This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

classification
Title: Recursive inclusion of packages
Type: enhancement Stage: resolved
Components: Distutils2 Versions: Python 3.3, 3rd party
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: alexis, eric.araujo, erik.bray, tarek
Priority: normal Keywords:

Created on 2012-04-11 16:42 by eric.araujo, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg158053 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-04-11 16:42
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 details).

A new field would be best if we could find a good name, or we could have special syntax in the existing packages field (like “packages = distutils2.*”).
msg158054 - (view) Author: Erik Bray (erik.bray) * (Python triager) Date: 2012-04-11 17:09
+1 for the wildcard syntax.
msg158055 - (view) Author: Erik Bray (erik.bray) * (Python triager) Date: 2012-04-11 17:13
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 it had an optional exclude argument. So maybe in addition to the wildcard syntax it couldn't hurt to add an exclude-packages option?  I don't think that would be too complicated.

Something similar for extension module sources would also be desirable.
msg158059 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-04-11 17:33
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, etc.  I proposed glob syntax or a new key to be conservative, but now I’ll add a third proposal:

packages = foo
packages-exclude = foo.spam

For a package foo with subpackages ham and spam, this would get foo and foo.ham.
Note that this was discussed on the fellowship ML two years ago but I don’t have the time to re-read the thread now.

(Why is it not named exclude-packages? 1) you can exclude single-file modules too with this option 2) it makes it clear that it’s a “sub-option” of packages)

About extension modules sources: good idea, but it should be its own feature request.
History
Date User Action Args
2022-04-11 14:57:29adminsetgithub: 58754
2014-03-13 00:41:11eric.araujosetstatus: open -> closed
resolution: out of date
stage: needs patch -> resolved
2012-04-11 17:33:10eric.araujosetmessages: + msg158059
2012-04-11 17:13:35erik.braysetmessages: + msg158055
2012-04-11 17:09:10erik.braysetmessages: + msg158054
2012-04-11 16:42:42eric.araujocreate