Reprise: maintaining an up-to-date dev environment

[pfaffman (Jay Pfaffman)]

@Falco

I’ve been using asdf to manage versions for the many tools I use, so for me it’s just a

asdf install ruby 3.1.3
asdf local ruby 3.1.3

But now Discourse wants 3.2.1 and asdf seems not to know about 3.2.1. How are you managing that?

asdf list all ruby|grep 3.2.1

returns nothing.

@Falco

While I can see how cool would be to have that all automatically handled, for me handling my dev environment, updates and all, is an essential part of the job.

Since your job includes benchmarking ruby versions that makes lots of sense, but don’t the vast majority of developers in and out of CDCK just need a working dev environment without needing to know what libraries are required to make imagemagick (or whatever) compile correctly?

[sam (Sam Saffron)]

@pfaffman

But now Discourse wants 3.2.1 and asdf seems not to know about 3.2.1.

Something needs updating on your side cause ruby-build certainly has 3.2.1

Automatically updating ruby-build

[Falco]

My guess is that @pfaffman forgot to run asdf plugin update --all ?

[pfaffman (Jay Pfaffman)]

@Falco

asdf plugin update --all

DOH! I swear that I had tried to at least do a

asdf plugin update ruby

but it appears that I didn’t do that either.

But now, I’m really close! Here’s my script that pulls Discourse, updates Ruby, imagemagick, and nodejs, and migrates the database.

DISCOURSE_SRC=/home/pfaffman/src/discourse-repos/discourse
DISCOURSE_DOCKER_SRC=/home/pfaffman/src/discourse-repos/discourse_docker
cd $DISCOURSE_SRC

  git -C $DISCOURSE_DOCKER_SRC pull https://github.com/discourse/discourse_docker
  DISCOURSE_BASE=$(grep -e ^image= $DISCOURSE_DOCKER_SRC/launcher|cut -d'"' -f2)
  cd -

  docker pull $DISCOURSE_BASE
  asdf plugin add nodejs #https://github.com/asdf-vm/asdf-nodejs.git
  asdf plugin add ruby #https://github.com/asdf-vm/asdf-ruby.git
  asdf plugin add imagemagick
  asdf plugin update --all
  RUBY_VERSION=$(grep -e ^RUBY_VERSION $DISCOURSE_DOCKER_SRC/image/base/install-ruby|cut -d'"' -f2)
  asdf install ruby $RUBY_VERSION
  asdf local ruby $RUBY_VERSION
  IMAGE_MAGICK_VERSION=$(grep -e ^IMAGE_MAGICK_VERSION ~//src/discourse-repos/discourse_docker/image/base/install-imagemagick|cut -d'"' -f2)
  asdf install imagemagick $IMAGE_MAGICK_VERSION
  asdf local imagemagick $IMAGE_MAGICK_VERSION
  # 2023-04-24 debian and pop!os have different nodejs versions
  NODE_VERSION=$(docker run discourse/base:2.0.20230420-0104 bash -c 'node --version'|cut -d'v' -f2)
  asdf install nodejs $NODE_VERSION
  asdf local nodejs $NODE_VERSION
  cd $DISCOURSE_SRC
  git checkout main
  git pull
  bundle install
  ./bin/rake db:migrate
  RAILS_ENV=test ./bin/rake db:migrate

I think it’s OK to keep up with redis and postgres by hand, though the next time I do an OS install and find that my OS and Discourse have diverged, I’m likely to change my mind!

I’m unclear about what oxipng even is, but don’t think that the wrong version is likely to cause issues for a plugin developer. The same goes for jemalloc.

And TBH, I’m not sure how many plugin developers are likely to be affected by imagemagick versions either. I think that just Ruby and nodejs are likely to be show stoppers.

It might be safer to get ruby and imagemagick versions from the image as well, as I suspect that when debian has the required Ruby version, that script will go away, but I’d already written that logic when I learned that I had to pull the node version from the base image.

And in the time between when @falco saved me with asdf plugin update --all and when I wrote this script, the Ruby version bumped to 3.2.2, and my code caught it and asdf installed it! I’ve added the above code to my update script, which includes this: