[Distutils] Deprecate MANIFEST.in

[Tarek Ziadé]

On Sun, Apr 5, 2009 at 10:37 PM, Jeremy Kloth <jeremy.kloth at 4suite.org> wrote:
> On Sunday 05 April 2009 10:45:45 am Tarek Ziadé wrote:
>> I would like to deprecate MANIFEST.in in Distutils, in favor of a
>> package_data that can match directories with a glob-style pattern
>> see : http://bugs.python.org/issue5302
>
> Not all files that are released in an sdist would be considered for
> installation (ala package_data). Think of top-level README, COPYRIGHT,
> LICENSE or files (modules) used only by the setup.py script (ala custom
> commands). It would become an abuse of a keyword `package_data` to indicate
> files that are not actually *package* data.
>
> Remember not all files are meant to be used by the Python code, some, like C
> header files, would only be used at build time. This just strikes me as being
> an over-simplification that really benefits no one.

The benefit I am seeing is having one and only one explicit way to
define what goes into your package
distribution. We have many right now, and the worst is :

now people define some packages that depends on the source control
system they use (like svn) !

So basically, if you get a source distribution out there and work on
it in your own DVCS,
you are unable to create a distro.

>
> Note, however, `sdist` does need to be updated to include more files
> automatically, like the aforementioned C header files. With those fixes in
> place, then, maybe, MANIFEST.in would not be required.

Answering to Marius here too.

Right now, when you create a sdist, without any template file, it will
include by default these files
if it finds them :

- README or README.txt
- setup.py
- test/test*.py
- all pure Python modules mentioned in setup script
- all files pointed by package_data (build_py)
- all files defined in data_files.(build_py)
- all files defined as scripts.
- all C sources listed as part of extensions or C libraries
  in the setup script (doesn't catch C headers!)

So basically, build_py does most of the hard work, by computing
package_data and data_files to build the
file list.

What build_py misses is the ability to recursively add elements found
in subdirectories,
which is the new feature I would like to add. People would be able to
provide glob-style patterns,
to macth all their files.

But maybe we would need to define another name for some files that
would not fit under "package_data"
and "data_files"

Last, I find it a bit odd to have README and test/test*.py added
explicitely while others have to be defined.



>
> --
> Jeremy Kloth
> 4Suite Developer        http://4suite.org/
>



-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/