Re: [Distutils] Deprecate MANIFEST.in
At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
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.
I mean understanding the use cases and how distutils features are used in the field. Deprecating something that people do understand and use, simply because you don't understand or use it, is not responsible stewardship for a stdlib package, IMO.
2009/4/6 P.J. Eby <pje@telecommunity.com>:
At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
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.
I mean understanding the use cases and how distutils features are used in the field. Deprecating something that people do understand and use, simply because you don't understand or use it, is not responsible stewardship for a stdlib package, IMO.
This is your point of view. But not the point of view of other people. And quit saying this is a unresponsible stewardship. IMHO the way you are driving setuptools since a few month now is *way* worse than anything done in this field. Unlike you, I am here to discuss things and try to find a consensus among people. And we have made more progress in a few months than you did I think. (people are working together and are not facing a bottleneck anymore) I didn't understand in the first place why people were moving away from distutils-SIG, now I get it . So please make you points but don't attack people that are trying to move things forward this is not a correct behavior in the Python community.
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
2009/4/6 P.J. Eby <pje@telecommunity.com>:
I mean understanding the use cases and how distutils features are used in the field.
This is of course true. But quite likely, the only one who does that is you. So it's up to you to document it so others can make solutions that are easy to understand. :)
I agree with you. But I 100% disagree with Tarek that the way to get there is by refactoring the distutils. The distutils are stable (i.e., dead and obsolete) and need to be *replaced*, not refactored.
One of the language summit conclusions was that many of the features if pkg_resources should make it into the stdlib, and that since distutils was stable, it was probably best to make that a new library. The same problem is true for any new feature in distutils, so quite possibly you are right. We need a "refactored" distutils with new features and with some of pkg_resources in it. And the easiest way to make that so it also works for Python 2.4 etc is to make it a completely new module. This also fixes the current problem with setuptools: That you are one of the few people who actually understand it, which makes you a bottleneck for development. The new module could very well start as a copy/fork of distutils. In fact, it probably should, so that nobody needs to start from scratch. But calling it something else means distribution of it gets easy, and we don't have to worry about backwards compatibility. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
2009/4/6 Lennart Regebro <regebro@gmail.com>:
2009/4/6 P.J. Eby <pje@telecommunity.com>:
I mean understanding the use cases and how distutils features are used in the field.
This is of course true. But quite likely, the only one who does that is you. So it's up to you to document it so others can make solutions that are easy to understand. :)
I agree with you. But I 100% disagree with Tarek that the way to get there is by refactoring the distutils. The distutils are stable (i.e., dead and obsolete) and need to be *replaced*, not refactored.
One of the language summit conclusions was that many of the features if pkg_resources should make it into the stdlib,
Some people are currently looking at that : extracting the good bits of pkg_resources.
and that since distutils was stable, it was probably best to make that a new library.
That was not exactly the conclusion of the summit. The idea is to make distutils a light, reference library, on wich third party libraries could implements OS-dependant features and so on. So part of the plan is to remove bdist_*, etc..
On Mon, Apr 6, 2009 at 17:46, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
That was not exactly the conclusion of the summit. The idea is to make distutils a light, reference library, on wich third party libraries could implements OS-dependant features and so on. So part of the plan is to remove bdist_*, etc..
Well, I wasn't involved in the final discussions, as I had to leave, but one of the problems mentioned with this is that distribution becomes a problem, as 2.4 already has a module called distutils, so there is no obvious way to know that you need to install a new version of it. Unless there is some magic hack for this which is guaranteed to always work (ha!) I would side with those who said it would be better if this distutils version is called something else than distutils. But if you can promise me that a package that needs a newer version of distutils will at a minimum exit with an error saying exactly how to upgrade it I will remove this objection. :) Also, renaming means you don't have to be backwards compatible. In particular, we don't have to make sure setuptools still works. So I would say both you and Philip are correct. Distutils should be refactored. And replaced. :) -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
participants (3)
-
Lennart Regebro -
P.J. Eby -
Tarek Ziadé