[Distutils] Module from install breaks subsequent install of different distribution

Nick Coghlan ncoghlan at gmail.com
Tue Jan 20 11:39:32 CET 2015

On 20 Jan 2015 09:11, "Ben Finney" <ben+python at benfinney.id.au> wrote:
> Tres Seaver <tseaver at palladion.com> writes:
> > On 01/19/2015 04:57 PM, Ben Finney wrote:
> > > My current position would be: that's a bug in Setuptools, it should
> > > not be applying entry points defined for package FOO when running the
> > > setup for some other package BAR.
> > >
> > > Is that right? Should I report a bug against Setuptools for this
> > > behaviour?
> >
> > Notabug. setuptools itself is extensible by means of entry points.
> > Both entry points in your example (as cited by Marius) demonstrate
> > that: one adds support for a new keyword argument to 'setup()'[1], and
> > the other defines a new "writer" for 'egg-info'[2]. By design, both of
> > those are supposed to be loaded / available for any invocation of
> > 'setup()' in a Python where the are installed (not merely for packages
> > which "mention" them).
> I can see the logic when it's explained, but that doesn't make it not a
> bug IMO. That's a pretty astonishing behaviour: a declaration in the
> setup for one package has a mystifying effect on the setup of other
> packages.
> I won't press the point. Hopefully, though, someone does consider it a
> bug worth fixing.

It's an artefact of setuptools's origins in the Chandler project: it
assumes it *is* the build infrastructure for the entire integrated system,
which is thoroughly wrong in the context of a Linux distribution.
easy_install has the same origins and hence the same problematic

On the installation side, changing the underlying design assumption to
"potentially only one component of a larger system" is one of the most
critical differences between easy_install and pip.

I'd like to see us achieve a similar replacement on the build side as well,
but cross platform build support is such a hard problem that it's currently
easier to tolerate the occasional quirk than it is to figure out a viable
transition plan to migrate to a less surprising build management system.


P.S. For example, Meson is an interesting project that I encountered at
LCA2015 last week and would like to learn more about. In particular, it
apparently has a JSON based metadata format aimed at implementation
independent integration between IDEs and build systems that may be well
worth exploring further.

> --
>  \       “To have the choice between proprietary software packages, is |
>   `\      being able to choose your master. Freedom means not having a |
> _o__)                        master.” —Richard M. Stallman, 2007-05-16 |
> Ben Finney
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150120/6e578d1e/attachment.html>

More information about the Distutils-SIG mailing list