[Distutils] MANIFEST destiny :)

[Ian Bicking]

M.-A. Lemburg wrote:
>>* Always, always, always build MANIFEST, and always include both the 
>>MANIFEST file and MANIFEST.in (if present) in the source distribution.
> 
> 
> -1 on always building MANIFEST.
> 
> This would miss the point of managing MANIFEST files
> independently of your package files, e.g. using
> Makefiles or other tools dealing with file dependencies,
> checkouts, etc.

How about always build it, automatically, if some particular option is 
not passed to setup()?  This would only apply to packages using 
setuptools, not distutils, and there's other things that existing 
distutils packages might have to tweak to move to setuptools.  Maybe it 
would be as simple as a keyword argument that refers to a routine to 
build the MANIFEST file; and if you build MANIFEST by hand, then you 
just make the function a no-op.

Also, disable all command-line options that control when/if/how MANIFEST 
is generated; these seem peculiar to me.  MANIFEST generation seems like 
package metadata, not something particular to your build, and 
command-line options seem like a bad way to control that.  It's a little 
fuzzy, though, since command-line options and setup.cfg are equivalent, 
and setup.cfg options often feel like package data.  So... I don't know 
what the middle ground is there.  Either way, these aren't things that 
seem like they should be regularly tweaked.  I don't know, I don't have 
any packages with complex (or even simple) build processes, so I only 
know that the current system is mysterious to me, and almost but doesn't 
always work without my intervention.

I think Phillip also mentioned using MANIFEST for package_data?  At 
least insofar as the packages and the MANIFEST intersect, this seems 
like a good idea.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org