[Python-Dev] Status of packaging in 3.3

[Tarek Ziadé]

On 6/20/12 1:19 PM, Paul Moore wrote:
> On 20 June 2012 11:34, Tarek Ziadé<tarek at 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 at 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.