<samueldr>
hmmm, bundler 2 might require that we have ruby_x_yPackages to have the right bundler; otherwise e.g. updating bundler to 2.0.1 in nixpkgs, then simply using it on a codebase where ruby is locked with 2.6, bundler will know only of the ruby it built with
<samueldr>
meaning that it errors out knowing it's ruby 2.5
<samueldr>
(or could this sanely happen as a passthru?)
<qyliss>
Oh does Bundler 2 record Ruby version?
<qyliss>
not entirely sure I understand what you mean
<samueldr>
sorry, yeah, it records bundler version and ruby version
<samueldr>
bundler 1.7 knows about bundler 2.x locking itself, so bundle install on a bundler 2.0.1 lockfile will not work
<samueldr>
the specific ruby version, though, is set in the Gemfile
<samueldr>
(but I haven't really checked yet if it is locked in other ways, or even if it can be set using bounxz)
<samueldr>
bounds*
<qyliss>
My plan is to package Bundler 1 and Bundler 2 for the foreseeable future
<qyliss>
In my limited testing Bundler's autodetection will work perfectly if you have both packages in your env at one
<qyliss>
So you can just nix-shell -p bundler_1 bundler_2 and everything will be fine
<samueldr>
what about ruby version lock?
<samueldr>
I'm thinking about development using nixos/nixpkgs, on non-nix projects
<samueldr>
(my current use case)
<qyliss>
yeah that's mine too
<qyliss>
I'm not sure I see the problem there?
<qyliss>
We'll need to put Bundler into rubyPackages or whatever
<qyliss>
But then it'll make sure it has the right version of Ruby.
<samueldr>
using `nix-shell -p bundler ruby_2_6` bundler sees ruby 2.5, thus will stop
<samueldr>
(as 2.5 is `ruby` and bundler uses `ruby`)
<qyliss>
Sure
<qyliss>
You'd do `nix-shell -p ruby_2_6.withPackages (pkgs: with pkgs; [ bundler ])`
<samueldr>
right
<qyliss>
I think that's fine?
<samueldr>
yeah
<qyliss>
So is there any problem here?
<samueldr>
sounds good
<samueldr>
I think I was confused by what you said beforehand
<qyliss>
manveru: had to finally kill that huge Bundler process. 1000+ hours of CPU time in, and it was still going lol.
<qyliss>
ahh
<samueldr>
didn't see how 2.6 would be specified → [16:36:44] <qyliss> So you can just nix-shell -p bundler_1 bundler_2 and everything will be fine
<samueldr>
but what you said seems alright
<qyliss>
riiight yeah I wasn't thinking about the Ruby version case
<manveru>
hmm, so we'll have to include bundler in the common gemset i guess
<manveru>
though i think it's in there anyway as a dependency somewhere
<samueldr>
though I'm just now getting concerned about ease of using _a_ specific bundler/ruby version, I'm thinking in the situation where working for a $client you can't upgrade their deps (even though you should)
<samueldr>
e.g. ruby_2_6 is now 2.6.3, not my job to upgrade to 2.6.2 on the project
<samueldr>
wondering if there's a way to make a sane interface for developers
<samueldr>
(mostly thinking out loud_
<qyliss>
samueldr: I think the solution to that is to expose a builder function
<samueldr>
yeah, that would be sufficient
<qyliss>
I use 1.9 for some things at work still
<samueldr>
(sorry) :)
<qyliss>
I just reverted the commit that removed it and it works fine
<qyliss>
So if we just exposed the builder functions people could do whatever they wanted
<samueldr>
though I was now thinking what if some shell building infra knew about the gemfile locking versions, what we'd need would "only" be a list of expected hashes for every ruby versions :/
<samueldr>
pkgs.mkBundlerShell ./.;
<qyliss>
manveru: yeah I'd always planned on doing that. And then just aliasing it to top-level `bundler`
<qyliss>
samueldr: not sure I understand again
<manveru>
heh
<samueldr>
yeah, I need to think more about it before barfing up my thoughts :)
<manveru>
well, you can do that if the Gemfile.lock includes the ruby version
<samueldr>
the Gemfile does
* samueldr
now fires up the bundler doc
<manveru>
the Gemfile _can_, the Gemfile.lock doesn't afaict
<samueldr>
(I was going from assumptions from what my colleague and creator of the project said about bundler 2)
<samueldr>
yeah, doesn't look like it _requires_ to specify a ruby version
<samueldr>
and looks like it does support version specificers like >= so I guess there's no issues after all with that, other than my colleague setting a specific version
<manveru>
yeah
<manveru>
qyliss: btw, did you do anything on bundix3?
<qyliss>
A bit
<qyliss>
But not too much
<qyliss>
A bunch of not-Nix stuff came up very shortly afterwards
<manveru>
started tinkering a bit this week, got generation for gems and git at least, plus a new CLI based on main.rb
<manveru>
(Gemfile generation)
<qyliss>
oooh
<manveru>
wanted to talk about moving to a gemset.json :)
<manveru>
because if we add enough meta-data we could also generate the Gemfile.lock, but not sure it's worth it?
<manveru>
just sounds like a pain to keep it compatible
<qyliss>
I think we should
<qyliss>
I have it working pretty well
<qyliss>
And it gives us a single source of truth
<qyliss>
that's pretty much the only thing I have working