[Distutils] Time for a setuptools_lite??

[Chris Barker]

On Wed, Oct 21, 2015 at 10:17 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 21 October 2015 at 17:42, Chris Barker <chris.barker at noaa.gov> wrote:
> > So why not have a setuptools-lite that only does the building?



> In general, this sounds like a reasonable idea. But, there are the
> usual problems:
>
> 1. Someone needs to do the work.
>

well, yeah -- that's the always the big problem.


> 2. Backward compatibility (as in, there's bound to be some projects
> out there using whatever functionality you can think of that "nobody
> would ever need"...)
>

actually, this is exactly the problem I'm trying to address with this idea.
Lots of people use setuptools, and you can bet the someone, somewhere, is
using every little feature (and counting on a bug) than it has. Which is
why distribute merged into setuptools -- I wasn't involved in the
conversation at that point, but I think it more or less started as a "new,
better, setuptools replacement", and then turned into a "maintained and
updated setuptools".

What I do remember from those days is that setuptools itself had fallen
into a maintenance hole -- very frustrating. But fixing that means that
distribute lost its goal of actually making it better.

The idea here is to provide an upgrade path -- if you want to do thing the
new way (the sane way :-) ), then drop in setuptools_lite, and see what
breaks -- then decide to remove or refactor the things that setuptools_lite
doesn't support, or just go back to setuptools.

3. You can't call it setuptools, and pip "injects" the real setuptools
> into projects when building/installing. Pretending to be setuptools
> was what made distribute such a PITA to deal with, and I don't imagine
> we'd ever want to go there again.
>

no -- it would be setuptools_lite -- different name :-) Or it would be a
somewhat-disabled setuptools -- which would be the distribute problem
again. But I _think_ the problem with distribute was that people WANTED it
to have all the functionality of setuptools -- and going back to setuptools
wasn't a good option because it was no longer well maintained (see above).
Granted, I wasn't in the trenches then, or even lurking -- but I was a
user, and trying to teach python newbies what to do -- and yes, it did kind
of suck.

As I understand it, pip injects setuptools because pip really needs a build
tool that does things that distutils doesn't. And there are no other build
tools. But that architecture really sucks -- pip should not have to rely on
injecting a particular package, but rather be able to rely on a given API
to be available.

I have no idea how we can get from here to there cleanly, but it would it
be that big a deal for pip to look for either setuptools or
setuptools_lite, and neither are there, inject setuptools_lite.

The whole point is that setuptools_lite would have everything that pip
needs.

Sorry, I'm being a downbeat grump today.


not at all -- this has been an ugly mess for a long time -- we really,
really need the folks with experience to keep  things in check :-)


> The reality is that far and
> away the best shot we've had at getting out of this mess is the plan
> we're currently working to, which is to standardise interfaces, and
> once we have some standards, we can start decoupling the various bits
> and *then* replacing them as needed.


well, yes. But my idea here is to have something for users to do in the
interim -- right now, I HAVE to use setuptools -- it's the only thing that
knows how to find the compiler on Windows, and pip needs it to install.

So there is no way for me not to find it really easy to accidentally use
setuptools features that I don't want to use, and "shouldn't" use.

So while we are waiting for the grand future of clear APIs and well-defined
components, we can start getting people ready for that....

As I write this, I'm starting to think that despite my post a half hour
ago, probably the best way to do this is to add a __future__ feature to
setuptools:

import setuptools
setuptools.__future__()

or some such -- all it would do is remove and/or turn off stuff setuptools
should no longer be doing.

And this might actually help with the "standardise interfaces" part of the
project. Essentially a working prototype of what the build tool needs to
support. If turn off a feature, we may find that it's needed -- then we can
decide where that feature needs to live.

But if you want to
> rework the existing toolset, you're probably going to be on your own
> (and there's unfortunately a risk that you'll pull attention away from
> other work via debates on this list etc).
>

Fair enough -- though I"m thinking of this as both a way to get something
useful sooner than later, AND a way to maybe test out some of the API
ideas. After all, there have been efforts to just build something new --
distutils2, etc -- maybe we need a more transitional, try it as you go
approach.


> As a thought, does anyone feel like working on an
> "interoperability standards roadmap" that provides a reference for
> where the PyPA see things going?


That would be great, yes!

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151021/48620b9f/attachment-0001.html>