Follow symbolic links in installed packages #2806
Conversation
| Ok(file_type) => file_type.is_dir().then_some(Ok(entry.path())), | ||
| Ok(file_type) => file_type.is_dir().then_some( | ||
| // We follow symbolic links to deduplicate linked packages e.g. in `lib` / `lib64` | ||
| entry.path().canonicalize(), |
There was a problem hiding this comment.
What about deduplicating in venv.site_packages()?
There was a problem hiding this comment.
Seems like it would be faster, yeah. I guess both might make sense. Do you see a downside to this approach?
There was a problem hiding this comment.
I can think of contrived cases where this would be wrong. Imagine, e.g., that you symlink anyio-4.0.0.dist-info to anyio-3.7.0.dist-info. I don't know why this would happen. But then we'd resolve them to the same package, which would be wrong. Or imagine you have a symlink to a dist-info directory, like foo symlinks to anyio-4.0.0.dist-info. Then it would appear to be installed twice, when it's not. I don't know, these are weird, but following symlinks on the site-packages directory seems a bit more true to the spirit of what's happening. (I don't really understand why they're symlinked in the first place though.)
There was a problem hiding this comment.
Then it would appear to be installed twice, when it's not
It wouldn't appear twice in this cause because they'd resolve to the same directory and be de-duplicated?
you symlink anyio-4.0.0.dist-info to anyio-3.7.0.dist-info... then we'd resolve them to the same package
True, but insane haha. I'm not sure if we should account for that.
I'm okay with a more limited implementation, but I'm worried not resolving links here could cause problems in the future too.
|
@zanieb Unfortunately that doesn't appear to have fixed the problem: |
|
Gahh... that's why we write tests. Thanks for trying it! Will investigate further. |
|
Superseded by #3002. |
Closes #2798