On 05/16/2012 02:35 AM, Tarek Ziadé wrote:
1/ your argument about people being baffled about which tool to use will be worse if we work outside the stdlib. Having packaging in the stdlib and distutils frozen here, leads the path: "hey, the next tool in the stdlib is packaging"
It all depends on the documentation. If you have complete documentation that explains how to do everything I need to do, then I can use the new tool -- someday, when I have time to read that documentation, figure out how to use it, and convert my software. If you do not have complete documentation or if your documentation does not describe some feature that I need, then the message to me is quite clear: "Don't use this -- it doesn't do what you need". If you want people to adopt this new tool someday, then you should avoid training everybody to think that it is incomplete and that it doesn't work. Don't ask everybody to look at it before it is ready. ( If this were a commercial effort, you might want to release incomplete software so that you can build market share against your competitors. But in this case, there are no alternative suppliers who might release something any day now. There are only the legacy tools. )
Can you see packaging as a set of utility at this point, rather than a tool that's going to replace instantly all the legacy tools ?
If it is not going to replace the legacy tools, then why should I use it? My understanding is that the legacy tools already work, for some vague definition of "work". Your task is to convince me that "packaging" is better -- which I think will be hard to do if packaging is not better. Mark S. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
