Summary
When /bin/python3 is a symlink to /usr/bin/python3 (or both resolve to the same prefix), PET discovers them as two separate environments — /usr/bin/python3 is correctly identified as LinuxGlobal, but /bin/python3 is reported as Unknown.
Observed Behavior
Tested in a Docker container (continuumio/miniconda3) where /bin → /usr/bin:
Environment (LinuxGlobal)
Executable : /usr/bin/python3
Version : 3.13.5.final.0
Prefix : /usr
Symlinks : "/usr/bin/python3", "/usr/bin/python3.13"
Environment (Unknown)
Executable : /bin/python3
Version : 3.13.5.final.0
Prefix : /usr
Symlinks : "/bin/python3", "/bin/python3.13"
Both environments have the same prefix (/usr) and same version — they are the same Python installation.
Expected Behavior
PET should recognize that /bin/python3 and /usr/bin/python3 resolve to the same Python and either:
- Merge them into a single
LinuxGlobal environment with both paths listed as symlinks, OR
- At minimum, the
LinuxGlobal locator should also identify /bin/python3 (via symlink resolution) so it doesn't show as Unknown
Impact
If a user has /bin/python3 in their PATH or configures it as their interpreter, PET reports it as Unknown instead of LinuxGlobal. This means:
- Missing metadata that would be available for a properly identified environment
- Confusing UX in VS Code showing the same Python twice with different types
- The
resolve JSONRPC method may return incomplete information for /bin/python3
Root Cause
The LinuxGlobalPython locator checks specific paths like /usr/bin but does not resolve symlinks to determine if an executable at another path (like /bin) points to the same installation. The PATH-based discovery finds /bin/python3 separately and no locator claims it.
Reproduction
docker run --rm continuumio/miniconda3 sh -c "ls -la /bin/python3 && ls -la /usr/bin/python3"
# Both point to the same binary
Proposed Fix
In try_from() or during identification fallback, resolve the executable's canonical path before giving up. If the resolved path falls under a known global location (e.g., /usr/bin), attribute it to LinuxGlobal. Alternatively, expand LinuxGlobalPython::find() to also scan /bin on systems where /bin is separate from /usr/bin.
Summary
When
/bin/python3is a symlink to/usr/bin/python3(or both resolve to the same prefix), PET discovers them as two separate environments —/usr/bin/python3is correctly identified asLinuxGlobal, but/bin/python3is reported asUnknown.Observed Behavior
Tested in a Docker container (
continuumio/miniconda3) where/bin→/usr/bin:Both environments have the same prefix (
/usr) and same version — they are the same Python installation.Expected Behavior
PET should recognize that
/bin/python3and/usr/bin/python3resolve to the same Python and either:LinuxGlobalenvironment with both paths listed as symlinks, ORLinuxGloballocator should also identify/bin/python3(via symlink resolution) so it doesn't show asUnknownImpact
If a user has
/bin/python3in their PATH or configures it as their interpreter, PET reports it asUnknowninstead ofLinuxGlobal. This means:resolveJSONRPC method may return incomplete information for/bin/python3Root Cause
The
LinuxGlobalPythonlocator checks specific paths like/usr/binbut does not resolve symlinks to determine if an executable at another path (like/bin) points to the same installation. The PATH-based discovery finds/bin/python3separately and no locator claims it.Reproduction
Proposed Fix
In
try_from()or during identification fallback, resolve the executable's canonical path before giving up. If the resolved path falls under a known global location (e.g.,/usr/bin), attribute it toLinuxGlobal. Alternatively, expandLinuxGlobalPython::find()to also scan/binon systems where/binis separate from/usr/bin.