flakes: rename devShell to developPackages #3833

Mic92 · 2020-07-18T08:03:05Z

The cli was changed but not the flake format.
It's not clear to a user that both names belong together.

zimbatm · 2020-07-20T11:41:49Z

flake.nix

@@ -414,7 +414,7 @@

      defaultPackage = forAllSystems (system: self.packages.${system}.nix);

-      devShell = forAllSystems (system:
+      developPackages = forAllSystems (system:


Suggested change

developPackages = forAllSystems (system:

developPackage = forAllSystems (system:

This should be singular as there is a single value per system available.

zimbatm · 2020-07-20T11:42:47Z

src/nix/flake.cc

-                        else if (name == "defaultPackage" || name == "devShell") {
+                        else if (name == "defaultPackage" || name == "developPackages" || name == "devShell") {
+                            if (name == "devShell") {
+                                warn("flake output 'devShell' is deprecated. Use by 'developPackages' instead");


Suggested change

warn("flake output 'devShell' is deprecated. Use by 'developPackages' instead");

warn("flake output 'devShell' is deprecated. Use 'developPackages' instead");

edolstra · 2020-07-20T11:49:04Z

While devShell is not a great name, I'm not convinced developPackage is better:

It's not a package, it's a derivation that configures a development environment. In fact there is no requirement that devShell actually builds, let alone produces a package.
I have trouble parsing developPackage. Is develop short for development, or is it a verb in the imperative tense?

Maybe we want something like developmentEnvironment?

Kloenk · 2020-07-20T11:52:38Z

Maybe we want something like developmentEnvironment?

I think that's a rather long name. Non native English speaker could have a problem spelling that.

Mic92 · 2020-07-20T12:06:33Z

Maybe we want something like developmentEnvironment?

I think that's a rather long name. Non native English speaker could have a problem spelling that.

I don't think so, both words are quite common in IT/English. Someone who has trouble spelling this out will have problems understanding the nix manual in the first place.

zimbatm · 2020-07-20T12:16:41Z

Actually, we are making the same mistake again and conflating the various use-cases, just like nix-shell.

nix develop right now is similar to nix-shell in that it loads the various inputs of a derivation amd creates an environment to debug that package. In that regard, devShell should be dropped entirely and use the defaultPackage only.

Then there is another use-case, which is to create a development environment for a repository. This is related but not entirely the same thing. Usually, in my experience, the development doesn't care about making build phases available to the user. The main facility is to bring the compilers, interpreters, linting tools, ... and add them to the PATH. Then there might be some other environment variable being set, but those are development specific (instead of package-specific).
That repository might be a monorepo with many languages and packages, so nix develop is not good enough.

For that reason, I would propose to deprecate devShell simply, and then come up with a better solution for the second case.

Mic92 · 2020-07-20T12:21:18Z

Actually, we are making the same mistake again and conflating the various use-cases, just like nix-shell.

nix develop right now is similar to nix-shell in that it loads the various inputs of a derivation amd creates an environment to debug that package. In that regard, devShell should be dropped entirely and use the defaultPackage only.

Then there is another use-case, which is to create a development environment for a repository. This is related but not entirely the same thing. Usually, in my experience, the development doesn't care about making build phases available to the user. The main facility is to bring the compilers, interpreters, linting tools, ... and add them to the PATH. Then there might be some other environment variable being set, but those are development specific (instead of package-specific).
That repository might be a monorepo with many languages and packages, so nix develop is not good enough.

For that reason, I would propose to deprecate devShell simply, and then come up with a better solution for the second case.

What would this look like? Is mkShell not the appropriate replacement for it, it comes without build phases.

blaggacao · 2020-07-20T12:31:44Z

I totally agree with @zimbatm the help text of nix develop tells tales. -> nix hack? It's not a descriptive name but aligned with intention.

There is also a ambiguity on the nix develop side of the cli.

nix hack ./myproject -> I want to hack on "myproject"
nix develop ./myproject -> I want to develop on "myproject".

What's the difference? Since we agree it's not the same.

In my opinion, nix has strong use cases beyond the well-contextualized nix community. So nix develop might be just plain confusing.

7c6f434c · 2020-07-20T12:34:47Z

> > Maybe we want something like `developmentEnvironment`? > > I think that's a rather long name. Non native English speaker could have a problem spelling that. I don't think so, both words are quite common in IT/English. Someone who has trouble spelling this out will have problems understanding the nix manual in the first place.

Well, being comfortable with typing an un-spell-checkable combination of two long words and being comfortable reading long-form texts might be correlated but are distinct things

edolstra · 2020-07-20T12:53:32Z

That repository might be a monorepo with many languages and packages, so nix develop is not good enough.

I'm not following, why would nix develop have a problem with having many languages and packages?

For that reason, I would propose to deprecate devShell simply, and then come up with a better solution for the second case.

Let's not deprecate things until we have something beter. Hopefully flake.toml will give us a more declarative way to specify developer environments without all the cruft like derivations and build phases.

So nix develop might be just plain confusing.

There is no perfect terminology but nix hack is just as confusing if not more so. nix develop conveys that it's intended to set up a development environment (unlike say nix shell or nix run).

blaggacao · 2020-07-20T13:03:48Z

nix develop conveys that it's intended to set up a development environment

Totally agree! I just was giving the code priority when interpreting, see:
https://github.com/NixOS/nix/blob/master/src/nix/develop.cc#L261

That description ought to be fixed then so it's crystal clear to the world:

nix develop ./myproject sets up a development Environment for myproject, where myproject is considered an arbitrary entity not specifically connected to nix, hence: without "the cruft".

Mic92 · 2020-07-20T13:16:32Z

So should I just rename it to developmentEnvironment now?

blaggacao · 2020-07-20T13:24:48Z

Maybe the develop command needs to be fixed first to concisely clarify it's semantics. Then this one can comply. Right now, it's not clear with what ultimate intepretation to comply with.

Mic92 · 2020-07-25T21:20:07Z

Maybe the develop command needs to be fixed first to concisely clarify it's semantics. Then this one can comply. Right now, it's not clear with what ultimate intepretation to comply with.

This sounds more like a different PR to add documentation to nix develop. It's in fact just the flake version of nix-shell.

The cli was changed but not the flake format, which makes it consistent for the user that the both are linked together.

Mic92 · 2020-07-25T21:30:19Z

I renamed it to developmentEnv. It's not as horrible long as developmentEnvironment and env should be a pretty common abbreviation of environment (i.e. direnv or setenv(3)

Mic92 · 2020-07-25T21:35:58Z

Actually, we are making the same mistake again and conflating the various use-cases, just like nix-shell.

nix develop right now is similar to nix-shell in that it loads the various inputs of a derivation amd creates an environment to debug that package. In that regard, devShell should be dropped entirely and use the defaultPackage only.

Then there is another use-case, which is to create a development environment for a repository. This is related but not entirely the same thing. Usually, in my experience, the development doesn't care about making build phases available to the user. The main facility is to bring the compilers, interpreters, linting tools, ... and add them to the PATH. Then there might be some other environment variable being set, but those are development specific (instead of package-specific).
That repository might be a monorepo with many languages and packages, so nix develop is not good enough.

For that reason, I would propose to deprecate devShell simply, and then come up with a better solution for the second case.

I think the problem here is what people put in developmentEnv. I think it's still possible to put a new abstraction behind this attributes that not just loads stdenv but instead export saner environment variables. We don't have this abstraction yet but I don't see how it's appearance would conflict with the current flake format in a backwards-incompatible way.

blaggacao · 2020-07-25T21:43:10Z

I was pondering on the two use cases a little during the last days, with no constraints or holy cows.

This is where my mind drifted towards: https://discourse.nixos.org/t/entice-the-developer/8310

zimbatm · 2020-07-26T09:01:45Z

I think I'd rather keep devShell for now. developmentEnv doesn't map 1:1 to nix develop so it's not a marked improvement.

Mic92 force-pushed the develop-packages branch 3 times, most recently from 22331d8 to ddb63cd Compare July 18, 2020 08:07

zimbatm reviewed Jul 20, 2020

View reviewed changes

rename devShell to developmentEnv

c3244cf

The cli was changed but not the flake format, which makes it consistent for the user that the both are linked together.

Mic92 force-pushed the develop-packages branch from ddb63cd to c3244cf Compare July 25, 2020 21:26

Mic92 closed this Jul 27, 2020

Mic92 deleted the develop-packages branch April 1, 2021 08:19

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

flakes: rename devShell to developPackages #3833

flakes: rename devShell to developPackages #3833

Mic92 commented Jul 18, 2020 •

edited

zimbatm Jul 20, 2020 •

edited

zimbatm Jul 20, 2020

edolstra commented Jul 20, 2020

Kloenk commented Jul 20, 2020

Mic92 commented Jul 20, 2020

zimbatm commented Jul 20, 2020 •

edited

Mic92 commented Jul 20, 2020 •

edited

blaggacao commented Jul 20, 2020 •

edited

7c6f434c commented Jul 20, 2020 via email

edolstra commented Jul 20, 2020

blaggacao commented Jul 20, 2020 •

edited

Mic92 commented Jul 20, 2020

blaggacao commented Jul 20, 2020 •

edited

Mic92 commented Jul 25, 2020 •

edited

Mic92 commented Jul 25, 2020

Mic92 commented Jul 25, 2020

blaggacao commented Jul 25, 2020

zimbatm commented Jul 26, 2020

	developPackages = forAllSystems (system:
	developPackage = forAllSystems (system:

	warn("flake output 'devShell' is deprecated. Use by 'developPackages' instead");
	warn("flake output 'devShell' is deprecated. Use 'developPackages' instead");

flakes: rename devShell to developPackages #3833

flakes: rename devShell to developPackages #3833

Conversation

Mic92 commented Jul 18, 2020 • edited

zimbatm Jul 20, 2020 • edited

Choose a reason for hiding this comment

zimbatm Jul 20, 2020

Choose a reason for hiding this comment

edolstra commented Jul 20, 2020

Kloenk commented Jul 20, 2020

Mic92 commented Jul 20, 2020

zimbatm commented Jul 20, 2020 • edited

Mic92 commented Jul 20, 2020 • edited

blaggacao commented Jul 20, 2020 • edited

7c6f434c commented Jul 20, 2020 via email

edolstra commented Jul 20, 2020

blaggacao commented Jul 20, 2020 • edited

Mic92 commented Jul 20, 2020

blaggacao commented Jul 20, 2020 • edited

Mic92 commented Jul 25, 2020 • edited

Mic92 commented Jul 25, 2020

Mic92 commented Jul 25, 2020

blaggacao commented Jul 25, 2020

zimbatm commented Jul 26, 2020

Mic92 commented Jul 18, 2020 •

edited

zimbatm Jul 20, 2020 •

edited

zimbatm commented Jul 20, 2020 •

edited

Mic92 commented Jul 20, 2020 •

edited

blaggacao commented Jul 20, 2020 •

edited

blaggacao commented Jul 20, 2020 •

edited

blaggacao commented Jul 20, 2020 •

edited

Mic92 commented Jul 25, 2020 •

edited