[Distutils] wheels, metadata

[Nick Coghlan]

On 24 January 2014 06:18, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>
> --------------------------------------------
>
>> certainly mention the distlib implementations,
>> but also let's be clear if there is a pypa-recommend
>> tool that is user-facing (like pip), that is using those
>> parts of distlib.
>> In most cases, that is not true currently.
>> As for mentioning distil,  I'm inclined to
>> say no.   Up to this point, you've presented it as a
>> proof of concept.If you're wanting to mention
>> "distil" as a real option for users, I'm
>> concerned about fracturing the mind of users, but it's
>> something to discuss I guess.
>
> I hear what you're saying. I've positioned distil as a proof of concept purely because it hasn't had widespread use, but I certainly expect it to fulfil the same role as pip functionally (which it must do to be an effective test-bed for distlib). I understand that pip is the officially recommended tool, and don't want to muddy the waters, there being enough confusion about packaging in the wider community. It seems a shame that some of the improvements over pip won't be more widely available, but such is life. I have the use of them, so there's that :-)

The fact we're still working on PEP 426/440/459 so distlib and distil
are chasing a moving target also makes it a little difficult to
recommend them to end users at this point :)

I actually expect that we'll see many of the internals of pip
significantly refactored in the next 12 months or so - in addition to
metadata 2.0, there's also The Update Framework support as a result of
PEP 458, and once we get proper metadata publication on PyPI, then
adopting a real dependency solver becomes a far more viable option
than it is today (and both conda and Fedora's hawkey have tackled the
problem of making a depsolver available to a Python based installation
tool).

pip, ultimately, is just a CLI - so long as that remains the case,
then the internals can change radically (which is why I agree with the
idea of it *not* having a public Python API, and instead leaving that
to distlib).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia