You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consider declaring package data in MANIFEST.in #9801
As @saimn mentioned in #9729, and as mentioned in APE 17, there are two main ways of specifying the package data, both of them mentioned in the setuptools docs:
Essentially, we can either define the package data in setup.cfg, or we can use the MANIFEST.in and then just set include_package_data=True in setup.cfg. I don't have very strong opinions, but MANIFEST.in might give us more flexibility in terms of e.g. including data files recursively.
Do people have strong opinions one way or another?
No strong opinions here either - as long as we stick to a single place and have a comments pointing from one to the other - but I do wonder a bit more generally why this is needed in the first place. Ideally, one would just start with everything under git version control and possibly add/reject relative to that...
Activity
saimn commentedon Dec 18, 2019
I think the main reason in favor of using MANIFEST.in is to avoid using both ;). MANIFEST.in is already used for other purposes (https://github.com/astropy/astropy/blob/master/MANIFEST.in), and is more flexible than
package_data(e.g.graft astropycould replace the recursive globbing, if there are specific files to exclude I think this can also be done).mhvk commentedon Dec 18, 2019
No strong opinions here either - as long as we stick to a single place and have a comments pointing from one to the other - but I do wonder a bit more generally why this is needed in the first place. Ideally, one would just start with everything under git version control and possibly add/reject relative to that...
pllim commentedon Jun 29, 2025
Can we close this now? Is this still relevant?