On 6/20/12 1:19 PM, Paul Moore wrote:
On 20 June 2012 11:34, Tarek Ziadé<tarek@ziade.org> wrote:
On 6/20/12 11:54 AM, Antoine Pitrou wrote:
On Wed, 20 Jun 2012 09:51:03 +0000 (UTC) Vinay Sajip<vinay_sajip@yahoo.co.uk> wrote:
Antoine Pitrou<solipsis<at> pitrou.net> writes:
Deciding to remove packaging from 3.3 is another instance of the same mistake, IMO.
What's the rationale for leaving it in, when it's known to be incomplete/unfinished? As an incentive for users to start using the features that are finished enough, and exercise the migration path from distutils. The module can be marked "provisional" so as to allow further API variations. It's true that some modules are quite mature and already useful:
- packaging.version (PEP 386) - packaging.pypi - packaging.metadata (PEP 345) - packaging.database (PEP 386)
the part that is not ready is the installer and some setuptools bridging I've never seen that information mentioned before. So that's (good) news.
A question, then. Why is it not an option to:
1. Rip out all bar those 4 modules. 2. Make sure they are documented and tested solidly (they may already be, I don't know). 3. Declare that to be what packaging *is* for Python 3.3.
Whether any of those modules are of any use in isolation, is a slightly more complex question. As is whether the APIs are guaranteed to be sufficient for further development on "the rest" of packaging, given that by doing this we commit to API stability and backward compatibility. Your comment "quite mature and already useful" is not quite firm enough to reassure me that we're ready to set those modules in stone (although presumably the 3 relating to the PEPs are, simply because they implement what the PEPs say).
The last time I checked: packaging.version is the implementation of PEP 386, and stable. It's one building block that would be helpful as-is in the stdlib. it's completely standalone. packaging.metadata is the implementation of all metadata versions. standalone too. packaging.pypi is the PyPI crawler, and has fairly advanced features. I defer to Alexis to tell us is it's completely stable packaging.database is where PEP 376 is. It has the most innovations, implements PEP 376 packaging.config is the setup.cfg reader. Ity's awseome because together with packaging.database and packaging.markers, it gives you OS-independant data files. see http://docs.python.org/dev/packaging/setupcfg.html#resources Yeah maybe this subset could be left in 3.3 and we'd remove packaging-the-installer part (pysetup, commands, compilers) I think it's a good idea !
Paul.