[WIP/RFC] Handle src-based distributions with egg-info installs - [opened]

[jaraco]

In GitLab by @blueyed on Mar 17, 2020, 12:34

Merges fix-locate-non-wheel-editable -> master

Ref: https://gitlab.com/python-devs/importlib_metadata/-/issues/112
Ref: https://gitlab.com/python-devs/importlib_metadata/-/issues/115

[jaraco]

In GitLab by @jaraco on Mar 25, 2020, 16:25

Commented on importlib_metadata/init.py line 270

Rather than undoing the abstraction here, I'd prefer if the handling of reading files for each type (distinfo, egginfo, egginfo legacy) were separate functions, such that this line of code and the subsequent return are unchanged.

[jaraco]

In GitLab by @jaraco on Mar 25, 2020, 16:25

Commented on importlib_metadata/init.py line 281

This code could be its own method, something like _read_files_legacy_install. However, as I commented in #115, I'm not sure this use-case should be supported at all. Let's exclude it for now and focus on #112.

[jaraco]

In GitLab by @jaraco on Mar 25, 2020, 16:25

Commented on importlib_metadata/init.py line 521

Can you clarify/document what _locate_path is intended to represent?

[jaraco]

In GitLab by @jaraco on Mar 25, 2020, 16:25

Commented on importlib_metadata/init.py line 290

I'd like to see the locate_path calculation extracted as a separate method with a docstring explaining its purpose and design. Is it possible for this behavior to be derived directly from the package_dir directive rather than implicitly by stumbling on the first entry in sources? This approach could fail if file_lines[0] happens to be missing or happens to match because the directory structure happens to match the parent directory structure.

Also, if _path is absolute, I believe this logic will traverse all the way to /. That seems undesirable.

[jaraco]

In GitLab by @jaraco on Mar 25, 2020, 16:25

Commented on importlib_metadata/init.py line 288

I've always been uneasy about the egginfo support here. In particular, because files() is presumably meant to be "files installed by this package", but in develop mode, files() means "sources identified for this package" (because there are not installed files), and sources are a semantically different set of files. So this approach has always been a bit of a best-effort approach to provide something meaningful in that case. I do agree that if this support remains, it should address #112, if that can be done in a safe and reliable way.

[jaraco]

In GitLab by @jaraco on Mar 25, 2020, 16:30

Thanks @blueyed for the exploration and code. As you can see, the coverage tests are failing. The project probably should have tests for the reported issues. I suggest keeping #112 and #115 separate for now and focusing on #112 here.

Would you consider adding a test that captures #112, preferably based prior to these changes so it demonstrates the failed expectation? Let me know if you could use help on that.

This project unfortunately can't use pytest, so the test suite is a little convoluted around fixtures, but I believe there are sufficient use-cases that it shouldn't be too difficult to re-purpose some of that behavior to test a source-layout package.

[jaraco]

I'm unsure if this issue was address or remains pending. The merge request got converted to an issue during the Github migration. Please feel free to re-engage the issue if the concern remains.

[bnavigator]

I think this is still an issue:

abravalheri/validate-pyproject#52

Package versions:
importlib.metadata from Python 3.10.5
setuptools 63.1.0

Cross-checked with importlib_metadata 4.11.4, different but still not the same as the dist-info file list.

[jherland]

I've run into a similar issue and tried to document it (and some potential solutions) here: #115 (comment)