[Distutils] distlib and wheel metadata

[Jim Fulton]

On Tue, Feb 14, 2017 at 2:40 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk>
wrote:

> > Nope.  Honestly, though, I wish there was *one* *library* that defined
> the standard,
> > which was the case for setuptools for a while (yeah, I know, the warts,
> really, I know)
> > because I really don't think there's a desire to innovate or a reason
> for competition
> > at this level.  In the case of wheel, perhaps it makes sense for that
> implementation to
> > be authoritative.
>
> The problem, to me, is not whether it is authoritative - it's more that
> it's ad hoc, just like
> setuptools in some areas. For example, the decision to use "metadata.json"
> rather than
> "pydist.json" is arbitrary, and could change in the future, and anyone who
> relies on how things
> work now will have to play catch-up when that happens.


Unless they depend on a public API provided by the wheel package.  Of
course, you could argue that the name of a file could be part of the API.

In many ways, depending and building on a working implementation is better
that drafting a standard from scratch.

Packaging has moved forward largely by people who built things
 pragmatically that worked and solved every-day problems:
setuptools/easy_install, buildout, pip, wheel...


> That's sometimes just too much work for
> volunteer activity - dig into what the problem is, put through a fix (for
> now), rinse and
> repeat - all the while, little or no value is really added.
>
> In theory this is an "infrastructure" area where a single blessed
> implementation might be OK,
>

I think so.


> but these de facto tools don't do everything one wants, so
> interoperability remains important.
>

Or collaboration to improve the tool.  That *should* have worked for
setuptools, but sadly didn't, for various reasons.


> There's no reason why we shouldn't look to innovate even in this area -
> there's some talk of a
> GSoC project now to look at dependency resolution


Yay! (I saw that.)


> for pip


Gaaaa. Why can't this be in a library? (Hopefully it will be.)

- something that I had sort-of working
> in the distil tool long ago (as a proof of concept) [1].


Almost is a hard sell.  If this was usable as a library, I'd be interested
in trying to integrate it with buildout. If it worked, many buildout users
would be greatful. Perhaps the GSoC project could use it as a reference or
starting point.

We've gotten so used to how pip and

setuptools work, and because they are "good enough", there is a real
> failure of imagination
> to see how things might be done better.
>

I think there is a failure of energy. Packaging should largely be boring
and most people don't want to work on it. I certainly don't, even though I
have.

But you picked a good example.

There are major differences (I almost said competition) between pip and
buildout. They provide two different models (traditional Python system
installs vs Java-like component/path installs) that address different use
cases. IMO, these systems should complement each other and build on common
foundations.

Maybe there are more cases for innovation at lower levels than I'm aware of.

Jim

-- 
Jim Fulton
http://jimfulton.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170214/ff3039be/attachment.html>