On Sun, Apr 5, 2009 at 10:37 PM, Jeremy Kloth <[email protected]> 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/ _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
