<manveru>
anw, gotta make some dinner or my son starves to death
<manveru>
maybe i'll play around with some better dependency resolution algorithms for our use-case with a bit of human intervention :)
<qyliss>
:)
<manveru>
but for now, can you assemble a list of gems you'd like personally?
<manveru>
i only need 10 or so myself
<qyliss>
For now, how about?: pry-byebug pry-doc activesupport rspec rugged
<qyliss>
I don't actually regularly use all that many gems
<qyliss>
I'm starting to experiment with generated bundler files
<qyliss>
I'm seeing if I could make a JSON representation of a Gemfile.lock, which would be readable by Ruby and Nix
<qyliss>
And could be turned back into a Gemfile.lock (and have a Gemfile generated from it) for Bundler.
<qyliss>
Looking promising, though requires a bit of Bundler internals
<manveru>
that'd be helpful yeah :)
<qyliss>
This is going to be my Bundix 3 :P
<qyliss>
It will have `bundix env` and generate a development environment
<manveru>
because of the changed format?
<qyliss>
And `bundix package` which will generate a package
<qyliss>
And that will be it
<manveru>
heh
<qyliss>
And a changed CLI
<qyliss>
I think the current one has grown too many options and is confusing
<qyliss>
I still don't know what "magic" is :P
<manveru>
i wish i'd never put that in...
<manveru>
i don't even use any options anyway
<manveru>
so yeah, i'm up for rewrites :)
<manveru>
anything is more useful than what we got now
<qyliss>
I like -l
<qyliss>
Maybe -l can stay
<qyliss>
Saves me having to add bundler to my nix-shell
<qyliss>
but it's extremely simple
<manveru>
that should really be what `bundix` does without any options
<qyliss>
yes good point
<qyliss>
it should have a --no-lock if you _really_ don't want to
<manveru>
something like that :)
<qyliss>
but I can't imagine that would be useful very often
<manveru>
esp if you can generate the lockfile
<manveru>
and gemfile
<qyliss>
that's the plan
<qyliss>
only thing you'll need to add to nixpkgs will be Gemfile.lock.json
<qyliss>
An updated bundlerEnv will read that to figure out dependencies, and then run bundix to generate the gemfile / lockfile
<manveru>
alright, had to push a new version of bundix
<qyliss>
what for?
<manveru>
it didn't support bundler > 2.0
<qyliss>
oh yeah that was on my list :)
<qyliss>
bundler 2 still isn't in nixpkgs iirc
<manveru>
it is in mine :P
<qyliss>
mine too :P
<manveru>
was testing if it was faster
<qyliss>
guessing it wasn't?
<manveru>
nope
<manveru>
anw, i got the list of gems pretty much done now
<qyliss>
They didn't actually change anything for bundler 2 -- they've had the codebase support both for ages. it's just now they can start dropping support for stuff like old rubies
<qyliss>
Update: losslessy roundtripping every Gemfile.lock in nixpkgs to JSON and back!
<samueldr>
\o/
<qyliss>
And less than 200 LoC, which isn't bad considering it feels like I've reimplemented half of Bundler
<samueldr>
IIUC the reasoning is that you need the json format (or implement a parser in nix) so there's no IFD, to resolve the right gems, right?
<qyliss>
tomorrow I'll look at generating Gemfiles from Gemfile.lock.json too, but I think that's probably enough for tonight.
<qyliss>
Yeah, exactly
<qyliss>
Same reason we have gemset.nix now
<samueldr>
yeah, that's good, checking I was groking the right parts :)
<qyliss>
But using JSON instead of Nix means we can parse it from Ruby _in addition to Nix_. Which means we don't need the Gemfile and Gemfile.lock at all any more -- those can be generated.
<samueldr>
nice, and eelco will not receive security notices from github since it won't be in the standard format :)
<samueldr>
(I know, that's not the goal!)
<manveru>
:D
<qyliss>
lol
<manveru>
i'd still like to run bundler-audit, but we can do that on the fly
<qyliss>
Yeah. Would just have to modify the script to run bundix first.
<samueldr>
considering it goes both ways, I guess it'll add a step to re-generate the gemfiles/lockfiles, hopefully easy enough