rycee changed the topic of #home-manager to: Support and discussion around the Home Manager project (https://github.com/rycee/home-manager) | Logs: https://logs.nix.samueldr.com/home-manager
ardumont has joined #home-manager
judson_ has joined #home-manager
judson has quit [Ping timeout: 276 seconds]
linarcx has joined #home-manager
ardumont has quit [Ping timeout: 246 seconds]
ardumont has joined #home-manager
linarcx has quit [Quit: WeeChat 2.4]
ardumont has quit [Ping timeout: 258 seconds]
ardumont has joined #home-manager
ardumont has quit [Ping timeout: 255 seconds]
ardumont has joined #home-manager
ardumont has quit [Ping timeout: 245 seconds]
iceypoi has quit [Quit: WeeChat 2.4]
<mog> rycee, home-manager is awesome
<mog> thank you
<mog> and anyone else who contributes to it
<rycee> Thanks, nice to hear! :-)
<mog> im moving all my user services over to it and have been very happy with it
<mog> im almost at point my whole system is defined, only emacs is left as its own heap
<rycee> Hehe, yeah. Emacs is a different beast :-)
<mog> and even that its in better place because home.file.".emacs.d".source = "/home/mog/code/dotfiles/home-manager/emacs";
<mog> and in git
<rycee> Yeah, certainly. Eventually there will be a module for configuring Emacs but it's still a bit rough.
<mog> ya and my emacs is crusty from years of use
<rycee> With the module my config is like this at the moment: https://gitlab.com/rycee/configurations/blob/master/user/emacs.nix
<mog> nixifying all the packages i use seems like great idea but also would be painful
<mog> is all of melpa in?
<rycee> Yeah, the emacs packages are regularly updated in Nixpkgs.
<rycee> For elpa, org, and melpa.
<infinisil> rycee: I think they weren't for some time now actually
<rycee> infinisil: Yeah. But I merged a bump relatively recently :-)
<rycee> From April 8.
<rycee> Unfortunately it isn't in 19.03 :-(
<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
xent has joined #home-manager
<xent> home-manager works now
<xent> now nixos feels like a semi normal system
xent has quit [Quit: Mutter: www.mutterirc.com]
<rycee> xent: Glad to hear it :-)