Conversation
The idea here is that future Nix first tries to "`nix run`" the
`pkg.devShell` package, and only if that fails, fall back to the
legacy `nix develop` (or `nix-shell`) behavior.
This allows the development shell to evolve with stdenv, and it
allows packages to individually customize the `devShell` attribute,
by setting `passthru.devShell`.
Furthermore, these shell behaviors will be pinned to the expressions,
allowing changes to be made in a more agile manner, unlike Nix,
which has to be very careful not to break old expressions, as users
can not revert Nix.
To give it a try:
nix run .#hello.devShell
In the future this will be equivalent to:
nix develop .#hello
Isn't this the responsibility of Nix?
It is not. `nix-shell` and `nix develop` are a great user interface,
that everyone loves, but their implementation is a pile of hacks on
top of stdenv.
Instead of coercing stdenv to do what `nix-shell` needs it to, we can
ask stdenv politely to provide a shell.
Now that Nix doesn't have to assume a package comes from stdenv,
there's a possibility for experimental builders to provide shells too.
What does this break?
Only packages that define a `devShell` attribute (for some reason?)
have to adapt to the suggested new Nix behavior. Note that a
`devShell` value for the builder can be overridden by `passthru`
without affecting the build or shell.
Packages and shells pinned to older versions can still be loaded
because Nix keeps the legacy behavior as a fallback.
But this still relies on `nix-shell` to provide a shell???
Fair enough. This is only a proof of concept. The goal is to replace
that invocation by a script or program with the same or better
behavior, without relying on `nix-shell` as its implementation.
Does this solve the need for `.env` for Haskell package shells?
Not in this commit, but Haskell packages will be able to produce
their own `devShell` attribute, which is derived from the .env
derivation rather than the regular derivation.
Refs
- NixOS/nix#7468 and a bunch of other
issues where I've preached about this idea.
ofborg
bot
added
10.rebuild-darwin: 0
|
Copying from NixOS/nix#7468 (comment)
I.e.:
|
This seems more than needed. If a package is complicated enough to warrant multiple shells, that probably means that it consists of components. Presumably those could be built separately and be represented by different attributes; siblings of the package, or attributes on the package (like # default shell
nix develop .#mypkg
# component-specific shell
nix develop .#mypkg.frontendThe So this is already a solution without having to make the package <-> nix interface more complicated. |
ofborg
bot
added
10.rebuild-darwin: 1-10
… __cleanAttrs packages" Do not add this until we've decided what inputDerivation is and how it fits in with cleanAttrs and the possible devShell attribute - NixOS#206728 This reverts commit 99e1be309a70bfb8476b1892b8d102065860b2be.
infinisil
added
the
1.severity: significant
| # TODO replicate in bash | ||
| exec ${pkgs.buildPackages.nix}/bin/nix-shell ${builtins.unsafeDiscardOutputDependency drv.drvPath} |
There was a problem hiding this comment.
See streamNixShellImage for how to do this kind of thing.
wegank
added
2.status: stale
stale
bot
removed
the
2.status: stale
|
@roberth any plans on updating this? |
|
I originally wrote this PR to illustrate the design, and it worked: NixOS/nix#7501 was accepted by the Nix team. In the foreseeable future I'm too occupied with Nix maintenance to put much effort into either the Nixpkgs or the Nix side of the proposal, so I would encourage anyone to work on it. Help is very much appreciated. I believe the general approach taken in this PR is valid, but it was written as a proof of concept. I'll close this so nobody hesitates to open their own. |
|
Making progress on some prerequisites here |
5 participants
The idea here is that future Nix first tries to "
nix run" thepkg.devShellpackage, and only if that fails, fall back to the legacynix develop(ornix-shell) behavior.This allows the development shell to evolve with stdenv, and it allows packages to individually customize the
devShellattribute, by settingpassthru.devShell.Furthermore, these shell behaviors will be pinned to the expressions, allowing changes to be made in a more agile manner, unlike Nix, which has to be very careful not to break old expressions, as users can not revert Nix.
To give it a try:
In the future this will be equivalent to:
Isn't this the responsibility of Nix?
It is not.
nix-shellandnix developare a great user interface, that everyone loves, but their implementation is a pile of hacks on top of stdenv.Instead of coercing stdenv to do what
nix-shellneeds it to, we can ask stdenv politely to provide a shell.Now that Nix doesn't have to assume a package comes from stdenv, there's a possibility for experimental builders to provide shells too.
What does this break?
Only packages that define a
devShellattribute (for some reason?) have to adapt to the suggested new Nix behavior. Note that adevShellvalue for the builder can be overridden bypassthruwithout affecting the build or shell.Packages and shells pinned to older versions can still be loaded because Nix keeps the legacy behavior as a fallback.
But this still relies on
nix-shellto provide a shell???Fair enough. This is only a proof of concept. The goal is to replace that invocation by a script or program with the same or better behavior, without relying on
nix-shellas its implementation.Does this solve the need for
.envfor Haskell package shells?Not in this commit, but Haskell packages will be able to produce their own
devShellattribute, which is derived from the .env derivation rather than the regular derivation.Refs
getDerivationEnvironmentas a primop to referencenix developdrv from Nix code nix#7468 and a bunch of other issues where I've written about this idea.Description of changes
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes