On Wed, Oct 21, 2015 at 10:17 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 21 October 2015 at 17:42, Chris Barker <chris.barker@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@noaa.gov