Incorrect working directory using "devbox run"

[joefiorini]

What happened?

I'm trying to use process-compose to run a few apps inside a monolith along with some individual microservices. The microservices work fine, but the monolith apps don't work with devbox run because the command passed to devbox run inherits the devbox project's root as the working dir rather than the directory you are actually running the command from.

Eg. I have a project in frontends/web and my process-compose.yml looks like:

web:
  command: devbox run npm start
  working_dir: /path/to/monolith/frontends/web

But the command fails saying:

ENOENT: no such file or directory, open '/path/to/monolith/package.json'

I would expect that the command would still run inside the specified working directory but still using the environment setup by devbox.

Steps to reproduce

I have a repo you can use here, instructions in the readme: https://github.com/joefiorini/devbox-working-dir-repro

Command

run

devbox.json

{
  "$schema":  "https://raw.githubusercontent.com/jetify-com/devbox/0.10.7/.schema/devbox.schema.json",
  "packages": ["nodejs@latest"],
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!' > /dev/null"
    ],
    "scripts": {
      "test": [
        "echo \"Error: no test specified\" && exit 1"
      ]
    }
  }
}

Devbox version

0.12.0

Nix version

2.21.2

What system does this bug occur on?

macOS (Apple Silicon)

Debug logs

No response

[joefiorini]

It looks like the problem may be here. Could this check if the current working dir is a child of the devbox and if so don't set the working dir?

[Allsimon]

You can fix it by using the DEVBOX_PROJECT_ROOT env variable

web:
  command: devbox run npm start
  working_dir: ${DEVBOX_PROJECT_ROOT}/path/to/monolith/frontends/web

[joefiorini]

Sorry for my delay in replying here, and thanks for the suggestion @Allsimon, but I'd like to find a solution that makes devbox transparent. I'm trying to build a cli to assist with running our non-trivial architecture locally and I shouldn't need to require devbox. Also, this appears to be something specific to devbox breaking behavior of process-compose.

[az-wegift]

devbox shell inherits the current directory, which is convenient. devbox run having a different behaviour is quite surprising and very disappointing, because that's the devbox run command is what I would use being in a child directory. My use case:

.
├── service1
│   ├── proj1
│   │   └── pyproject.toml
│   └── proj2
│       └── pyproject.toml
└── deployment
        └── main.tf

Working in /service1/proj1 I'd invoke devbox run poetry run pytest which runs just tests for proj1. In /deployment I have some Terraform stuff, so in that directory I'd call devbox run terraform apply. devbox run not respecting the current directory feels pretty useless.

[savil]

Thanks for the feedback on this. We fixed the working directory for devbox run to be the project-root folder so that scripts invoked by it run more deterministically. Prior to that fix, many users would run into bugs. Changing this behavior at this point would break a lot of users.

For the process-compose, i.e. npm install scenario, the upcoming Devbox version 0.13.0 will introduce DEVBOX_WD env var and you can do devbox run cd $DEVBOX_WD && npm install

For the python/terraform monorepo scenario, we can also consider introducing a --wd flag, so it can be devbox run --wd terraform apply in a future devbox version. It is a bit cumbersome, so one could then define something like alias devbox-cmd='devbox run --wd' to help. Alternatively, consider working inside a devbox shell or (even better IMO) using direnv so that you can be in some child directory and directly call poetry run pytest or terraform apply.

[az-wegift]

Thanks for the explanation. I understand that flipping the default behaviour now would be terrible. The --wd option (or make it even shorter -w) would be great. Perhaps the behaviour could alternatively be configurable in devbox.json?

Could you elaborate more on using the direnv, please?

[savil]

@az-wegift direnv is a shell utility that lets one modify the shell environment when cd-ing into a directory. It'll undo the modifications when moving out of the directory.

So, once direnv is setup on your system, you can configure devbox to work with it (see https://www.jetify.com/devbox/docs/ide_configuration/direnv/). Then, as you navigate (cd) into the directory the "devbox shell" environment will get set up giving you access to the packages and the env-vars from the devbox.json.

In your scenario, once this is set up, if you are in a child dir like deployment you can directly invoke terraform apply without the devbox run

[az-wegift]

Perfect, thank you, @savil!