[issue14549] Recursive inclusion of packages

Changes by Éric Araujo : -- resolution: -> out of date stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue14549] Recursive inclusion of packages

Éric Araujo added the comment: IMO the best behavior would be to always recurse and have an option to exclude specific submodules. When the Django devs want to package their code, they think about a Python package named django, docs and scripts, not about django, django.views, django.http, e

[issue14549] Recursive inclusion of packages

Erik Bray added the comment: Potential downside: Say I have foo, foo.bar, and foo.tests. I want to install foo and foo.bar, but not foo.tests. Then I have to manually list all the packages I do want: packages = foo foo.bar That's fine, but one nice thing about find_packages is that

[issue14549] Recursive inclusion of packages

Erik Bray added the comment: +1 for the wildcard syntax. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue14549] Recursive inclusion of packages

New submission from Éric Araujo : For projects with more than a few packages, it is tedious to list all subpackages manually in setup.cfg. There was once a find_packages in distutils2.util (copied from distribute), but when we moved away from setup.py it was removed (I don’t remember all the