4 ms·

That does not seem useful? Unless there is a bug in where the files end up, ie they are not namespaced by the package? Shipping tests is great, it allows downst

That does not seem useful? Unless there is a bug in where the files end up, ie they are not namespaced by the package? Shipping tests is great, it allows downstream to verify the package works. Linux distributions now a days often runs test suites during packaging.

formerly_proven 2y ago
The top-level directories in a wheel are packages, so this means they all clobber the top-level tests package name. If the wheel contains a "test" package, it even clobbers the "test" package from the standard library (which contains tests for Python itself, the built-in testing package is "unittest"). I think that's just a misconfiguration due to the relatively common layout of - .git - pyproject.toml / setup.py / setup.cfg etc. - src/mypackage - tests/test_module1.py - tests/test_module2.py Depending on how you configure stuff you might accidentally include the tests directory as a separate top-level package next to all packages under "src". If you stick to the legacy ways, this does not happen if you just used the usual setup( ..., packages=find_packages('src'), package_dir={'': 'src'}, ) I think this is the default behavior of setuptools nowadays if you do not say anything at all in any of the config files about where your code is. If you actually intend to ship the tests, because they don't require a specialized environment to run, then the project layout should really be - .git - pyproject.toml / setup.py / setup.cfg etc. - src/mypackage - src/mypackage/tests/test_module1.py Downstream consumers who might want to ship this as part of something larger should ideally be able to just delete mypackage/tests without anything breaking.
- jononor 2y ago
  Ah, right you are. Yeah, then packages really should not ship such directories. The practice of having tests inside the package being tested I remember as being discouraged, because it makes it hard to run one version of tests against another of the package. Which I guess can be useful for regression testing, though I have not really used it. An alternative layout that would preserve that be a mypackage_tests top-level.
  - formerly_proven 2y ago
    That's another good option, though I guess yodafying that (tests_mypackage) would have the added benefit that downstream consumers don't get mypackage_tests as an autocomplete suggestion.

formerly_proven 2y ago

The top-level directories in a wheel are packages, so this means they all clobber the top-level tests package name. If the wheel contains a "test" package, it even clobbers the "test" package from the standard library (which contains tests for Python itself, the built-in testing package is "unittest"). I think that's just a misconfiguration due to the relatively common layout of - .git - pyproject.toml / setup.py / setup.cfg etc. - src/mypackage - tests/test_module1.py - tests/test_module2.py Depending on how you configure stuff you might accidentally include the tests directory as a separate top-level package next to all packages under "src". If you stick to the legacy ways, this does not happen if you just used the usual setup( ..., packages=find_packages('src'), package_dir={'': 'src'}, ) I think this is the default behavior of setuptools nowadays if you do not say anything at all in any of the config files about where your code is. If you actually intend to ship the tests, because they don't require a specialized environment to run, then the project layout should really be - .git - pyproject.toml / setup.py / setup.cfg etc. - src/mypackage - src/mypackage/tests/test_module1.py Downstream consumers who might want to ship this as part of something larger should ideally be able to just delete mypackage/tests without anything breaking.

jononor 2y ago
Ah, right you are. Yeah, then packages really should not ship such directories. The practice of having tests inside the package being tested I remember as being discouraged, because it makes it hard to run one version of tests against another of the package. Which I guess can be useful for regression testing, though I have not really used it. An alternative layout that would preserve that be a mypackage_tests top-level.
- formerly_proven 2y ago
  That's another good option, though I guess yodafying that (tests_mypackage) would have the added benefit that downstream consumers don't get mypackage_tests as an autocomplete suggestion.