Keeping rails/dev up to date

dev
1

TL;DR

Perhaps:

https://github.com/techAPJ/install-rails/blob/master/linux#L47-L63

Should do git pull in .rbenv and ruby-build if they exist already and then this script can be used to update stuff?

Or is there something more obvious that I should be doing?

The long, sad story

I just upgraded to Ubuntu 18.04 on my desktop. I ran

   bash <(wget -qO- https://raw.githubusercontent.com/techAPJ/install-rails/master/linux )

And rails s cranks up just fine.

But rails c fails trying to load readline.

/home/pfaffman/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/bootsnap-1.3.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:
in `require': libreadline.so.6: cannot open shared object file: No such file or directory - /home/pfaffman/.rbenv/versions/2.4.2/lib/rub
y/2.4.0/x86_64-linux/readline.so (LoadError)
        from /home/pfaffman/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/bootsnap-1.3.0/lib/bootsnap/load_path_cache/core_ext/kernel_r
equire.rb:21:in `block in require_with_bootsnap_lfi'                                                                                   
        from /home/pfaffman/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/bootsnap-1.3.0/lib/bootsnap/load_path_cache/loaded_features_i
ndex.rb:65:in `register'

Readline library is installed in the os:

$ dpkg -l |grep readl
ii  lib32readline-dev                          7.0-3                                amd64        GNU readline and history libraries, development files (32-bit)
ii  lib32readline7                             7.0-3                                amd64        GNU readline and history libraries, run-time libraries (32-bit)
ii  libreadline-dev:amd64                      7.0-3                                amd64        GNU readline and history libraries, development files
ii  libreadline5:amd64                         5.2+dfsg-3build1                     amd64        GNU readline and history libraries, run-time libraries
ii  libreadline7:amd64                         7.0-3                                amd64        GNU readline and history libraries, run-time libraries
ii  readline-common                            7.0-3                                all          GNU readline and history libraries, common files

Finally, I re-ran this code:

ruby_version="2.5.1"

log_info "Installing Ruby $ruby_version ..."
  rbenv install "$ruby_version"

log_info "Setting $ruby_version as global default Ruby ..."
  rbenv global $ruby_version
  rbenv rehash

And now it’s working again.

Perhaps:

https://github.com/techAPJ/install-rails/blob/master/linux#L47-L63

Should do git pull in .rbenv and ruby-build if they exist already and then this script can be used to update stuff?

I’ll submit a PR if this is a good idea.

2

I am mixed on adding too much fancy here, getting into the world of installing Ruby on machines is a world of pain. I prefer to double down on docker dev image we have which takes care of all of this and more.

2 Likes
3

I like the idea of docker Dev, but my experiences with docker dev have been mixed.

How many folks on team are using it for their development work? Are you?

4

No I do not usually use it but I like pain, I am not really the demographic for an “easy dev install” setup.

8 Likes
5

Not on the team, but I use it near daily for all my Discourse core/plugin development work.

I rolled my own scripts to help with my particular workflow (which requires pretty regular switching between a vanilla discourse instance, and one with all the bells, whistles and API keys we hang off Discourse within Mozilla):

4 Likes
6

I’m pretty sure that’s how we’re the same. (Though I don’t like pain enough to use Windows.) :wink:

Me neither. I’m the kind of person who’s likely to for one reason or other, set up or upgrade a new machine several times a year. Often enough that I’d like to have stuff scripted because it’s not often enough that I remember.

For running final imports I’m increasingly running them in a production container, but when I’m developing an import script, having it run on my desktop unencumbered by a layer of abstraction seems preferable. OTOH, it’s not unlikely that I find that habits that I developed 20 years ago are no longer best practices.

Another pain point for me is running one import on one branch while also being able to switch branches and work on another while the first one is running. Sometimes I’ve thought that docker_dev would help with that. I’ll see about giving it another look, but I think that unless someone on team actively uses discourse_dev it’s likely to be difficult to keep it fresh.

Maybe I’ll give it another shot, but I may still submit a PR that updates rbenv and ruby-build in the dev install script.

2 Likes