<manveru> heh
<manveru> well, i don't see a much better way than changing rbconfig, and the implementation seems fine to me...
<manveru> but we'll have to see how much it breaks in real world :)
<qyliss> Cool, okay
<qyliss> I’ll merge tomorrow then I guess
<qyliss> Was proud when I eventually thought of doing it that way
<qyliss> Was staring at RI’s source for ages feeling extremely pessimistic about multiple outputs being at idle
<qyliss> *possible
<manveru> indeed :)
<manveru> dunno, other option would've been to always require rbconfig in all executables and set it there?
<manveru> which i like even less
<qyliss> Huh, didn’t think of that
<qyliss> rubygems requires rbconfig, so it is pretty much always there
<qyliss> but still, we shouldn’t be changing what libraries are loader EVER if we can at all avoid it
<manveru> jup
<manveru> there is --disable-gems
<qyliss> Exactly
<qyliss> So I think the shim is the least bad option
<manveru> now try it for jruby :D
<qyliss> Plus, a shim is pretty in-character for nixpkgs ;)
<qyliss> Oh no :P
<qyliss> You’ve piqued my curiosity now. Maybe I will.
<manveru> anw, i need sleep
<qyliss> But not right now
<manveru> cu tomorrow
<qyliss> Me too
<qyliss> cya
zimbatm has joined #nixos-ruby
<zimbatm> <3 ruby was my first love
<manveru> zimbatm: yo :)
<manveru> about the PR, it's totally not finished, i'm still thinking about the best way to enable people to reference `ruby.gems.$gemname`
<manveru> got some ideas, but still busy with dayjob :)
<manveru> and yeah, i thought about adding all gems in gem-config, i think it's a good idea, but i think i ran into some dependency conflicts
<manveru> will need to spend more time on that
<qyliss^work> There will be some gems in gem-config that are super old or whatever, that would bring down the maximum usable version for all other gems
<qyliss^work> So I don't think it's always worth it
<zimbatm> yeah, trimming down gemConfig is also a valid route
<qyliss^work> I think gemConfig should be as exhaustive as it can be
<zimbatm> bundler is mainly useful for the dependency resolution here, I think we could get rid of it at runtime
<zimbatm> same with the ruby package set
<zimbatm> maybe it should be the list of the 1000 most used gems or something like that
<qyliss^work> zimbatm: we've talked about this quite a bit already
<zimbatm> before I joined the channel?
<qyliss^work> yeah
<qyliss^work> We tried doing lots of popular gems but Bundler is so slow it was infeasible
<manveru> ruby.withPackages doesn't use bundler at all, it's still in the set though (still conflicted about it)
<zimbatm> ok
<qyliss^work> Can provide logs if you're interested
<zimbatm> I guess the dependency resolution is close to exponential complexity
<manveru> jup
<qyliss^work> glad to have you in here now :)
<zimbatm> thansk :)
ChanServ changed the topic of #nixos-ruby to: Everything about using Nix & Ruby. Logs at https://logs.nix.samueldr.com/nixos-ruby/
<zimbatm> I think it's fine to just let me know when I am repeating some of the previous point
<zimbatm> have you discussed about stackage yet?
<manveru> in passing
<qyliss^work> Yep
<manveru> i don't know how stackage compiles their package set
<zimbatm> they have some docker-thing cobbled up together
<manveru> after trying a bunch of different automatic approaches, we decided the least time-consuming and easiest to maintain is to do it manually after all :P
<zimbatm> they use a familiar base image like Ubuntu or Debian
<zimbatm> then they also have some manual banging at bits until it works
<zimbatm> as long as the package set is small we can keep it inside of nixpkgs
<zimbatm> at some point we'll probably want a supporting infrastructure to generate new snapshots
<manveru> the goal atm is to simply provide a quick and dirty way to use nix-shell with common gems
<zimbatm> yeah
<manveru> for everything more, use bundix
<zimbatm> ruby doesn't have the same problem as haskell regarding compilation times
<manveru> indeed
<zimbatm> just nokogiri :p
<manveru> even nokogiri is pretty fast :)
<manveru> it's really more about convenience of sharing ruby scripts for me :)
<zimbatm> in that case we should probably add "pry" to it if it's not already there
<zimbatm> make a cool ruby hacking environment
<manveru> it's in
<manveru> also added camping for fun :P
<zimbatm> essential :p
<manveru> bbl, work calls
<zimbatm> see you
<zimbatm> do you know if the rubygems API includes the sha256 of all the gems now?
<zimbatm> I remember we had to actually fetch the gems to discover their sha256
<zimbatm> qyliss^work: I don't think you were around, I wrote this thing at the time: https://github.com/zimbatm/nix-rubygems
<zimbatm> all the rubygems hashes was taking up 3.2GB of disk space
<qyliss^work> woww
<qyliss^work> sinatra would be good to have in there too
<manveru> zimbatm: it has the hashes for a long time now
<manveru> they don't match nix hashes, but we could do a custom fetcher
<manveru> i'm still hoping rubygems starts doing db dumps again
<manveru> so this kind of work is easier
<manveru> ,locate bin ar
<manveru> hm, different bot?
<manveru> mysql hasn't been updated since 2013 and doesn't compile on ruby 2, afaict
<qyliss^work> we only have the log bot
<manveru> yeah, noticed
<qyliss^work> I think you need to ask gchristensen or infinisil if you want {^_^}
<qyliss^work> Yeah I don't ever remember not using mysql2
<manveru> seems like all our gems were built so far with a hidden bundler dependency
<manveru> some actually need that to compile
<manveru> anw, only grpc and gtk2 left to fix :)
<manveru> then we can expose all gems from gem-config as well, they're actually compatible (other than mysql)
<manveru> gtk2 fixed, no clue how to fix grpc
<manveru> well, still need to actually test requiring all those gems to see what runtime dependencies they have :P
<qyliss^work> oh wow nice
<qyliss^work> (re: them all being compatible)
<manveru> i updated the PR with it, but need to write some kind of test that requires each once
<manveru> and then expose each gem via ruby.gems, that should be easy though
<manveru> and then users can use them via RUBYLIB or something
<qyliss> They should be able to use them automagically, because Ruby has a setup hook
<qyliss> I’m pretty sure if you do nix-shell -p ruby bundler right now you can require bundler
<qyliss> Although not at computer so can’t check
<manveru> i thought there was some function for pretty printing in nixpkgs lib...
<qyliss> not that I know of -- but maybe ask in a more populous channel?
<manveru> nah, it's silly anyway
<manveru> thought about making the format of ruby-packages.nix more compact, but it's not really needed
<manveru> it just doesn't need the fields for `groups`, `platforms`, `type`, `remotes` in this case
<qyliss> ya
<qyliss> Until we add jruby at least :P
<manveru> anw, time to finally write this thing :)
<manveru> wish i had more time for writing nix, it's always fun :D
<manveru> so i got this working now
<manveru> nix-shell -E 'let pkgs = (import ./. {}); in pkgs.stdenv.mkDerivation { name = "foo"; buildInputs = with pkgs.ruby.gems; [nokogiri pry]; }'
<manveru> and i can require nokogiri from pry :)
<manveru> time for some more cleanup
<qyliss> Nice! :)
<manveru> it's now super tiny ;)
<manveru> i love when i can throw out 80% of code
<manveru> would like a better name for the derivation, but it'll do for now i think
<manveru> does hydra build stuff in passthru?
<qyliss> Dunno
<qyliss> bundle lock is still running, btw :P
<qyliss> I should try profiling it