On 05/16/2012 02:35 AM, Tarek Ziadé wrote:
I know the idea of having packaging in the stdlib is something some people disliked, from day 1. And if I recall correctly, you did not like this either back then.
I've always been pro-stdlib-contains-a-package-installer-and-machinery, and I still am.
I am -1 on for two reasons: 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's fine to develop it inside the stdlib. It's harder to think about releasing it in 3.3 though without good docs. Do you think we have enough time to document it and define its scope and limitations and future plans in written form before 3.3beta1 ships?
2/ packaging is completely mature for some parts, like the PEP 386 implementation. And having the packaging.version module in the stdlib is a great step forward for standardization The pep 376 implementation is also providing great APIs to push all tools to inter-operate.
That's good to know.
If we develop this tool outside, I am afraid we will just add more confusion in the mix. 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 ?
I can. - C _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
