URL scheme: allow building `withPackages`-style derivations

[flokli]

Nixpkgs provides some *.withPackages functions to build an environment assembled so that it's able to find all modules specified afterwards:

examples:

• python*.withPackages (p: [ p.requests ])
• lua*.withPackages ( l: [ l.luasocket ])
• perl*.withPackages ( p: [ p.YAML ])

It would be nice if we'd be able to use these directly from nixery too.

[tazjin]

In general I wouldn't mind adding more "special" packages, but it's unclear how that should be specified in the URL syntax.

For example:

/pywithpkgs/requests -> python.withPackages (p: [ p.requests ])

If I now want git as well, where do I put it?

Thoughts:

1. Special packages like pywithpkgs could be at the beginning of the path segment (like meta-packages (shell)) and continue until either a) another special package appears, b) something from the top-level appears. But can b) be reliably determined? Are there package sets that overlap with the top-level?

2. Special packages could be at the end of the path, in which case there can be multiple (until the next special package or path end): nixery.dev/shell/git/pywithpkgs/request/luawithpkgs/luasocket

At this point the URL syntax starts having a little more grammar than (metapkg | pkg)/[pkg ...] ...

[flokli]

1b) There's packages both in p. and just in nixpkgs, so it wouldn't be distinct.

Hm, "special packages" would mean we'd have to hardcode which packages support this syntax. That could become quite cumbersome, given each python, lua and perl package version support the withPackages syntax (and new ones could pop up)

I'd rather see a syntax able to express what we want to do here. Can we use a double slash (//) in the path? This could act as a separator, or maybe encode some modifiers…

[FRidh]

So far I've been skeptical towards supporting installing Python libraries directly into a profile and having that function, because it could lead to ABI issues which, frankly, I prefer not to see in our tracker because they're avoidable with the way we currently work (buildEnv/withPackages). However, for situations like these as well as Flakes it may be worth considering after all.