Open sanmai-NL opened 1 week ago
Usually, building or installing the current project needs to be done in place, otherwise, you would need to copy the entire project to a temporary directory, causing unnecessary overhead. Moreover, if your project references packages from the parent directory as dependencies, copying becomes infeasible either.
I think if we can define more strictly what mutations/write transactions are needed where, we can in practice work around this without significant disadvantages. In my case, only pyproject.toml
, pdm.toml
and pdm.lock
are bind mounts and the rest of the filesystem tree isn't, avoiding some of the essential limitations you point out.
Arguments in favor of such a more refined design, are that read-only filesystems or parts thereof (such as some mount points) are common in Linux-containerized scenarios. These environments allow for more performance-efficient and hermetic builds. See source identity on https://bazel.build/basics/hermeticity.
Describe the bug
To support
uv
(indeed, a feature not yet production ready in the current implementation), thepyproject.toml
file gets moved away and the contents at its path mutate. Afteruv
completes,pdm
restores the originalpyproject.toml
.This doesn't work when the filesystem is read-only (in some place). This design also creates some noise in IDEs that watch the filesystem and thing the VCS working copy is undergoing changes.
I haven't studied the current implementation in detail, but creating a temporary directory and/or files using e.g., the
tempfile
module is more likely to get past this filesystem constraint.To reproduce
Expected Behavior
Don't assume renames etc. are possible and avoid filesystem mutations as much as possible.
Environment Information
pdm -v output
No response
Additional Context
When
pyproject.toml
is a read-only bind mount, it's simply impossible to rename as far as I know.Are you willing to submit a PR to fix this bug?