I’ve been having issues running

pants package ::

inside of a devcontainer, and haven’t been able to find an issue report online yet. I’ve got a simple sample repo up on my public Github that repros this issue: https://github.com/natehardison/pants-test. When building a PEX binary, I run into the following permissions error. Looks like one of the directories in the lmdb_store isn’t writable. If I manually add the permissions, then packaging succeeds. For larger projects, I may get multiple permissions issues and have to go in and chmod everything before it works.

vscode ➜ /workspaces/pants-test (main) $ pants package ::
18:55:09.95 [WARN] No requirements defined in any Poetry dependency groups, tool.poetry.dependencies and tool.poetry.dev-dependencies in pyproject.toml, which is loaded by Pants from a poetry_requirements macro. Did you mean to populate these with requirements?
18:55:12.97 [INFO] Completed: Building local_dists.pex
18:55:13.91 [INFO] Completed: Building .pex
18:55:13.93 [ERROR] 1 Exception encountered:

Engine traceback:
  in `package` goal

IntrinsicError: Error setting permissions on /home/vscode/.cache/pants/lmdb_store/immutable/files/71/714b08b6246a1d98708bc75c609c41077f5051c32c79b4130e9cbb3fab80d26a: Permission denied (os error 13)
vscode ➜ /workspaces/pants-test (main) $ ls -l /home/vscode/.cache/pants/lmdb_store/immutable/files/71/714b08b6246a1d98708bc75c609c41077f5051c32c79b4130e9cbb3fab80d26a
-r-xr-xr-x 1 vscode vscode 655665 Mar  8 18:59 /home/vscode/.cache/pants/lmdb_store/immutable/files/71/714b08b6246a1d98708bc75c609c41077f5051c32c79b4130e9cbb3fab80d26a
vscode ➜ /workspaces/pants-test (main) $ chmod +w /home/vscode/.cache/pants/lmdb_store/immutable/files/71/714b08b6246a1d98708bc75c609c41077f5051c32c79b4130e9cbb3fab80d26a
vscode ➜ /workspaces/pants-test (main) $ pants package ::
19:00:18.92 [INFO] Wrote dist/.pex

If I go and change any of the source, the issue returns, so a one-time chmod of the directory doesn’t fix things. Adding

--print-stacktrace

and

-ldebug

doesn’t yield much more info; points to issue in `<pants native internals>`:

$ pants --print-stacktrace -ldebug package ::
19:15:39.72 [ERROR] 1 Exception encountered:

Engine traceback:
  in select
    ..
  in pants.core.goals.package.package_asset
    `package` goal

Traceback (no traceback):
  <pants native internals>
Exception: Error setting permissions on /home/vscode/.cache/pants/lmdb_store/immutable/files/0a/0ae72d1c39362b5b00dfdf6ff084e812c2a4490d4015b376e7e2ab6c0d8b98a2: Permission denied (os error 13)

Please let me know any pointers on things to try; also happy to file an issue in GitHub if that’s preferred.

Hmm, I'm not a vscode user so I know ~nothing about devcontainers. But does this all work if you run it natively? And what is that native platform?

As a sanity, have you tried changing cache dirs? https://www.pantsbuild.org/2.18/docs/using-pants/troubleshooting-common-issues#how-to-change-your-cache-directory

Yeah, all works natively (macOS 14.3.1). All other goals work fine in the devcontainer too (lint, check, test, etc.) so it’s just package. README added. Assuming you have Docker Desktop running then when you open a repo with a

.devcontainer/

directory in VSCode, VSCode will automatically prompt you to reopen the folder in a devcontainer — it invokes Docker to build and start the container and does all of the mounting. So repro is as simple as: 1. Ensure Docker running 2. Clone repo 3. Open repo in VSCode 4. Follow prompt to reopen in devcontainer 5. Once container ready, open a terminal and run

pants package ::

(This sounds similar to https://github.com/pantsbuild/pants/issues/19826 which doesn’t yet have a reproducer… so maybe we finally have one. Nice!)

I’ve tried moving

local_store_dir

and

named_caches_dir

out of

/home/vscode/.cache

and into

/tmp/cache/

as well as the bind-mounted workspace root

/workspaces/pants-test/.cache/

, and I continue to get the same error, fyi @wide-midnight-78598. if this is a reproducer for an existing issue, then that’s great! happy to help poke at this as you’d like.

Any solutions/workarounds for this issue? I need to get things to work in a docker container for my CI/CD and don’t have the option of using

chmod +w

(as suggested in the ticket) to sidestep this issue 😞