search

pdoc3 / pdoc

:snake: :arrow_right: :scroll: Auto-generate API documentation for Python projects
https://pdoc3.github.io/pdoc/
GNU Affero General Public License v3.0
1.11k stars 143 forks source link

BUG: Handle import of distutils for python 3.12 #438

Closed ERosendo closed 3 weeks ago

ERosendo commented 5 months ago

This PR adds code to handle the import of the sysconfig module for Python >= 3.11

ferdnyc commented 3 months ago

None of this code will work anyway — the code is looking for *.egg-link files, which haven't been supported in forever. They're as deprecated as distutils. Anything installed with pip install -e in a venv will have a .dist-info directory instead.

(Of course, so will most other packages installed in the venv, so it's necessary to look for a direct_url.json file inside the .dist-info dir to determine whether or not the package is editable, and the path to its source files.)

ferdnyc commented 3 months ago

IIUC correctly, based on the comment above the code that uses distutils, it's there to support one very particular use case: When the user is working in a virtualenv, but runs a pdoc script installed outside of that virtualenv (in a system or user path).

Honestly, the most sensible solution, to me, seems to be: Just don't support that. It's a lot of effort for very little reward. When working in a venv, install pdoc3 in the venv. Simple as that, and all of the path shenanigans go away.

Otherwise, checking for a VIRTUAL_ENV environment variable is the wrong way to detect when running in a venv (though it is a clever way to detect a non-venv-installed package being run from an activated venv).

But if pdoc is being executed under a non-venv Python interpreter, even with an activated venv, distutils.sysconfig.get_python_lib() / sysconfig.get_path() won't return the paths inside the venv. They'll return the system paths.

And if pdoc is actually being executed in a venv (that it's installed in), then there's no need to screw with sys.path, it'll already point into the venv's site-packages dir. If there are any editable installs, importlib.import_module('packagename') will work to import those packages, and the path to the source files is just packagename.__path__[0].

So I really don't get what that code is trying to do anyway.

kernc commented 3 weeks ago

And if pdoc is actually being executed in a venv (that it's installed in), then there's no need to screw with sys.path, it'll already point into the venv's site-packages dir. If there are any editable installs, importlib.import_module('packagename') will work to import those packages, and the path to the source files is just packagename.__path__[0].

@ferdnyc Apparenly, this being a non-issue hasn't always been the case ... 🤷