Support for .pth files in VSCode

[pawamoy]

Just opened this feature request: https://github.com/microsoft/vscode-python/issues/17063

I love the install_cache feature but right now VSCode does not follow .pth files 😕

[pawamoy]

It seems editables will complicate things a little...
Now editable installs cannot be found using sys.path only, as they use a mix of .pth file and private modules setting up some kind of redirect to the actual module... 😕

% cat __pypackages__/3.9/lib/griffe.pth        
import _griffe

% cat __pypackages__/3.9/lib/_griffe.py 
from editables.redirector import RedirectingFinder as F
F.install()
F.map_module('griffe', '/media/data/dev/pytkdocs/src/griffe/__init__.py')

It makes it difficult to find the source code without actually importing the module (which could have side-effects) 😕

[frostming]

Yes, that is the downside of the proxy module method. pdm(pdm-pep517) is the only backend so far that produces such wheels, and it can be easily opted out.

[pawamoy]

Ah, thanks! Very valuable information!

[frostming]

You can read the pros and cons for these methods and why PDM chooses the editables module here

[pawamoy]

• Build backends may choose to place a .pth file at the root of the .whl file, containing the root directory of the source tree. This approach is simple but not very precise, although it may be considered good enough (especially when using the src layout) and is similar to what setup.py develop currently does.

• The editables [1] library shows how to build proxy modules that provide a high quality editable installation. It accepts a list of modules to include, and hide. When imported, these proxy modules replace themselves with the code from the source tree. Path-based methods make all scripts under a path importable, often including the project's own setup.py and other scripts that would not be part of a normal installation. The proxy strategy can achieve a higher level of fidelity than path-based methods.