[BUG] pkg_resources/tests/data/my-test-package-source/setup.py is installed via wheel

[hroncok]

setuptools version

57.0.0 to 57.4.0

Python version

Any version

OS

Any OS

Additional environment information

No response

Description

The pkg_resources/tests/data/my-test-package-source/setup.py file is present in setuptools-57.0.0-py3-none-any.whl and is installed together with setuptools. I believe this might be related to https://github.com/pypa/setuptools/issues/2688

Expected behavior

The pkg_resources/tests and setuptools/tests directories are not expected to be present in setuptools wheels and installation.

How to Reproduce

1. Download the wheel
2. Inspect the content
3. Install setuptools
4. Inspect the installed files

Output

$ unzip -l setuptools-57.0.0-py3-none-any.whl | grep tests
      104  05-23-2021 03:54   pkg_resources/tests/data/my-test-package-source/setup.py

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct

[black-snow]

Wait, this is sitting here since 2021? Why am I suddenly seeing my-test-package pop up in setuptools 71.1.0?

./.venv/lib/python3.12/site-packages/setuptools-71.1.0.dist-info/RECORD:pkg_resources/tests/data/my-test-package-source/setup.cfg,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
./.venv/lib/python3.12/site-packages/setuptools-71.1.0.dist-info/RECORD:pkg_resources/tests/data/my-test-package-source/setup.py,sha256=1VobhAZbMb7M9mfhb_NE8PwDsvukoWLs9aUAS0pYhe8,105
./.venv/lib/python3.12/site-packages/setuptools-71.1.0.dist-info/RECORD:pkg_resources/tests/data/my-test-package-zip/my-test-package.zip,sha256=AYRcQ39GVePPnMT8TknP1gdDHyJnXhthESmpAjnzSCI,1809
./.venv/lib/python3.12/site-packages/setuptools-71.1.0.dist-info/RECORD:pkg_resources/tests/data/my-test-package_unpacked-egg/my_test_package-1.0-py3.7.egg/EGG-INFO/PKG-INFO,sha256=JvWv9Io2PAuYwEEw2fBW4Qc5YvdbkscpKX1kmLzsoHk,187
./.venv/lib/python3.12/site-packages/setuptools-71.1.0.dist-info/RECORD:pkg_resources/tests/data/my-test-package_unpacked-egg/my_test_package-1.0-py3.7.egg/EGG-INFO/SOURCES.txt,sha256=4ClkH8eTovZrdVrJFsVuxdbMEF--lBVSuKonDAPE5Jc,208
./.venv/lib/python3.12/site-packages/setuptools-71.1.0.dist-info/RECORD:pkg_resources/tests/data/my-test-package_unpacked-egg/my_test_package-1.0-py3.7.egg/EGG-INFO/dependency_links.txt,sha256=AbpHGcgLb-kRsJGnwFEktk7uzpZOCcBY74-YBdrKVGs,1
./.venv/lib/python3.12/site-packages/setuptools-71.1.0.dist-info/RECORD:pkg_resources/tests/data/my-test-package_unpacked-egg/my_test_package-1.0-py3.7.egg/EGG-INFO/top_level.txt,sha256=AbpHGcgLb-kRsJGnwFEktk7uzpZOCcBY74-YBdrKVGs,1
./.venv/lib/python3.12/site-packages/setuptools-71.1.0.dist-info/RECORD:pkg_resources/tests/data/my-test-package_unpacked-egg/my_test_package-1.0-py3.7.egg/EGG-INFO/zip-safe,sha256=AbpHGcgLb-kRsJGnwFEktk7uzpZOCcBY74-YBdrKVGs,1
./.venv/lib/python3.12/site-packages/setuptools-71.1.0.dist-info/RECORD:pkg_resources/tests/data/my-test-package_zipped-egg/my_test_package-1.0-py3.7.egg,sha256=ZTlMGxjRGiKDNkiA2c75jbQH2TWIteP00irF9gvczbo,843
./.venv/lib/python3.12/site-packages/pkg_resources/tests/test_find_distributions.py:            TESTS_DATA_DIR / 'my-test-package_unpacked-egg',
./.venv/lib/python3.12/site-packages/pkg_resources/tests/test_find_distributions.py:        assert [dist.project_name for dist in dists] == ['my-test-package']
./.venv/lib/python3.12/site-packages/pkg_resources/tests/test_find_distributions.py:            TESTS_DATA_DIR / 'my-test-package_zipped-egg',
./.venv/lib/python3.12/site-packages/pkg_resources/tests/test_find_distributions.py:        assert [dist.project_name for dist in dists] == ['my-test-package']
./.venv/lib/python3.12/site-packages/pkg_resources/tests/test_find_distributions.py:            TESTS_DATA_DIR / 'my-test-package-zip', target_dir, dirs_exist_ok=True
./.venv/lib/python3.12/site-packages/pkg_resources/tests/test_find_distributions.py:            str(target_dir / "my-test-package.zip")
./.venv/lib/python3.12/site-packages/pkg_resources/tests/test_find_distributions.py:        assert [dist.project_name for dist in dists] == ['my-test-package']
./.venv/lib/python3.12/site-packages/pkg_resources/tests/test_find_distributions.py:            str(target_dir / "my-test-package.zip"), only=True
./.venv/lib/python3.12/site-packages/pkg_resources/tests/data/my-test-package_unpacked-egg/my_test_package-1.0-py3.7.egg/EGG-INFO/PKG-INFO:Name: my-test-package
./.venv/lib/python3.12/site-packages/pkg_resources/tests/data/my-test-package-source/setup.py:    name="my-test-package",

Apart from that the tests shouldn't be present there, why is there some random package? Is it this? Because that's the first thing you'd find if you went looking for why the hell there's a package called my-test-package in your prod build.

/edit: apparently it's not the one from pypi. Can we not ship this? It's confusing my license scanner.

[abravalheri]

Hi @hroncok, in the current state of the repository this issue is related to https://github.com/pypa/setuptools/issues/3260 and the sister issue https://github.com/pypa/setuptools/issues/3340 (there is a mutual deadlock between these 2 issues).

But including them in the wheel seems to be a deliberate decision from https://github.com/pypa/setuptools/pull/4479. I believe that @jaraco have carefully considered the existing limitations and decided that the best approach would be to just include the files in the wheel anyway (see comments in #4479).

[abravalheri]

Hi @black-snow these are test fixtures, intentionally shipped with the rest of the code. Since they are nested under setuptools and maintained/distributed as the same source code, they follow the same license as the rest setuptools. I believe this is a false positive/limitation of your license scanner. Anyway you can workaround that?

[black-snow]

Thanks for the links!

Whew, scrolled through the linked threads and I gotta say it's too much to ingest. From my point of view tests / test data should not be shipped with the wheel, arguably, and I didn't really see why it does.

Apparently this is a false positive but arguably just accidentially so. It kinda makes sense to me to scan recursively down to the bottom. For my specific case it would probably suffice to add license information to my-test-package tbh. I'd still be confused about why there's such a package there, but before shouting 'what the hell' at my fellow colleagues I'd remember this thread :D

[jaraco]

To be sure, the long-term strategy is to eliminate reliance on pkg_resources, remove it from this package, and then move setuptools' own tests into ./tests such that they are only included in the sdist (and not the installed wheel). That work will take some time, so thanks for bearing with this cruft in the meantime.

[black-snow]

Thanks for caring! @jaraco @abravalheri

Would it be an option to copypasta the license into the test package as well in the meantim? I really haven't looked at what's actually happening there yet. Anything I can help with?

[jaraco]

I'd rather not add artifacts to the source code that this project doesn't care about, as it could get removed incidentally and also could linger long after it's needed. It would be tricky to add a LICENSE that's only needed for black-snow's build system, especially if that's the only one that's affected (by the lack of a license). What do you think about abravalheri's proposition?

I believe this is a false positive/limitation of your license scanner. Anyway you can workaround that?

[jaraco]

Another option I'd prefer instead of adding a license would be to define this fixture in code and build it dynamically at runtime rather than store it as source in the repo/sdist.

[black-snow]

Anyone using Trivy should be affected.

I like the runtime generation idea.

[jaraco]

I like the runtime generation idea.

Before we go down that route, I'd hope that Trivy could be updated or configured to avoid this false positive.

[black-snow]

Actually, I'm not sure we can call this a false positive from Trivy's stance. It walks like a package, it quacks like a package, it lacks a license. How should Trivy know that this is only a test and not actually in use? ('cept from having an explicit exception for us ... which would be rather shitty)

There's no filtering I'd know of so far. I could explicitly skip the test package, I guess. But now I need to copypasta this into each and every Python project and keep it in there forever :/

[benglvr]

This affects Artifactory's X-Ray as well which is used by many large companies, please add a licence declaration for the my-test-package.

@black-snow I am happy to write a PR for this, does your scanner just check for the info in PKG-INFO?

Metadata-Version: 1.0
Name: my-test-package
Version: 1.0
Summary: UNKNOWN
Home-page: UNKNOWN
Author: UNKNOWN
Author-email: UNKNOWN
License: UNKNOWN
Description: UNKNOWN
Platform: UNKNOWN

License just needs changing to MIT and it should appease the license scanners.

(yes you can add exceptions but it's a pain in the butt and has to be done on every update... at larger companies this can take a while to go through all the levels of bureaucracy)

[black-snow]

@benglvr to me it's not quite clear from the docs where exactly Trivy is looking for licenses.