nix-community / bundix

Generates a Nix expression for your Bundler-managed application. [maintainer=@manveru]
163 stars 55 forks source link

Doesn't work within `nix-store --realize` #54

Closed nyarly closed 5 years ago

nyarly commented 5 years ago

For some time, my .envrcs for Ruby projects have looked something like:

bundix
use nix
watch Gemfile.lock

so that the process of updating my gems reverts to something like the basic Ruby case with bundle lock [--update gem]. This has been great for a long time.

Enter lorri - the downside to my bundle lock solution has been (in part) that the updates are kind of slow, and I get distracted. If lorri could let me keep working while gems update in the background that would be excellent.

However, what I find is a couple of shortcomings - mostly that bundix updates gemset.nix when it's run, which means that lorri constantly reconsiders the directory.

One way to approach this would be to put the bundix step into my shell.nix. This would not be a solution for shipping code, but for developing it would be very natural: building my development environment has the gemset.nix file as a dependency, so it makes sense as an expression in the shell.nix.

However, bundix in the buildPhase of a mkDerivation fails all kinds of ways, because it relies on the kinds of things that the Nix build environment purposely foils - writing to the home directory, to /nix/var, etc.

Would it be possible to have bundix take an --in-nix flag, or flags for it's various paths, or just recognize that it's being run with e.g. NIX_ENFORCE_PURITY=1 and do the right thing?

alyssais commented 5 years ago

Would it be possible to have bundix take an --in-nix flag, or flags for it's various paths, or just recognize that it's being run with e.g. NIX_ENFORCE_PURITY=1 and do the right thing?

How do you imagine Bundix-in-Nix working? It has to download checksums, and you wouldn't know the checksum ahead of time, so you wouldn't be able to use it in a derivation.

nyarly commented 5 years ago

I'm contemplating, effectively, only the nix-shell case - bundix as a buildInput in the nixpkgs repo would be inappropriate.

But for nix-shell, the checksums are recorded in gemset.nix which would be what I'd be using Bundix to produce and then using as an input to a bundlerEnv

As for fetching sources to compute the checksums, IIRC Bundix already fetches the Ruby sources into the /nix/store in order to calculate those digests when it can.

alyssais commented 5 years ago

As for fetching sources to compute the checksums, IIRC Bundix already fetches the Ruby sources into the /nix/store in order to calculate those digests when it can.

Indeed, but when you change the lockfile, it's going to need to fetch new sources, which it isn't going to be able to do inside a derivation because it won't have network access.

Unless I'm misunderstanding what you want to do? If you think that might be the case, perhaps share an example of what you would want your shell.nix to look like?

nyarly commented 5 years ago

Oh, you're right. I forget that "no network access" is part of the build environment. Thanks for the catch.

nyarly commented 5 years ago

@alyssais Are you around somewhere to hash out the larger issue wrt lorri?

alyssais commented 5 years ago

@alyssais Are you around somewhere to hash out the larger issue wrt lorri?

I'm qyliss on Freenode, and I'm in most of the NixOS channels.

alyssais commented 5 years ago

lorri is probably the best place.