Re: [Distutils] Deprecate MANIFEST.in
At 03:40 PM 4/6/2009 +0200, Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 3:40 PM, P.J. Eby <pje@telecommunity.com> wrote:
At 03:11 AM 4/6/2009 +0200, Tarek Ziadé wrote:
Right, that would require something else, maybe a new one, ignored by the install command and using the glob-style pattern.
This means the glob-style pattern will need to have an exclude mechanism if some non-installed data are inside a directory that is added in package_data (like the tests directory if it's located in the src directory)
We already have this... it's called MANIFEST.in.
hum, ok let's deprecate what package_data provides then, (the ability to define a list of files without a MANIFEST.in template)....
MANIFEST.in (under setuptools at least) is merely a way to specify *exceptions* to the defaults, for what goes in the sdist. I don't understand why you're so anxious to deprecate something without first understanding what it's for. If you want to put some sort of sdist_exceptions in setup.py to replace the *file*, that's one thing, but the *same functionality* of MANIFEST.in is still needed, or else setuptools would've deprecated it.
On Mon, Apr 6, 2009 at 4:04 PM, P.J. Eby <pje@telecommunity.com> wrote:
We already have this... it's called MANIFEST.in.
hum, ok let's deprecate what package_data provides then, (the ability to define a list of files without a MANIFEST.in template)....
MANIFEST.in (under setuptools at least) is merely a way to specify *exceptions* to the defaults, for what goes in the sdist.
I doubt this was the first goal of this templating system (dealing with what setuptools was unable to deal with)
I don't understand why you're so anxious to deprecate something without first understanding what it's for.
Because we have too many ways to handle this problem right now. It's a mess. (and I think this mess is partly because of your project - besides all the good features it has of course)
If you want to put some sort of sdist_exceptions in setup.py to replace the *file*, that's one thing, but the *same functionality* of MANIFEST.in is still needed, or else setuptools would've deprecated it.
We need to describe a list of file. that's for sure. But not with : a VCS Plugin, + a MANIFEST.in but just for the exceptions + a bit of package_data etc.. how do you expect people to do it right ? Cheers Tarek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 4:04 PM, P.J. Eby <pje@telecommunity.com> wrote:
We already have this... it's called MANIFEST.in.
hum, ok let's deprecate what package_data provides then, (the ability to define a list of files without a MANIFEST.in template).... MANIFEST.in (under setuptools at least) is merely a way to specify *exceptions* to the defaults, for what goes in the sdist.
I doubt this was the first goal of this templating system (dealing with what setuptools was unable to deal with)
I don't understand why you're so anxious to deprecate something without first understanding what it's for.
Because we have too many ways to handle this problem right now. It's a mess.
(and I think this mess is partly because of your project - besides all the good features it has of course)
If you want to put some sort of sdist_exceptions in setup.py to replace the *file*, that's one thing, but the *same functionality* of MANIFEST.in is still needed, or else setuptools would've deprecated it.
We need to describe a list of file. that's for sure. But not with :
a VCS Plugin, + a MANIFEST.in but just for the exceptions + a bit of package_data etc..
- -1 to anything which breaks that pattern, which requires less effort and braaks less often than any "explicit" manifest. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJ2lNU+gerLs4ltQ4RAuw0AKDQTPVKfR9XP82UU2gvhuyBYB/FHwCcC1PX zdCne3q39TS2ufdUC3lhBMk= =+p3C -----END PGP SIGNATURE-----
On Mon, Apr 6, 2009 at 16:04, P.J. Eby <pje@telecommunity.com> wrote:
I don't understand why you're so anxious to deprecate something without first understanding what it's for.
If nobody understands it, that is in itself reason to replace it with something people understand. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
participants (4)
-
Lennart Regebro -
P.J. Eby -
Tarek Ziadé -
Tres Seaver