Make Mastodon use its own gemset

[TheStranjer]

Generally, having a gem environment that's specific to the app you're writing is a good idea. If merged, this will implement that.

[ClearlyClaire]

I'm not sure what the benefits of using RVM gemsets are since we're using bundler to install gems (which are managed locally in vendor/bundle)

[TheStranjer]

If you're using RVM, it by default won't go into vendor/bundle. It will go into whichever gemset is being used. So, the benefit is primarily for RVM users. Here's what happens when I checkout main and then jump in and try to use bundle (install):

thestranjer@monolith:~/Code$ cd mastodon
thestranjer@monolith:~/Code/mastodon$ rvm list
   ruby-2.1.2 [ x86_64 ]
   ruby-2.2.1 [ x86_64 ]
   ruby-2.3.1 [ x86_64 ]
   ruby-2.4.1 [ x86_64 ]
   ruby-2.4.5 [ x86_64 ]
   ruby-2.5.1 [ x86_64 ]
   ruby-2.5.3 [ x86_64 ]
   ruby-2.6.3 [ x86_64 ]
   ruby-2.6.5 [ x86_64 ]
   ruby-2.7.1 [ x86_64 ]
 * ruby-3.0.0 [ x86_64 ]
   ruby-3.0.2 [ x86_64 ]
=> ruby-3.0.3 [ x86_64 ]
   ruby-3.1.1 [ x86_64 ]

# => - current
# =* - current && default
#  * - default

thestranjer@monolith:~/Code/mastodon$ rvm gemset list

gemsets for ruby-3.0.3 (found in /home/thestranjer/.rvm/gems/ruby-3.0.3)
=> (default)
   downtest
   fedi_thread_watch
   global
   mastodon

thestranjer@monolith:~/Code/mastodon$ bundle
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies....
Using rake 13.0.6
Fetching concurrent-ruby 1.1.9
Using minitest 5.15.0
Using erubi 1.10.0
Fetching mini_portile2 2.8.0
Using zeitwerk 2.5.4
Fetching racc 1.6.0
Using builder 3.2.4
Fetching crass 1.0.6
Installing concurrent-ruby 1.1.9
Installing mini_portile2 2.8.0
Installing crass 1.0.6
Installing racc 1.6.0 with native extensions
Fetching rack 2.2.3
Fetching nio4r 2.5.8
Fetching websocket-extensions 0.1.5
^Cthestranjer@monolith:~/Code/mastodon$ ls ./vendor/ -l
total 0

I'd like to not have to either mix all my gems together in one big pile or remove RVM just to tinker with this project.

[ClearlyClaire]

Does this occur even when following the installation instructions from the Mastodon documentation?

bundle config deployment 'true'
bundle config without 'development test'
bundle install -j$(getconf _NPROCESSORS_ONLN)

In any case, I don't think this change should be needed. But if it does not have any surprising or ill effect either, why not.

[TheStranjer]

I didn't use that because I wasn't trying to install it exactly, but develop on it. I'm normally a Pleroma user and wanted to tinker with this locally. I submitted this PR as a courtesy since I, personally, am going to use a gemset for this even if the people running this repo think that's wacky.

I don't think it will have any ill effects; after running those installation commands, it did place the files in vendor/bundle, although I will admit that was counter-intuitive to me thanks to my own misunderstood difference between installation (those instructions do tell you to say it's a deployment!), and development.

I would keep this change but it's also not my repository. Merge or close it, neither bothers me. Enjoy the rest of your day!

[ClearlyClaire]

I didn't use that because I wasn't trying to install it exactly, but develop on it. I'm normally a Pleroma user and wanted to tinker with this locally. I submitted this PR as a courtesy since I, personally, am going to use a gemset for this even if the people running this repo think that's wacky.

I don't think it will have any ill effects; after running those installation commands, it did place the files in vendor/bundle, although I will admit that was counter-intuitive to me thanks to my own misunderstood difference between installation (those instructions do tell you to say it's a deployment!), and development.

Yes, bundle config deployment 'true' does a little more than just using vendor/bundle, which can be achieved by doing bundle config path 'vendor/bundle' if you want to develop (including be able to change the dependencies).

I would keep this change but it's also not my repository. Merge or close it, neither bothers me. Enjoy the rest of your day!

Thanks, I'll read up a little more on gemsets before I make up my mind, but it sounds like a good change.

[ClearlyClaire]

My understanding is that this would only ever affect people using RVM (not people using distribution-provided ruby, nor people following the documentation and using RBenv).

As for people using RVM, this would allow new users to not have gem clashes with other installs without having to configure bundler the recommended way. It might possibly cause an issue for users already making using Mastodon through RVM, although I haven't checked. Such issues would be solved just by re-installing bundler and re-running bundle install.

I don't have a strong opinion either way, so I'll just refer to @Gargron

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.