examples: add simple pip devShell example

[zackattackz]

To test, navigate to the python-devShell-hello directory and run nix develop .#devShells.x86_64-linux.hello. You will drop into a dev shell with python3.10 and pip package cryptography 41.0.5 available.

I wanted to include an example to showcase the devShell attribute of a dream2nix package. Specifically with pip module, though it should be possible to do this with more modules.

I am open to any critiques as I am unsure myself if this is the best way to go about accomplishing this.

Thank you!

[zackattackz]

oh no there are some buildbot fails, will look into them but am unsure of them. I think I need to properly format my files? Any advice appreciated.

[DavHau]

Just run 'nix fmt'

[zackattackz]

After looking into it further, I don't think that this example is allowable into the repo.

I say this because of this buildbot check https://buildbot.nix-community.org/#/builders/222/builds/2

It is expecting each of the example flakes to have an output packages.${system}.default which should evaluate to a package. But my flake just outputs the lock and the devShell specifically.

So maybe I should put my example in a seperate area of examples/?

Or is there some workaround.

My original thinking with only exposing devShell and lock was that because I sort of use a hack with

mkDerivation = {
  src = ./.;
};

which would normally cause an error when you try to use the package itself returned by dream2nix.lib.evalModules

So I only want to expose the devShell and the lock to prevent that possible "misuse".

Either way, I am curious on your thoughts of the "hack"

[zackattackz]

Hi @DavHau ! I see this module nodejs-devshell-v3 has been added in this commit c25e889
Does this mean we could expect a similar module for pip in the future? If you are not planning on creating it yourself, is it a feature you would like someone to open a PR for? I haven't read the full code yet of that new module, but it seems like a better idea to make an explicit devshell module for pip rather than "hack" it like I have done. I'd be interested in creating that module if you were not already working on it.

Thanks :)

[DavHau]

I'm not sure to be honest. What we don't want for sure is having two separate dependency specifications or two separate lock files. If we make it individul modules we kind of rely on the user to set the options for dependencies correctly. Though there is a use case where one wants only a dev shell but not a package and that should be covered.

[zackattackz]

I feel like a good usage interface could be to clearly expose the lock-file-parsing parts of the modules that deal with them from the dream2nix library. Something like evalModules but it only works on the lock file level? This way (in my use case) I could just have a repository of lock files representing different versions of dependencies I need, and a flake that just calls that "parseLock" function to get the devShell. parseLock could return other things as well. Idk if this could possibly work, given that more information may be needed at build time such as the drv overrides and stuff, so maybe you'd also have to supply that information too.

[zackattackz]

Though I'm not sure the utility of this as opposed to just doing the "hack". Because the hack honestly works fine too, you just have to explicitly not expose the package just the devshell/lock. Instead of a "parseLock", there could just be a wrapper around evalModules that only exposes "meta" things like .lock, .devShell, maybe other things too that I'm unaware of.

Or alternatively, just add a warning/error that warns you if you try to use the package without a proper mkDerivation. So you can still use the non package things like devShell but the moment you try to evaluate the package you get a descriptive error instead of a vague one

[yajo]

each of the example flakes to have an output packages.${system}.default which should evaluate to a package

What about adding a default package that is just a runCommand that runs inside the devshell environment and checks that cryptography is installed from nix and hello is installed in editable mode?

[zackattackz]

@yajo That is a good idea I think. I'm unware of editable packages though, still fairly new to nix. Could you please link some documentation if you have the time? I could only find some information about this for python packages (NixOS/nixpkgs#11957) but I'm unsure about it.

[yajo]

Well, the common way of developing python projects is to run pip install -e . from inside a venv. That should pull all dependencies, install them in the venv, and then install the local project in editable mode (which means that you can change it live and all the libs and bins installed by the package will get those changes without having to reinstall).

In a dream2nix devshell I'd expect the same to happen. But for that, the shell should run --impure. So, maybe it's not so easy to test in CI...