[Distutils] Deprecate MANIFEST.in

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Cournapeau wrote:
> Lennart Regebro wrote:
> 
>> Well, because the tarball will include the files in the VCS. But sure,
>> if you in the tarball case add files in the directory that are not in
>> the VCS, that would be included too. Maybe that's a problem, I don't
>> know. I can't see the problem myself, but maybe somebody else would
>> have a case for that.
>>   
> 
> My use case is very simple, and yet very common. If you have your
> sources in a VCS system, say svn:
> 
> python setup.py sdist # put everything under svn into the tarball
> cd dist && uncompress tarball && python setup.py sdist # the tarball is
> not the same

That is an "iced tea spoon"[1]:  there is no guarantee that running
sdist will (or even should) work the same way.  Note that under
setuptools, the actual files included in the original 'sdist' are
generated into the 'sources.txt' file in the EGG-INFO directory,

It is often true for *lots* of release management strategies that the
release managers have to do extra work to create a release tarball
(e.g., re-run autogen, etc., or flex / bison, etc.), and that the
released tarball does not include enough information to rebuild itself
(as opposed to re-tgz'ing it).

> That's a concrete example of what I mean by magic. The distributed files
> depends on how where you build it. It means that someone who get this
> tarball, modify it, and regenerate it cannot do it correctly.
> 
> The whole point of packaging tools is reproducibility. Using the VCS as
> is done currently breaks this.

Nobody but a package maintainer should be making sdists.  If you are
making private sdists of a package maintained elsewhere, they you should
be prepared to do extra work, like checking the sources into a VCS, or
hacking the packaging data yourself.


[1] "Doctor!  Doctor!  whenever I drink iced tea, I get a cold stabbing
    pain in my eye!"  "Take out the spoon!"


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ2lFk+gerLs4ltQ4RAt3pAJ96zikIssJkAtifbZUNf40ZFVvryQCfVl9d
0+1vwn8q91zzTBRyPeBcViY=
=ydao
-----END PGP SIGNATURE-----