Plugins for the MANIFEST file
Hello, I'd like to refactor the current Distutils code that builds the MANIFEST file so it's pluggable, like what setuptools introduced. Distutils would provide some default plugins, and a new global display option --manifest I have started a new task in the wiki for that here : http://wiki.python.org/moin/Distutils/ManifestPluginSystem If anyone wants to work on it, or comment, Cheers Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
If anyone wants to work on it, or comment,
Some comments:
"MANIFEST.in is fine"
Except that it introduces Yet Another Domain Specific Language. Wtf does "prune" mean? It's not obvious. The docs indicate that it actually excludes, but why it's not called "exclude" is then strange. We already have a language, Python. We don't need more. ;-) And the fact that is uses a separate file doesn't help. Yes, I know I'm just whining. But I don't agree that MANIFEST.in is fine. I think it is unfine. :)
Like Bill, he is unable to launch the sdist command because he will probably get a incomplete list of files.
Not if the default is all files except well known temporary files. He might get more files than desired, though. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
If anyone wants to work on it, or comment,
Some comments:
"MANIFEST.in is fine"
Except that it introduces Yet Another Domain Specific Language. Wtf does "prune" mean? It's not obvious. The docs indicate that it actually excludes, but why it's not called "exclude" is then strange. We already have a language, Python. We don't need more. ;-)
And the fact that is uses a separate file doesn't help.
Yes, I know I'm just whining. But I don't agree that MANIFEST.in is fine. I think it is unfine. :)
I agree with this. Remember: I wanted to deprecate MANIFEST.in in favor of a pure python description. Then people strongly objected. Tarek
On Wed, Apr 8, 2009 at 10:21, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
I agree with this. Remember: I wanted to deprecate MANIFEST.in in favor of a pure python description. Then people strongly objected.
How many people objected? Would it be OK to only have support for this in an external plugin, and not in stdlib? Again, this is of course only possible if the new distutils is called something else, as we need backwards compatibility for a Very Long Time if it continues to be called distutils. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
On Wed, Apr 8, 2009 at 10:30 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Wed, Apr 8, 2009 at 10:21, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
I agree with this. Remember: I wanted to deprecate MANIFEST.in in favor of a pure python description. Then people strongly objected.
How many people objected? Would it be OK to only have support for this in an external plugin, and not in stdlib?
These changes will go into Python current Distutils. You are welcome to help on enhancing this proposal.
Again, this is of course only possible if the new distutils is called something else, as we need backwards compatibility for a Very Long Time if it continues to be called distutils.
We are going to work as we said during the Summit : - make distutils lighter, and provide better/simpler ways to use it - include the good bits of setuptools in it - provide a backport for 2.5/2.6 as soon as 2.7 is out. I am changing my strategy. Since I am the current Distutils maintainer, I will take the role of 'packaging dictator' for Python 2.7. If you think I am missing some points (I am probably), You will need to complete the wiki pages or write a new page there explaining what you would like to see included in Distutils. But I will not work in flame-threads anymore on my side. Cheers Tarek
On Wed, Apr 8, 2009 at 12:03, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
But I will not work in flame-threads anymore on my side.
Probably a good idea. The only thing I'm worried about is the fact that you are proposing both to remove and add things to distutils. Although backports will be available, how will this work? If I use a new version of distutils, and somebody uses 2.5 to install my package, how will he know how to fix the errors that appear? And how will my 2.6 package work under 2.7 if you remove backwards compatibility? -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
On Wed, Apr 8, 2009 at 12:11 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Wed, Apr 8, 2009 at 12:03, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
But I will not work in flame-threads anymore on my side.
Probably a good idea.
The only thing I'm worried about is the fact that you are proposing both to remove and add things to distutils. Although backports will be available, how will this work? If I use a new version of distutils, and somebody uses 2.5 to install my package, how will he know how to fix the errors that appear? And how will my 2.6 package work under 2.7 if you remove backwards compatibility?
I don't think we want to break any current feature in 2.7, we will probably just display deprecation warnings and keep them, then wait until the next python version. And if someone want to use your package, that uses a new feature that is not present in 2.5/2.6, he will need to install the backport. Some good practice will be needed for package developers for this (maybe a kind error message) Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
On Wed, Apr 8, 2009 at 13:01, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
I don't think we want to break any current feature in 2.7, we will probably just display deprecation warnings and keep them, then wait until the next python version.
And if someone want to use your package, that uses a new feature that is not present in 2.5/2.6, he will need to install the backport.
Some good practice will be needed for package developers for this (maybe a kind error message)
Well, that's survivable, if not ideal. I would push hard for a rename if I could just come up with a good name. But I can't. :-) -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
If anyone wants to work on it, or comment, Some comments:
"MANIFEST.in is fine" Except that it introduces Yet Another Domain Specific Language. Wtf does "prune" mean? It's not obvious. The docs indicate that it actually excludes, but why it's not called "exclude" is then strange. We already have a language, Python. We don't need more. ;-)
And the fact that is uses a separate file doesn't help.
Yes, I know I'm just whining. But I don't agree that MANIFEST.in is fine. I think it is unfine. :)
I agree with this. Remember: I wanted to deprecate MANIFEST.in in favor of a pure python description. Then people strongly objected.
I want *less* stuff (ideally nothing) spelled in imperative Python, with some common declarative file replacing both the information currently in setup.py and MANIFEST.in. I thought we were in agreement that non-introspectable metadata was a Bad Thing(TM)? http://wiki.python.org/moin/Distutils/StaticMetadata 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 iD8DBQFJ3JdV+gerLs4ltQ4RAhGbAJ4in8+UOgM5GJ/3ISGfU2VHLVh4tgCg13O1 qx4oVMxLRJXHUz794mW2UyM= =pgtS -----END PGP SIGNATURE-----
On Wed, Apr 8, 2009 at 14:23, Tres Seaver <tseaver@palladion.com> wrote:
I want *less* stuff (ideally nothing) spelled in imperative Python, with some common declarative file replacing both the information currently in setup.py and MANIFEST.in. I thought we were in agreement that non-introspectable metadata was a Bad Thing(TM)?
For me, the important part is that it's not spread around many files. I would also tend to prefer some INI-type file format than python code. On the other hand, python code offers benefits such as being able to dynamically change the data depending on things like module availability and python version, etc. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
Tres Seaver wrote:
Tarek Ziadé wrote:
On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
If anyone wants to work on it, or comment, Some comments:
"MANIFEST.in is fine" Except that it introduces Yet Another Domain Specific Language. Wtf does "prune" mean? It's not obvious. The docs indicate that it actually excludes, but why it's not called "exclude" is then strange. We already have a language, Python. We don't need more. ;-)
And the fact that is uses a separate file doesn't help.
Yes, I know I'm just whining. But I don't agree that MANIFEST.in is fine. I think it is unfine. :) I agree with this. Remember: I wanted to deprecate MANIFEST.in in favor of a pure python description. Then people strongly objected.
I want *less* stuff (ideally nothing) spelled in imperative Python, with some common declarative file replacing both the information currently in setup.py and MANIFEST.in. I thought we were in agreement that non-introspectable metadata was a Bad Thing(TM)?
It is possible to use a single, static format which is a bit more powerful than .ini (to allow conditional and the likes), like haskell packaging tool does [1] (or rpm .spec file does as well [2]). I am convinced that such a format would cover many needs without even needing any python code except a dummy setup file. It also has the advantages that it can be made compatible with distutils and a potential successor. This problem has been solved by other people in other communities. It may not be perfect, but it is certainly better than the current distutils situation, and it has been widely used, cheers, David [1] http://www.haskell.org/cabal/release/cabal-1.6.0.2/doc/users-guide/authors.h... [2] http://www.rpm.org/max-rpm/s1-rpm-inside-conditionals.html
On Wed, Apr 8, 2009 at 2:23 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tarek Ziadé wrote:
On Tue, Apr 7, 2009 at 8:47 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Tue, Apr 7, 2009 at 20:18, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
If anyone wants to work on it, or comment, Some comments:
"MANIFEST.in is fine" Except that it introduces Yet Another Domain Specific Language. Wtf does "prune" mean? It's not obvious. The docs indicate that it actually excludes, but why it's not called "exclude" is then strange. We already have a language, Python. We don't need more. ;-)
And the fact that is uses a separate file doesn't help.
Yes, I know I'm just whining. But I don't agree that MANIFEST.in is fine. I think it is unfine. :)
I agree with this. Remember: I wanted to deprecate MANIFEST.in in favor of a pure python description. Then people strongly objected.
I want *less* stuff (ideally nothing) spelled in imperative Python, with some common declarative file replacing both the information currently in setup.py and MANIFEST.in. I thought we were in agreement that non-introspectable metadata was a Bad Thing(TM)?
I consider the MANIFEST static file itself to be part of the metadata. and the discussions we had were related to the way to *build* this file. which is not incompatible to what you have proposed I think. I can imagine a declaration in setup.cfg to provide the commands the options to use to build metadata, like: metadata-builder= LIST OF PLUGINS TO USE for example, a Mercurial script + a MANIFEST.in reader would write in setup.cfg: metadata-builder=hg,template Or someone could write another plugin that builds the file in imperative Python, but that is not part of setup.py. Maybe we could start to write down examples of such setup.cfg files for a few project out there, in this wiki page. Tarek
participants (4)
-
David Cournapeau -
Lennart Regebro -
Tarek Ziadé -
Tres Seaver