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? We need to
> keep the full over-burdened setuptools around, because lot sof folks are
> using those features. But for those of us that are doing something fairly
> new, and don't want to use stuff that setuptools "shouldn't" be doing, I'd
> love to have a setuptools-lite that only did what I really need, and was
> guaranteed NOT to accidentally introduce easy_install, etc...

In general, this sounds like a reasonable idea. But, there are the
usual problems:

1. Someone needs to do the work.
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"...)

And a third issue specific to this idea.

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.

Sorry, I'm being a downbeat grump today. 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. We need people working on that in
the first instance, work is currently stalled by lack of time from the
key participants. So anyone with energy for moving this whole area
forward would be really welcome to help out with the interoperability
standards (metadata 2.0, defining a sdist format, pinning down pip's
interfaces to build systems, things like that). 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).

I really appreciate the enthusiasm we're seeing from people on the
list at the moment, it's a matter of harnessing that into the right
direction. As a thought, does anyone feel like working on an
"interoperability standards roadmap" that provides a reference for
where the PyPA see things going? It would be useful to keep focus, but
the information's currently scattered about various mailing lists and
discussions - some of the posts around the recent "new source
distribution format" threads might be a good place to start.