Hi Guix, In the course of some fairly involved yak-shaving, I found the need to run a Ruby package, and tried running `guix environment --ad-hoc bundler ruby`. However, running it produced an error: $ bundle install Traceback (most recent call last): 2: from /gnu/store/5flpa8h2adwb86n49r7p3mbp11p0jafr-profile/bin/bundle:23:in `<main>' 1: from /gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/2.6.0/rubygems.rb:302:in `activate_bin_path' /gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/2.6.0/rubygems.rb:283:in `find_spec_for_exe': Could not find 'bundler' (2.1.0.pre.2) required by your /home/josh/c/gnome-dbus-emulation-wlr/Gemfile.lock. (Gem::GemNotFoundException) To update to the latest version installed on your system, run `bundle update --bundler`. To install the missing version, run `gem install bundler:2.1.0.pre.2` Indeed I see that gnu/packages/ruby.scm only packages Bundler v1.17.3, though Bundler 2 was released in January 2019 [0]. I'm not hugely familiar with the Ruby ecosystem, but reading the release announcement suggests that they expect users/developers to have both Bundler 1 and Bundler 2 available. If I hadn't seen this, I'd have gone ahead and submitted a patch simply upgrading the Bundler package definition, but I'm not sure if that will then immediately break every package depending on it that expects Bundler 1. Is this a valid concern? Should Guix provide packages for both Bundler 1 and Bundler 2, or would just Bundler 2 be sufficient? I'll still write a definition for the new version, but I'll hold off submitting a patch until I've had some feedback. [0]: https://bundler.io/blog/2019/01/03/announcing-bundler-2.html Thanks, -- Josh Holland
On Tue, 12 May 2020, Josh Holland wrote:
> Indeed I see that gnu/packages/ruby.scm only packages Bundler v1.17.3,
> though Bundler 2 was released in January 2019 [0]. I'm not hugely
> familiar with the Ruby ecosystem, but reading the release announcement
> suggests that they expect users/developers to have both Bundler 1 and
> Bundler 2 available. If I hadn't seen this, I'd have gone ahead and
> submitted a patch simply upgrading the Bundler package definition, but
> I'm not sure if that will then immediately break every package depending
> on it that expects Bundler 1.
>
> Is this a valid concern? Should Guix provide packages for both Bundler
> 1 and Bundler 2, or would just Bundler 2 be sufficient? I'll still
> write a definition for the new version, but I'll hold off submitting a
> patch until I've had some feedback.
>
> [0]: https://bundler.io/blog/2019/01/03/announcing-bundler-2.html
Josh,
Thanks for raising this question.
I'm not a Rubist, but we do wrangle some Ruby code at work (unfortunately,
not yet with Guix). Our experience has been that everyone interacting with
the code should use the same Bundler version, so I think that as long as
Bundler v1 is supportable, we should provide both in Guix.
What do others think?
Jack
On Tue, May 12, 2020 at 05:48:12PM -0400, Jack Hill wrote: > On Tue, 12 May 2020, Josh Holland wrote: > > > Indeed I see that gnu/packages/ruby.scm only packages Bundler v1.17.3, > > though Bundler 2 was released in January 2019 [0]. I'm not hugely > > familiar with the Ruby ecosystem, but reading the release announcement > > suggests that they expect users/developers to have both Bundler 1 and > > Bundler 2 available. If I hadn't seen this, I'd have gone ahead and > > submitted a patch simply upgrading the Bundler package definition, but > > I'm not sure if that will then immediately break every package depending > > on it that expects Bundler 1. > > > > Is this a valid concern? Should Guix provide packages for both Bundler > > 1 and Bundler 2, or would just Bundler 2 be sufficient? I'll still > > write a definition for the new version, but I'll hold off submitting a > > patch until I've had some feedback. > > > > [0]: https://bundler.io/blog/2019/01/03/announcing-bundler-2.html > > Josh, > > Thanks for raising this question. > > I'm not a Rubist, but we do wrangle some Ruby code at work (unfortunately, > not yet with Guix). Our experience has been that everyone interacting with > the code should use the same Bundler version, so I think that as long as > Bundler v1 is supportable, we should provide both in Guix. > > What do others think? Bundler is a packaging tool that typically works at the source tree level. Its approach is to pull all dependencies in. With Guix we don't have much use for it. Better to package gems in Guix and benefit from a true reproducible and dependable deployment system that *includes* underlying dependencies, such as libxml and all that. Sometimes it is useful to try gems. I did write up in the past how I mix Guix packages with Ruby gems. Using bundler is just another layer. See https://gitlab.com/pjotrp/guix-notes/-/blob/master/RUBY.org#gnu-guix-ruby-with-bundler Not much love for bundler therefore ;) Pj.
[-- Attachment #1: Type: text/plain, Size: 2195 bytes --] Josh Holland <josh@inv.alid.pw> writes: > In the course of some fairly involved yak-shaving, I found the need to > run a Ruby package, and tried running `guix environment --ad-hoc bundler > ruby`. However, running it produced an error: > > $ bundle install > Traceback (most recent call last): > 2: from /gnu/store/5flpa8h2adwb86n49r7p3mbp11p0jafr-profile/bin/bundle:23:in `<main>' > 1: from /gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/2.6.0/rubygems.rb:302:in `activate_bin_path' > /gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/2.6.0/rubygems.rb:283:in `find_spec_for_exe': Could not find 'bundler' (2.1.0.pre.2) required by your /home/josh/c/gnome-dbus-emulation-wlr/Gemfile.lock. (Gem::GemNotFoundException) > To update to the latest version installed on your system, run `bundle update --bundler`. > To install the missing version, run `gem install bundler:2.1.0.pre.2` > > Indeed I see that gnu/packages/ruby.scm only packages Bundler v1.17.3, > though Bundler 2 was released in January 2019 [0]. I'm not hugely > familiar with the Ruby ecosystem, but reading the release announcement > suggests that they expect users/developers to have both Bundler 1 and > Bundler 2 available. If I hadn't seen this, I'd have gone ahead and > submitted a patch simply upgrading the Bundler package definition, but > I'm not sure if that will then immediately break every package depending > on it that expects Bundler 1. > > Is this a valid concern? Should Guix provide packages for both Bundler > 1 and Bundler 2, or would just Bundler 2 be sufficient? I'll still > write a definition for the new version, but I'll hold off submitting a > patch until I've had some feedback. > > [0]: https://bundler.io/blog/2019/01/03/announcing-bundler-2.html Hi Josh, I'm not particularly sure, but it's probably easier to just provide both. Note that bundler has quite few dependencies in Guix [1], so it would be interesting to see if these all build with Bundler 2. 1: → guix refresh -l bundler Building the following 37 packages would ensure 182 dependent packages are rebuilt Thanks for looking in to this, Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 962 bytes --]