<rycee>
But the patch applies cleanly on 19.03 and I've been using it since then.
<infinisil>
I see
<infinisil>
It might be a cool idea to have a general auto-update infrastructure for nixpkgs
<infinisil>
A bot that runs every week or so, using an auto-update config specified in nixpkgs itself
<infinisil>
Instead of having all these ad-hoc update scripts scattered across
<rycee>
Certainly, that would be quite nice.
<rycee>
I do something like that with the Firefox addons and it's been working pretty well.
<judson_>
Unifying a lot of the nixpkgs infra would be rad.
<judson_>
I still would like to see that for language repos, but... it would not be easy to get to.
<judson_>
OTOH, nix-prefetch-* happened
<rycee>
judson_: Yes, more uniformity in general would be nice. Quite silly to have to learn a whole new packaging structure inside Nixpkgs when you go from Haskell to Perl or whatever.
<judson_>
At the same time, there's basic philosophical/political issues there.
<rycee>
Certainly. But one can dream :-D
<judson_>
I'd advocate that the Ruby approach is correct: the deps of an application should be scoped to the app. The nixpkgs-Python maintainer holds that it should be repo-scoped in order to make package updates easier.
<judson_>
OTOH, I've had python based apps break in Nix because stuff got updated...
<judson_>
And I don't know how the Haskell packaging world works.
<judson_>
But if we could agree on a common-enough approach we could start having nixify-* tools.
xent has joined #home-manager
<xent>
hello
<xent>
is there a guide to install home manager
<infinisil>
judson_: What do you mean by "scoped to the app"?
<judson_>
What version of Nokogiri does e.g. Gitlab use? Should it be the same one that Rubymine does?
<judson_>
xent, the README it pretty good, I thought.
<judson_>
Ruby packages have a gemset.nix generated by bundix based on the Ruby Gemfile that picks the exact versions w/ digests.
<infinisil>
judson_: Oh right
<infinisil>
Yeah that doesn't work for Haskell at least
<judson_>
There's a pypi2nix, but PRs based on it get rejected.
<infinisil>
Because this would mean there would be so many dependencies of almost the same version to build
<xent>
is it ok to run this “nix-shell '<home-manager>' -A install”
<xent>
or is there a better way to add it into the config?
<infinisil>
judson_: And python is done the same way because it means you have a single set of dependencies. This also makes fixing things easier. If some python package fails to build, you won't have to fix it for all apps that use it
<rycee>
xent: That command looks OK. It's like the one in the installation instructions.
<xent>
rycee: ok thank you
<infinisil>
judson_: I guess perl can do that because of how perl doesn't have any complicated builds
<infinisil>
It just needs some perl path stuff and everything will work out (is my guess)
<judson_>
I guess I'm not clear on how python varies there. How would a python package fail to build?
<rycee>
infinisil: Yeah, I think that would work for Perl.
<infinisil>
judson_: Dependency mismatch, a couple python packages need to build C stuff or other things to build
<infinisil>
Can't think of anything else right now
* infinisil
looks at pkgs/development/python-modules
<infinisil>
Ah right, tests failing all the time
<judson_>
Ruby has similar, I think. FFI. Nokogiri is the go-to example because Rails depends on it and it links against libxml2
<judson_>
And carries around its own portage implementation as a result!
xent has quit [Remote host closed the connection]
<infinisil>
I guess python isn't that bad, it might be possible to use the perl approach for it with some tooling
<judson_>
(I'm sure there were some questioning of life decisions involved with building mini-portile)
<infinisil>
Oh and also, the advantage of the python and haskell way is that you have much reduced closure size, as deps can be shared between the whole system
<judson_>
And I understand the "if there's one instance of a python librarian in nixpkgs, we can fix it once" argument, for sure.
<judson_>
Ruby uses a gemConfig set to do univeral overrides though, which works really well.
<infinisil>
I see
<judson_>
IME, you don't actually have "we'll fix it once" - you fix the library for this dependent, and that one breaks.
<infinisil>
nixpkgs all-in-all also uses the sharing dependencies between everything approach. It would be a pain if it wouldn't
<infinisil>
The less sharing, the bigger the expressions also get
<infinisil>
Would probably be good to make a list of advantages/disadvantages of either approach
<judson_>
Sharing in expressions. Not necessarily in productions.
<judson_>
Oh, for sure. I think there's a ton of design work to be done here (not just in Nix!) I'm not sure how to get that going though.
<infinisil>
pie__ started some working group on something about plugins, which has something to do with this as well maybe
<judson_>
Interesting.
<judson_>
I get the sense that a lot of Nix organization happens at NixConf. Accurate?
<infinisil>
Hmm, I can't say there is, I did hear some things though