New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mkShell: add builder #30975

Merged
merged 1 commit into from Dec 20, 2017

Conversation

Projects
None yet
7 participants
@zimbatm
Member

zimbatm commented Oct 30, 2017

Motivation for this change

For nix-shell-only scenarios, this is a small optimization to make it nicer such that:

{ pkgs ? import <nixpkgs> {} }:
pkgs.stdenv.mkDerivation {
  name = "forced-to-add-but-i-dont-care";
  src = null; # irrelevant
}

Is simplified to:

{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell { }

It also fails when trying to build it directly:

$ nix-build shell.nix
...
This derivation is only meant to be used in nix-shell, aborting
...

And finally, it supports the scenario where one wants to compose the shell with different inputs from various packages:

{ pkgs ? import <nixpkgs> {}}:
pkgs.mkShell {
  mergeInputs = [ pkgs.hello pkgs.gnutar ];
}
@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Oct 30, 2017

Member

For now I am looking for feedback on the following things:

  • should the shellHooks be merged as well?
  • where should I put the documentation for that?
  • is there any other kind of feature that you often use in your shells?
Member

zimbatm commented Oct 30, 2017

For now I am looking for feedback on the following things:

  • should the shellHooks be merged as well?
  • where should I put the documentation for that?
  • is there any other kind of feature that you often use in your shells?
@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Oct 30, 2017

Member

It would be nice if the shellHooks where composable

Member

zimbatm commented Oct 30, 2017

It would be nice if the shellHooks where composable

@gilligan

This comment has been minimized.

Show comment
Hide comment
@gilligan

gilligan Oct 30, 2017

Contributor

@zimbatm Could you also add documentation to the manual for this?

Edit: I see you asked where to document.. good question ;-)

Contributor

gilligan commented Oct 30, 2017

@zimbatm Could you also add documentation to the manual for this?

Edit: I see you asked where to document.. good question ;-)

@gilligan

This comment has been minimized.

Show comment
Hide comment
@gilligan

gilligan Nov 8, 2017

Contributor

bump - i would love to see this merged. What's the status?

Contributor

gilligan commented Nov 8, 2017

bump - i would love to see this merged. What's the status?

Show outdated Hide outdated pkgs/top-level/all-packages.nix Outdated
@avnik

This comment has been minimized.

Show comment
Hide comment
@avnik

avnik Nov 9, 2017

Contributor

Nice,
can it be a base for myEnvFun replacement?

Contributor

avnik commented Nov 9, 2017

Nice,
can it be a base for myEnvFun replacement?

@zimbatm zimbatm merged commit adc5c9b into master Dec 20, 2017

@zimbatm zimbatm deleted the mkShell branch Dec 20, 2017

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Dec 20, 2017

Member

I realize that the doc needs to be improved, will do another round tomorrow.

Member

zimbatm commented Dec 20, 2017

I realize that the doc needs to be improved, will do another round tomorrow.

@vaibhavsagar

This comment has been minimized.

Show comment
Hide comment
@vaibhavsagar

vaibhavsagar Jan 19, 2018

Contributor

Is this coming to nixos-17.09?

Contributor

vaibhavsagar commented Jan 19, 2018

Is this coming to nixos-17.09?

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Jan 19, 2018

Member

This is a new feature so it will land in 18.04

Member

zimbatm commented Jan 19, 2018

This is a new feature so it will land in 18.04

@CMCDragonkai

This comment has been minimized.

Show comment
Hide comment
@CMCDragonkai

CMCDragonkai Jul 5, 2018

Contributor

The inputsFrom is so intriguing.

I'm wondering if one major usecase is say you have multiple projects each with their own shell.nix, and you could create 1 master shell.nix that merges all subproject's shell.nix in case you wanted to work on all the subprojects together.

@zimbatm Could you enumerate what other usecases you envision for inputsFrom?

Also with regards to merging shell hook, this is definitely something that would be cool as well as long as the shell hooks were written in a way that didn't conflict with each other. My project's shell hook tends to be creating relevant environment variables. So they could be automerged. However I'd imagine in some cases you wouldn't want to auto merge them. Maybe some function that can explicitly compose the shell hooks based on the inputsFrom.

Contributor

CMCDragonkai commented Jul 5, 2018

The inputsFrom is so intriguing.

I'm wondering if one major usecase is say you have multiple projects each with their own shell.nix, and you could create 1 master shell.nix that merges all subproject's shell.nix in case you wanted to work on all the subprojects together.

@zimbatm Could you enumerate what other usecases you envision for inputsFrom?

Also with regards to merging shell hook, this is definitely something that would be cool as well as long as the shell hooks were written in a way that didn't conflict with each other. My project's shell hook tends to be creating relevant environment variables. So they could be automerged. However I'd imagine in some cases you wouldn't want to auto merge them. Maybe some function that can explicitly compose the shell hooks based on the inputsFrom.

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Jul 5, 2018

Member

Yes that's exactly the use-case that I had in mind. Imagine you have a monorepo with multiple services, each in their own folder with their own default.nix that you can nix-shell and nix-build. On the top-level you can then add a shell.nix with, mkShell { inputsFrom = [ serviceA serviceB ]; to pull all the dependencies together.

shellHooks are a bit more tricky because they also tend to assume things about $PWD. For example if you have a node package it might add $PWD/node_modules/.bin to the PATH. But that only works if you start the shell within the frontend service for example.

Member

zimbatm commented Jul 5, 2018

Yes that's exactly the use-case that I had in mind. Imagine you have a monorepo with multiple services, each in their own folder with their own default.nix that you can nix-shell and nix-build. On the top-level you can then add a shell.nix with, mkShell { inputsFrom = [ serviceA serviceB ]; to pull all the dependencies together.

shellHooks are a bit more tricky because they also tend to assume things about $PWD. For example if you have a node package it might add $PWD/node_modules/.bin to the PATH. But that only works if you start the shell within the frontend service for example.

@CMCDragonkai

This comment has been minimized.

Show comment
Hide comment
@CMCDragonkai

CMCDragonkai Jul 7, 2018

Contributor

How should mkShell be used in comparison to higher order shell functions like haskell.lib.buildStackProject or pythonPackages.buildPythonApplication that already set things up relevant to stack or python build environment? Could potentially mkShell be used to eventually compose a stack and python environment together in case you're working with Python and Haskell at the same time?

Contributor

CMCDragonkai commented Jul 7, 2018

How should mkShell be used in comparison to higher order shell functions like haskell.lib.buildStackProject or pythonPackages.buildPythonApplication that already set things up relevant to stack or python build environment? Could potentially mkShell be used to eventually compose a stack and python environment together in case you're working with Python and Haskell at the same time?

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Jul 7, 2018

Member

I don't have a satisfying answer and would be interested in figuring this out. Aside from changing the PATH it's going to be hard to prove that two shells are going to compose nicely and that the application is commutative.

One idea is to require each environment to provide a function that takes the project root as an argument. Eg: nodePackage.shellHook could be executed to be setup for the $PWD/frontend. But then it doesn't work if there are two nodejs projects in the same repo.

For now I just use mkShell to pull project-global dependencies like deployment tooling and when the $language build tools can just be imported into the PATH and knows how to do the right thing based on $PWD alone. And if necessary I compose the things by hand by writing my own shellHook. It's more work but also creates less surprises in the event of a nixpkgs update.

Member

zimbatm commented Jul 7, 2018

I don't have a satisfying answer and would be interested in figuring this out. Aside from changing the PATH it's going to be hard to prove that two shells are going to compose nicely and that the application is commutative.

One idea is to require each environment to provide a function that takes the project root as an argument. Eg: nodePackage.shellHook could be executed to be setup for the $PWD/frontend. But then it doesn't work if there are two nodejs projects in the same repo.

For now I just use mkShell to pull project-global dependencies like deployment tooling and when the $language build tools can just be imported into the PATH and knows how to do the right thing based on $PWD alone. And if necessary I compose the things by hand by writing my own shellHook. It's more work but also creates less surprises in the event of a nixpkgs update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment