[Feature]: `devbox shell -p somepackage`

[altano]

Is your feature request related to a problem you're trying to solve? Please describe. There are too many steps to testing out a package. I potentially potentially have to:

1. devbox init
2. devbox add X
3. devbox shell
4. rm devbox.json ... # maybe cleanup stuff I don't need

Describe the solution you'd like I would like something equivalent to nix-shell -p <package>^1 which allows you to temporarily, on only the current shell, have access to a package. I think the most obvious way to expose this is to have devbox shell take a -p option that allows the same syntax as devbox.json packages, e.g. devbox shell -p [email protected] should work.

Describe alternatives you've considered This doesn't enable anything new. It is just a convenience method.

Additional context This was requested in https://github.com/jetpack-io/devbox/issues/50 but I think that request got misinterpreted as having a way of running a one-off command on a temporary devbox shell and the part about having access to a package got missed.

[Lagoja]

This is interesting, and something we've discussed previously. A few questions for discussion:

1. If you run devbox shell -p in a directory with a devbox.json, would you expect it to apply the devbox.json environment as well?
2. Would this also support creating a shell with multiple packages? (I think so)
3. Would you want this to function like devbox shell, where we leak your current environment variables and shell, or like nix shell, where you get a fully new shell?

[altano]

I think you can make up whatever you want, as the most simple of use-cases (I want a shell with a package and I don't care how I get it) is probably all that is desired most of the time. This feature is dangerous if over-used or relied on too much, so it should very much be a one-off temporary thing.

That said, I'd be happy to tell you what nix-shell does as inspiration:

If you run devbox shell -p in a directory with a devbox.json, would you expect it to apply the devbox.json environment as well?

nix-shell -p inherits the current shell and all available packages (e.g. it continues to use configuration.nix). It is also nestable, unlike devbox shells, so that would be a consideration here (just special case and allow nesting when -p is specified?):

$ which ruby; which python
which: no ruby in ...
which: no python in ...

$ nix-shell -p ruby

$ which ruby; which python
/nix/store/.../bin/ruby
which: no python in ...

$ nix-shell -p python3

$ which ruby; which python
/nix/store/.../bin/ruby
/nix/store/.../bin/python

Would this also support creating a shell with multiple packages? (I think so)

nix-shell -p does allow this (and the full option name is plural: --packages):

$ nix-shell -p ruby python3
$ which ruby; which python;
/nix/store/.../bin/ruby
/nix/store/.../bin/python

Would you want this to function like devbox shell, where we leak your current environment variables and shell, or like nix shell, where you get a fully new shell?

I don't have a use-case that cares so I won't state my arbitrary preference.

[Akiyamka]

Cool feature! Sometimes I need to build some utility from an open repository that requires rust, or golang of a certain version. Since these dependencies are needed only once, it would be very convenient to specify the packages at once without creating a devbox file.

If you run devbox shell -p in a directory with a devbox.json, would you expect it to apply the devbox.json environment as well?

Not my case, these projects don't have devbox.json (yet ;- )

Would this also support creating a shell with multiple packages? (I think so)

Sure

Would you want this to function like devbox shell, where we leak your current environment variables and shell

I think yes

[Lagoja]

Related to #1275

[wrdls]

I created the following in my .zshrc

dbe () {
        local pkgs="$@" 
        [ -z "$pkgs" ] && printf "dbe: missing argument.\nUsage: dbe PKG1 PKG2 ...\n" && return 255
        local pkgs_sha256=$(echo "$pkgs" | sort | sha256sum | awk '{print $1}') 
        local configdir="${HOME}/.cache/devbox/ephemeral/${pkgs_sha256}" 
        mkdir -p "$configdir"
        devbox init "$configdir"
        devbox add -c "$configdir" $pkgs
        devbox shell -c "$configdir"
}

(dbe = DevBox Ephemeral)

E.g.

dbe [email protected]

My main use-case for this is a Terraform repository with a bunch of projects with different Terraform versions. Devbox is not widely used in my company yet, so I also don't want to pollute the repository.

[pomdtr]

Another usecase: I would love to use devbox for writing portable scripts (by leveraging shebangs).

See https://yukiisbo.red/notes/spice-up-with-nix-scripts/

[altano]

Wow I love that use case.

[kadaan]

See https://pkgx.sh/ for inspiration.

[djgoku]

Another usecase: I would love to use devbox for writing portable scripts (by leveraging shebangs).

See https://yukiisbo.red/notes/spice-up-with-nix-scripts/

https://nixos.wiki/wiki/Nix-shell_shebang

[Sheemap]

I'm also very interested in this sort of nix-shell -p ephemeral package management.

We are using devbox in a monorepo, and it has been really great, but we have some dev tools we use that take a long time to build, it slows down the initial load by 5-10 mins depending on the computer's resources. But those dev tools are only needed for a few specific use-cases, and most often it ends up being just wasted time.

I would love if there could somehow be a central core list of packages that are installed, and then a way to add on-demand packages for specific commands.

That way a dev only needs to incur the build cost of those tools if they actually need to use them.

It would also help in a CI use case. Where maybe not all the packages are needed for the specific CI task (linting, testing, etc). Right now each step still needs to build all the dependencies for the env. Which can be quite slow if its not cached.

I would be open to helping contribute time and resources to pushing this forward. Whats needed to advance this feature request?