New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot infer top-level imports from packages installed by PDM w/install.cache=true
(aka. symlinked packages)
#452
Comments
The packaging spec is weak about My first instinct is that PDM should supply a I also wonder if the inference shouldn't be updated to honor just a directory. That is, the name I'm reluctant to go further into the inference by inspecting the environment because that process doesn't generalize well. Although |
I don't disagree, but since I'm developing a tool that is run in the context of a user's project that happens to be PDM-managed, I'm not really in a position to change how the user manages their project. Also, Isn't the
True, although if it were a regular file, it should have an associated hash (and size). Quoting https://packaging.python.org/en/latest/specifications/binary-distribution-format/#the-dist-info-directory: Is it too far-fetched to deduce from this that a
Understood. Do you consider PDM's behavior here a bug, and would it be appropriate to raise an issue with PDM about this? I suspect it may be hard to argue this given that Python itself apparently has no problem importing packages that are installed this way. |
I tried replicating the environment, but I'm running up against an issue with pdm. It seems to get confused if there's more than one Python interpreter on the system:
Although Aha. It does appear that if I pass from jaraco/multipy-tox
run pipx install pdm
run pdm init --non-interactive --python 3.11
run pdm add colorama |
Unfortunately, even after attempting to replicate the indicated failure, I cannot. The symlinks and record are not being created:
|
Found my mistake. Through all my troubleshooting, I'd missed the from jaraco/multipy-tox
run pipx install pdm
run pdm config install.cache true
run pdm init --non-interactive --python 3.11
run pdm add colorama
|
I notice that even the cached wheel doesn't have a
And even if I install colorama without |
Same with Now I understand better. |
I have confirmed that by adding a
So, I've also observed that I see three options:
|
I've confirmed that file is generated by setuptools (and possibly other tools) at build time as egg-info and (probably) carried over to the wheel and dist-info by wheel. I don't think that precludes PDM from generating one, though it does beg the question - does this failure indicate that maybe these packages should be building with tools that provide this useful metadata? I'm not sure we want to add a fallback to a fallback to support these packages. Maybe PDM should warn when installing a package without top_level.txt into an environment with
That seems reasonable, and from my perspective a modest tweak to the existing fallback, so more palatable.
Not precisely a bug, but definitely a missed expectation caused by challenging assumptions about how packages are installed. By creating a new abstraction layer between the metadata in site-packages and the package's original metadata, it's taken on the burden of owning that abstraction. That is, it's written a new RECORD to represent the virtual package and creating symlinks of all top-level names to the original package. That means importlib metadata no longer has a clear model to follow for "files supplied by this package" - should it supply the files actually installed in site-packages (the virtual package and its links) or should it supply files represented by the original package (in the cache)? Both PDM and importlib metadata are operating outside the bounds of specifications here, providing best-effort solutions that nominally work, but which make assumptions and attempt to provide a reasonable experience in an ill-defined space. |
Fixed in #453 and released as v6.7.0. |
PDM has an alternative to install packages (enabled with
pdm config install.cache true
) where the package is first installed into a local cache (typically under$HOME/.cache/pdm/packages/
), and then the package is installed into the target virtualenv, but with symlinks pointing back to the package in the cache. Here is an example:Specifically:
top-level.txt
file, so top-level imports must be inferred fromRECORD
.RECORD
file does not mention any Python files undercolorama/
, only thecolorama
entry itself is listed. This is reflected inimportlib_metadata.files("colorama")
, and as a result_top_level_inferred(colorama)
ends up finding nothing, andpackages_distributions()
incorrectly presents zero imports for this packages.site-packages
directory,colorama
is a symlink to the correspondingcolorama
directory inside the PDM cache, so Python is indeed able toimport colorama
and find modules within this package.This was first reported via tweag/FawltyDeps#307, and (as a FawltyDeps maintainer and importlib_metadata user) I'm trying to figure out if this is an issue with importlib_metadata not properly handling PDM's weird (but techinically valid) installation method, or if PDM is doing something strictly incorrect here.
The text was updated successfully, but these errors were encountered: