Skip to content

Consider declaring package data in MANIFEST.in #9801

Closed as not planned
Closed as not planned

Description

@astrofrog

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:

https://setuptools.readthedocs.io/en/latest/setuptools.html#including-data-files

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?

Activity

  1. saimn commented on Dec 18, 2019

    @saimn
    Contributor

    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 astropy could replace the recursive globbing, if there are specific files to exclude I think this can also be done).

  2. mhvk commented on Dec 18, 2019

    @mhvk
    Contributor

    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...

  3. pllim commented on Jun 29, 2025

    @pllim
    Member

    Can we close this now? Is this still relevant?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions