On 28 November 1999, Michael Hudson said:
Yes! I spent a frustrating few minutes trying to work out why files I was trying to exclude from the distribution were turning up in the tarball...
Oops, sorry.
Also, excluding files from the dist in general is a pain.
I have bytecodehacks in CVS; I don't want to distribute the CVS folders. I found no way to do this except building the MANIFEST file using a shell script (which kind of defeats the point of the manifest, I'd have thought).
Also excluding a single file doesn't work.
[...more ranting about what doesn't work in the Distutils MANIFEST file...]
Yeah, I've been bitten by a couple of these things myself; others, I haven't seen. As I said in my last post, this was a cobbled-together hack and not-at-all well thought-out. Guess it's time to fix that.
What I'm moving towards now is some of the ideas that MAL, Gordan MacMillan, and Fred Drake (anyone else?) were tossing around back in September when I first brought up the MANIFEST thing. In particular:
* two-phase manifest; developer writes a MANIFEST.in that is short and simple, something like this (for Distutils itself):
USAGE TODO MANIFEST CHANGES examples README *.py
(although possibly with a more verbose syntax). Then, at some point the Distutils will process this and output MANIFEST, which is used a) to put together the distribution, b) to allow the developer to peek into the explicit list of files generated, and c) to allow the developer to meddle with the explicit list of files generated.
However, this gets complicated when you start thinking about the interactions between MANIFEST.in and MANIFEST. I think there are cases where the module developer will just want to use his own MANIFEST and ignore my MANIFEST.in thing, and there are cases where he'll just want to clobber MANIFEST from MANIFEST.in every time. I started scribbling down some thoughts on this a few weekends ago, but got distracted.
* more explicit, clearer syntax
Anyways, I'm open to ideas on how best to handle the MANIFEST.in/MANIFEST thing (and syntax for the former). Tell me what features you want, whether you even like the idea of going from a short, simple list of exclude/include patterns to an explicit list of every file, how you would like to use such a system, etc. (My main concern is that we *not* just have a simple MANIFEST file that the developer has to create and maintain; that's how Perl's MakeMaker expects you to work, and it's a PITA. It provides a module to help you generate the MANIFEST the first time, but after that you're pretty much on your own.)
Greg