Skip to content

atomic writes in pixi assume the pixi.toml path is writeable #5724

@kratsg

Description

@kratsg

Checks

  • I have checked that this issue has not already been reported.

  • I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

Commands I ran and their output:

$ $ pixi add -f mlcpu mplhep
Error:   × Permission denied (os error 13) at path "/app/.pixi.toml.IwHBzW"

pixi.toml/pyproject.toml file that reproduces my issue: not relevant

pixi info output:

$ pixi info
System
------------
       Pixi version: 0.66.0
        TLS backend: rustls
           Platform: linux-64
   Virtual packages: __unix=0=0
                   : __linux=5.14.0=0
                   : __glibc=2.39=0
                   : __archspec=1=zen2
          Cache dir: /home/kratsg/.cache/rattler/cache
       Auth storage: /home/kratsg/.rattler/credentials.json
   Config locations: No config files found

Global
------------
            Bin dir: /home/kratsg/.pixi/bin
    Environment dir: /home/kratsg/.pixi/envs
       Manifest dir: /home/kratsg/.pixi/manifests/pixi-global.toml

Workspace
------------
               Name: ml-platform
            Version: 2026.3.18
      Manifest file: /app/pixi.toml
       Last updated: 19-03-2026 00:49:03

Environments
------------
        Environment: default
           Features: default
           Channels: conda-forge
   Dependency count: 0
   Target platforms: linux-aarch64, osx-arm64, osx-64, linux-64
    Prefix location: /app/.pixi/envs/default

        Environment: dev
           Features: dev, default
           Channels: conda-forge
   Dependency count: 2
       Dependencies: python, tbump
   Target platforms: linux-64, osx-64, linux-aarch64, osx-arm64
    Prefix location: /app/.pixi/envs/dev
              Tasks: bump, tbump

        Environment: mlcpu
           Features: mlbase, mlcpu, default
           Channels: conda-forge
   Dependency count: 50
       Dependencies: python, pixi-kernel, root, openjdk, keras, numpy, pandas, scipy, scikit-learn, pyarrow, h5py, pytables, cython, matplotlib, seaborn, bokeh, graphviz, jupyter, jupyterlab_server, jupyterlab, notebook, ipykernel, metakernel, ipywidgets, jupyterlab-git, rise, uproot, rucio-clients, curl, wget, unzip, zip, vim, jq, rsync, git, make, compilers, pkg-config, freetype, libpng, zeromq, hdf5, tbb, zlib, requests, pillow, tqdm, imageio, tensorflow
  PyPI Dependencies: tensorflow-datasets, keras-tuner, plumbum, jupyter-bokeh, qtpy, elasticsearch, gymnasium, JSAnimation, dask-labextension, atlasify, rucio-jupyterlab
   Target platforms: linux-64
    Prefix location: /app/.pixi/envs/mlcpu

        Environment: ml
           Features: mlbase, mlgpu, default
           Channels: conda-forge
   Dependency count: 50
       Dependencies: python, pixi-kernel, root, openjdk, keras, numpy, pandas, scipy, scikit-learn, pyarrow, h5py, pytables, cython, matplotlib, seaborn, bokeh, graphviz, jupyter, jupyterlab_server, jupyterlab, notebook, ipykernel, metakernel, ipywidgets, jupyterlab-git, rise, uproot, rucio-clients, curl, wget, unzip, zip, vim, jq, rsync, git, make, compilers, pkg-config, freetype, libpng, zeromq, hdf5, tbb, zlib, requests, pillow, tqdm, imageio, tensorflow-gpu
  PyPI Dependencies: tensorflow-datasets, keras-tuner, plumbum, jupyter-bokeh, qtpy, elasticsearch, gymnasium, JSAnimation, dask-labextension, atlasify, rucio-jupyterlab
   Target platforms: linux-64
    Prefix location: /app/.pixi/envs/ml
System requirements: cuda = "13.0"

Other files (e.g. script files, source files, etc.):

$ ls -lavh /app
total 456K
drwxr-xr-x. 1 root root 4.0K Mar 18 19:56 .
drwxr-xr-x. 1 root root 4.0K Mar 19 00:36 ..
drwxrwxrwx. 1 root root 4.0K Mar 19 00:36 .jupyter
drwxrwxrwx. 1 root root 4.0K Mar 18 19:56 .pixi
-rwxr-xr-x. 1 root root 1.8K Mar 18 19:54 entrypoint.sh
-rwxrwxrwx. 1 root root 411K Mar 19 00:39 pixi.lock
-rwxrwxrwx. 1 root root 2.0K Mar 18 19:53 pixi.toml

Issue description

No response

Expected behavior

The problem I believe is in

/// Build a [`tempfile::NamedTempFile`] in the same directory as `path`, using
/// the original filename as the prefix so the temp file is easily identifiable
/// (e.g. `.pixi.toml.XXXXXX`).
fn temp_file_for(path: &Path) -> std::io::Result<tempfile::NamedTempFile> {
let dir = path.parent().ok_or_else(|| {
std::io::Error::new(
std::io::ErrorKind::InvalidInput,
"path has no parent directory",
)
})?;
let prefix = format!(
".{}.",
path.file_name().and_then(|n| n.to_str()).unwrap_or("tmp")
);
tempfile::Builder::new().prefix(&prefix).tempfile_in(dir)
}
from #5500 which makes the (not safe) assumption that the path for the pixi.toml file is writeable. I suspect it should rely on the $TMPDIR of the machine that pixi is running on which is user-writeable (typically...?) but at the moment, I see no way to configure this from my end.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions