Why not just use the fetchTarball from nixUnstable and tell users to upgrade if they don't have it? It's not like this is going to be needed for core nixpkgs usage or anything.

Because I use it on a bunch of systems today and nobody's using nixUnstable (in part because there have been big warnings saying that nixUnstable is very unstable right now) 😛 I'd rather not force everyone to upgrade before this thing works, especially when there's little downside to this approach.

Eh, OK 👅 Fine by me

Hmm, as one would never use this within nixpkgs, I wish there was a more "out of band" location for it within the repo. Maybe /lib, which, while also the heart / deepest import, can be used to without nixpkgs so it makes some sense?

As to the arguments, they still in much flux----which makes pinning packages difficult anyways if one is pinning nixpkgs before and after my changes.

All in all, it seems like very little code to abstract over, shrugs. I assumed this is used in situations like https://github.com/reflex-frp/reflex-platform/blob/develop/nixpkgs/default.nix --- but in that specific example, this wouldn't exactly fit anyways?

In it's defence, there are number of instances of needing nixpkgs just to get another instances of nixpkgs---e.g. picking nixpkgs from the module system, or for the new command line in lieu of channels. Together, these constitute a good need for a general solution.

I'm not really seeing the use of this. This adds a function to Nixpkgs to fetch Nixpkgs, which presents an obvious chicken-and-egg problem. Indeed you're better off using fetchTarball, which in the next Nix release supports a sha256 attribute (NixOS/nix@06bbfb6).

Also the name asOf is very non-descriptive.

@edolstra I thought it was sort of cute to write pkgs.asOf { rev = "12345"; ... } 😄 Would you accept it with a better name? There doesn't seem to be much of a downside to adding something like this, to me, but having a name that people can agree on would also be nice.

The idea would be to be able to say, in my configuration.nix, services.postgresql.package = (pkgs.asOf { rev = "12345"; ... }).postgresql. Basically just gives me a simple and succinct way to reach into nixpkgs history and mix and match versions of nixpkgs, sometimes even in the same configuration. Sometimes I need a fix for one thing but then another unrelated thing gets upgraded in the same channel and that breaks something else.

I know that fetchTarball can do this in the unreleased version, but what's so bad about this one for the use case I describe above?

The idea would be to be able to say, in my configuration.nix...

Should this be a NixOS helper then? Like in the NixOS Lib?

@copumpkin just aesthetically trying to avoid the nixpkgs-fetches-nixpkgs scenario. Even though with NixOS being in the same repo, its hardly a practical improvement.

I'll not be a roadblock here, just wishing there was a more pleasing solution long term.

I'm not really seeing what's so fundamentally wrong with nixpkgs-fetches-nixpkgs. It seems like a reasonable place to stash up-to-date knowledge of a canonical place where nixpkgs lives and how to fetch particular versions of it.

@copumpkin Sorry I can't come up with a good argument---tbh in programming as everywhere else my design/aesthetic concerns are gut instincts only receiving a post-hoc rationalization. The best I could come up with was where the asOf happened to coincide with the current version, extra work would be needed, but in a post-channels world that may well be not the case.

This is why I don't want my concerns to actually block this :)

What would being a NixOS helper change though? I don't want to set it on a module level because then I can't control it in a fine-grained manner.

I think NixOS should definitely work with multiple nixpkgs---we can think about this separate from this patch though

I think ultimately what I really want is super lightweight named channels that I can easily create/destroy/update on the fly 😄 I still don't have a good grasp of @edolstra's plans to abolish channels, but until we get that, I really find myself using something like this quite often.

Take e.g., @jwiegley who often complains (in the ##nix-darwin IRC channel) that the packages he uses in his shell environments break in master. Something like this allows him to lock particular ones that break in master to known-good versions, but to otherwise track master. If you use a lot of it, it becomes a bit of a maintenance pain, which is why we need to rethink how we do channels, but until then I think this at least gives us an "easy" way to hop across versions of nixpkgs without keeping half a dozen nixpkgs clones lying around.

Well, the idea is that you write your shell.nix like this:

with import (fetchTarball { 
  url = https://github.com/NixOS/nixpkgs/archive/2766a4b44ee6eafae03a042801270c7f6b8ed32a.tar.gz;
  sha256 = ...; # optional
}) {};
...

This involves only one version of Nixpkgs, namely the one you specify.

Sure, and now people who want it have to remember the GitHub archive URL scheme (because any abstraction over that would need to live somewhere), and if they want that sha256 field they need to use unreleased software that just underwent a major refactor.

Anyway, I give up. The amount of time that's going into justifying these 5 lines of code far exceeds what makes sense for me to argue for.

😢

FWIW, the feature @copumpkin described would be amazing for my workflow. I build over 2,000 packages in my main environment, and it's very hard to keep all of these working when other Nixers don't do their primary testing on Darwin. Sure, Hydra catches it and eventually they get fixed, but much of the time, something in that set of 2,000 breaks, forcing me to delay updating until Hydra catches up. Thus, my complaints in ##nix-darwin.

If I could "freeze" the broken packages during an upgrade attempt, and then unfreeze them a few days later, it would be a much, much better solution than what I do now: which is to hack nixpkgs to undo whatever change broke those packages -- if I even can. Plus, if I have something important coming up, like a demo at work, I could freeze the relevant packages without having to freeze the entire system.

I would rank such a feature very high on my wishlist; but the tarball importing @edolstra suggests is not something I'd use. It sounds much too brittle and manual, compared to what @copumpkin has proposed.

@copumpkin What about having let nixpkgsAsOf = import (builtins.fetchurl "https://nixos.org/nixpkgs-as-of.nix"); in at the top of every file?

@jwiegley Eh, what's brittle or manual about it? It specifies exactly the same thing, except that it doesn't require evaluating a different version of Nixpkgs first.

I may have misunderstood the usage of asOf. Here's what my ideal would be:

(asOf "fd7b74db" dovecot)

@shlevy my goal is basically to be as close to 100% reproducible/auditable as I can be. the "https://nixos.org/nixpkgs-as-of.nix" thing would work except that it introduces an unhashed and unversioned middleman in all this. I could hash-check that but then I need to hash check the fetcher, and the actual version of nixpkgs I wanted, and then that ends up being more effort than the thing I was abstracting over.

Anyway, it's not a big deal. I thought this would be a nice and useful thing for more people, since I don't think we have a good solution for mix-and-match workloads today. Yes, in principle someone can use fetchTarball, but nobody knows about it, and having an endorsed function for this feels like it's first-class support whereas just telling people to fetchTarball a URL that GitHub doesn't make very obvious doesn't feel like that. I acknowledge that the whole thing is a pretty thin abstraction. In retrospect I probably should've just pushed and nobody would've noticed 😄