search

numtide / devshell

Per project developer environments
https://numtide.github.io/devshell/
MIT License
1.17k stars 86 forks source link

Preserve system bash prompt and configuration for non-pure devshells #101

Open mayl opened 3 years ago

mayl commented 3 years ago

I have an interactive bash prompt which is configured to my liking - starship.rs, fzf integration, git aliases, z-lua, etc.

With a normal nixpkgs.mkShell I can enter a project shell without --pure and keep my system settings with me. However, devshell seems to override all these. I want access to my bash configuration and tools when working on a project, but it wouldn't be appropriate to burden my devshell with them since they are strictly speaking not project dependencies.

Is there a way to get devshell mirror the behavior of nixpkgs.mkShell when run without the --pure flag?

Edit: I spoke a bit too soon, looks like git aliases actually do persist as expected. The other comments still seem valid however.

zimbatm commented 3 years ago

Related issue https://github.com/numtide/devshell/issues/26

How are you loading the environment. Using nix-shell?

mayl commented 3 years ago

It's a little complicated, there is some more context here.

As a brief summary, I'm building my devshell as part of a nixos-generators vagrant-virtualbox machine for offline use. I've been using writeShellScriptBin just to give my devshell a memorable name and adding that to environment.systemPackages. I run that script to enter the devshell environment. I'm certainly not wedded to this approach if something better is available, but I do need a way to build nix-shell environments ahead of time and then use them in an offline environment and prefer to do it in a declarative way which is compatible with nixos-generators

blaggacao commented 3 years ago

I'll try to figure out a solution tomorrow. This also annoys me (using nix develop / zsh). #26 has a pending fix for review, which lead me to believe the solution for this issue here can't be far away, either.

Regardless of how the devshell would be invoked, for CI we could detect either a CI=true (most CIs) or a PURE=true and switch to pure eval, there.

Reading again through https://blog.flowblok.id.au/2013-02/shell-startup-scripts.html ...

The good thing is from a devshell perspective we don't need to care about login shells altogether. We can also safely assume that any non-interactive shell is meant to be pure (or we can establish that restriction). So we are left with the interactive/non-login shell path on which we need o overlay the devshell enviroent. As if the path had a final ./devshellrc that was hit before enter the running state. (That's in a way what devshell does).

mayl commented 3 years ago

FWIW, my preference would still be to not have devshell enforce a particular prompt. For instance, I use starship for my prompt which among other things has support for nix-shell.