[Distutils] Q about best practices now (or near future)

Brett Cannon brett at python.org
Fri Jul 19 17:20:46 CEST 2013


On Thu, Jul 18, 2013 at 8:33 PM, Daniel Holth <dholth at gmail.com> wrote:

> On Thu, Jul 18, 2013 at 8:15 PM, Donald Stufft <donald at stufft.io> wrote:
> >
> > On Jul 18, 2013, at 7:37 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk>
> wrote:
> >
> >>> I think the point is that people might be dependent on this
> functionality and
> >>
> >>> changing it out from underneath them could break their world.
> >>
> >>
> >> I got the point that Daniel made, and my question was about *how* their
> world would break, and whether we really need to support multiple versions
> of something installed side-by-side, with on-the-fly sys.path manipulation.
> If that is a real requirement which should be supported, shouldn't there be
> a PEP for it, if it's coming into Python? It's not supported by distutils,
> and it has been a point of contention.
> >>
> >> A PEP would allow standardisation of the multiple-versions feature it
> it's considered desirable, rather than definition by implementation (which
> I understand you're not in favour of, in general).
> >>
> >> If it's not considered desirable and doesn't need support, then we only
> need to consider if it's undeclared setuptools dependencies that we're
> concerned with, or some other failure mode not yet identified - hence, my
> questions. I like to get into specifics :-)
> >
> > Yes I'm against implementation defined features. However this is already
> the status quo for this particular implementation. Basically I'm worried we
> are trying to fix too much at once.
> >
> > One of the major reasons for distutils/packaging failing was it tried to
> fix the world in one fell swoop.  I see this same pattern starting to
> happen here. The problem is each solution has a bunch of corner cases and
> gotchas and the more things we try to fix at once the less eyes we'll have
> on each individual one and the more rushed the entire toolchain is going to
> be.
> >
> > I think it's *really* important we limit the scope of what we fix at any
> one time. Right now we have PEP426, PEP440, PEP439, PEP427, Nick is talking
> about an Sdist 2.0 PEP, Daniel just posted another PEP I haven't looked at
> yet, this is going to be another PEP. On top of that we have a number of
> issues related to those PEPs but not specifically part of those PEPs.
> >
> > A lot of things is being done right now and I personally have having
> trouble keeping up and keeping things straight. I know i'm not the only one
> because I've had a number of participants of these discussions privately
> tell me that they aren't sure how I'm keeping up (and i'm struggling to do
> so). I really don't want us to ship a bunch of half baked / not entirely
> thought through solutions.
> >
> > So can we please limit our scope? Let's start by fixing the stuff we
> have now, punting on fixing some other problems by using the existing
> tooling and then let's come back to the things we've punted once we've
> closed the loop on some of these other outstanding things and fix them
> better.
>
> I feel your pain.
>
> We might as well allow happy setuptools users to continue using
> setuptools. I don't care about making a pkg_resources console_scripts
> handler that does the same thing because we can just use the existing
> one. The more important contribution is to provide an alternative for
> people who are not happy setuptools users.


Which is an argument, in my mind, to vendor setuptools over bundling
(assuming people are using "bundling" as in "install setuptools next to pip
or at least install a .pth file to access the vendored version"). Including
pip with Python installers is blessing it as the installer, but if we
include setuptools as well that would also be blessing setuptools as *the*
building tool as well. If people's preference for virtualenv over venv
simply because they didn't want to install pip manually has shown us
anything is that the lazy path is the used path.

If the long-term plan is to bless setuptools then go for the bundling, but
if that decision has not been made yet then bundling may be premature if
the bundling of pip with Python moves forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130719/ac19e00c/attachment.html>


More information about the Distutils-SIG mailing list