<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 21 Oct 2015 at 10:17 Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21 October 2015 at 17:42, Chris Barker <<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>> wrote:<br>
> So why not have a setuptools-lite that only does the building? We need to<br>
> keep the full over-burdened setuptools around, because lot sof folks are<br>
> using those features. But for those of us that are doing something fairly<br>
> new, and don't want to use stuff that setuptools "shouldn't" be doing, I'd<br>
> love to have a setuptools-lite that only did what I really need, and was<br>
> guaranteed NOT to accidentally introduce easy_install, etc...<br>
<br>
In general, this sounds like a reasonable idea. But, there are the<br>
usual problems:<br>
<br>
1. Someone needs to do the work.<br>
2. Backward compatibility (as in, there's bound to be some projects<br>
out there using whatever functionality you can think of that "nobody<br>
would ever need"...)<br>
<br>
And a third issue specific to this idea.<br>
<br>
3. You can't call it setuptools, and pip "injects" the real setuptools<br>
into projects when building/installing. Pretending to be setuptools<br>
was what made distribute such a PITA to deal with, and I don't imagine<br>
we'd ever want to go there again.<br>
<br>
Sorry, I'm being a downbeat grump today. The reality is that far and<br>
away the best shot we've had at getting out of this mess is the plan<br>
we're currently working to, which is to standardise interfaces, and<br>
once we have some standards, we can start decoupling the various bits<br>
and *then* replacing them as needed. We need people working on that in<br>
the first instance, work is currently stalled by lack of time from the<br>
key participants. So anyone with energy for moving this whole area<br>
forward would be really welcome to help out with the interoperability<br>
standards (metadata 2.0, defining a sdist format, pinning down pip's<br>
interfaces to build systems, things like that). But if you want to<br>
rework the existing toolset, you're probably going to be on your own<br>
(and there's unfortunately a risk that you'll pull attention away from<br>
other work via debates on this list etc).<br>
<br>
I really appreciate the enthusiasm we're seeing from people on the<br>
list at the moment, it's a matter of harnessing that into the right<br>
direction. As a thought, does anyone feel like working on an<br>
"interoperability standards roadmap" that provides a reference for<br>
where the PyPA see things going? It would be useful to keep focus, but<br>
the information's currently scattered about various mailing lists and<br>
discussions - some of the posts around the recent "new source<br>
distribution format" threads might be a good place to start.<br></blockquote><div><br></div><div>Would it makes sense to start a roadmap doc/repo under the PyPA account so the current grand vision is written down in a very high-level overview and then what the issues needing solving for each bit are along with any in-progress work are kept in a single place (I don't care if this is one big doc or there is the overview doc and then an individual doc per part of the grand vision)? Putting it up on GitHub allows for quick PRs on some Markdown doc that people can do quickly after an email thread reaches some form of a conclusion. </div></div></div>