¿Entice the developer!

I can see a potent opportunity for wide-spread adoption of nix.

To see it for yourself, those concepts provide helpful context:

Now, should we entice the developer?

An economy fundamentally grows through population multiplied by access to knowledge and resources.

  • sed i/economy/software community/
  • sed i/population/developers/
  • sed i/knowledge/standard tooling/
  • sed i/resources/experience/

Hence, we should entice the developer!

Therefore, let’s prioritize for the future of nix, down-wind of nix flakes inauguration:

  1. nix develop github:foo/bar to become the tooling of choice for developers to setup a universally sharable development & tooling environment for their project.
  2. nix run github:foo/bar to become a natural choice for packaging their application.
  3. nix build github:foo/bar to also generate binaries for X, Y & Z.
  4. The rest.

I wanted to keep this short. Be creative filling in the blank spots on your side!


I have no clue what you are talking about.

Update: the author rephrased his post completely.


I suspect you want to check out Flakes?

1 Like

I believe OP’s attempt to “keep this short” did a great disservice. Anyways a lot of these changes are being implemented in Nix Flakes. You should have a look


I am screaming and waiving hands at flakes, indeed! :wink:

There are a couple of deltas:

  1. nix --help isn’t optimized cli wise. A little better grouping and maybe consolidating some heredary commands behind nix build would be an actionable suggestion.
  2. There is https://builtwithnix.org/ which is absolutely great and polished. Though we need to complement stances like this with a hypothetical developwithnix.org.
  3. Those points are just pars pro toto for a suggested transition to actively try (on all channels) to attract more developers (as oposed to packagers).

It is (or will be) a logical consequence of flakes.

I hope this enigmatic post can promote conscientation about it.

I hope you enjoyed the linked schools of thought and how they affect ecosystem dynamics such as ours.

Some might have also notices between the lines, that this was the cornerstone that catapulted once docker out of the shadows: A greate UX for developers.

EDIT: I remember the docker page of those days around 2013. It looked a little like nixos.org just befor it took off. Is this coincidence? Please say no! :wink:

@zimbatm is doing an incredible move into this direction please have a look at his work (see also history in readme for interesting details):

1 Like

The challenge with mkShel and devshell is the bash first approach; which leads me to reach for something like direnv.

The problem then is i lose the fact that the shellHook is executed each time fresh.
This means I can’t automatically startup required services (redis, postgres) and maybe even shut them down via TRAP; which would be a slick feature.

I think this is too much of an automation in a team environment. — while people might trust their boss, I’m sure a developer at least want’s to be asked if DevOps is remotely taking control of their runtime.

There is the devshell MOTD feature which looks as a great balanced approach to such requirement.

This is an interesting aspect — might warrant an upstream issue with detailed feedback. There is a value in providing a standard e.g. python shell for tinkering in a project setup, besides the bash shell.