Add packages to PATH

[rcrowe]

After installing packages make them available to further steps below after installing devbox.
https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#adding-a-system-path

When using actions that rely on finding a binary on the path, you can't enable the shell or run devbox run, this option makes every installed binary available on your $PATH.

Wasn't 100% sure on the naming, feel free to tweak if you see fit.

[LucilleH]

Should we do this by default? Is there a downside to it? cc @savil thoughts?

[mikeland73]

I'm not sure we can do it by default because some packages may not work if the environment is not set.

A few alternatives:

• Keep this PR as is with the caveat that some packages may not work.
• Add new run field to the action that runs in a devbox shell.
• export the entire devbox environment into github action environment? (not sure if this is possible)
• Add eval "$(devbox shellenv)" before other normal run` commands. (@rcrowe this should work for you without any action changes)

If possible I think the best solution is exporting entire environment (PATH and other env vars), but this PR is OK as a middle step as well.

[rcrowe]

Thanks for the comments.

I need to double check the eval suggestion as I thought I'd tried that, but each step is running in an isolated shell, it's very likely I just misconfigured something so will check.

My motivation for raising this PR was to find a way for a more out of the box experience. As you install things with the action but still have to go tweaking other things to make use of it.

[LucilleH]

I wonder if there's a way to add eval "$(devbox shellenv --config=<dir>)" in the rc file of the runner, so that each subsequent step gets the devbox environment automatically? But then, since the shells are all non-interactive, that wouldn't work? 🤔

[nbasov]

Hello! Thank you for researching this problem! Just want to share my solution:

- name: Configure devbox
  run: |
    eval "$(devbox shellenv)"
    printenv >> $GITHUB_ENV

[mikeland73]

Would simply doing run: devbox shellenv >> $GITHUB_ENV work as well?

[mikeland73]

btw, I'm 100% in favor of doing this. It's a breaking change, but since we're still on major version 0 that's ok?

[gcurtis]

I think just setting the PATH will be a little fragile now that wrappers have been removed. Some packages depend on other environment variables and will fail in weird ways if they're missing. For example Python might need PYTHONPATH and the gcc wrapper will need NIX_LDFLAGS to find libraries.

Exporting everything to GITHUB_ENV sounds like the way to go, but we might need to do a bit of tweaking to get the syntax right. Namely:

• If I recall, the lines in $GITHUB_ENV can't have quoted values because they don't get reinterpreted by the shell. So echo 'FOO="bar"' >> $GITHUB_ENV is like doing setenv("FOO", "\"bar\"").
• Multi-line values need to be handled (I think Nix does set some of these).

[gcurtis]

We'll also need to make sure that the devbox shellenv output doesn't have arbitrary shell commands.

[altano]

eval $(devbox shellenv) doesn't work with Devbox's corepack virtual environment. devbox shellenv doesn't do anything with the corepack virtenv directory, so your package manager won't be on your path. I think that somehow comes from devbox global shellenv (even though corepack is not global!).