<p dir="ltr"><br>
On 20 Jan 2015 09:11, "Ben Finney" <<a href="mailto:ben%2Bpython@benfinney.id.au">ben+python@benfinney.id.au</a>> wrote:<br>
><br>
> Tres Seaver <<a href="mailto:tseaver@palladion.com">tseaver@palladion.com</a>> writes:<br>
><br>
> > On 01/19/2015 04:57 PM, Ben Finney wrote:<br>
> > > My current position would be: that's a bug in Setuptools, it should<br>
> > > not be applying entry points defined for package FOO when running the<br>
> > > setup for some other package BAR.<br>
> > ><br>
> > > Is that right? Should I report a bug against Setuptools for this<br>
> > > behaviour?<br>
> ><br>
> > Notabug. setuptools itself is extensible by means of entry points.<br>
> > Both entry points in your example (as cited by Marius) demonstrate<br>
> > that: one adds support for a new keyword argument to 'setup()'[1], and<br>
> > the other defines a new "writer" for 'egg-info'[2]. By design, both of<br>
> > those are supposed to be loaded / available for any invocation of<br>
> > 'setup()' in a Python where the are installed (not merely for packages<br>
> > which "mention" them).<br>
><br>
> I can see the logic when it's explained, but that doesn't make it not a<br>
> bug IMO. That's a pretty astonishing behaviour: a declaration in the<br>
> setup for one package has a mystifying effect on the setup of other<br>
> packages.<br>
><br>
> I won't press the point. Hopefully, though, someone does consider it a<br>
> bug worth fixing.</p>
<p dir="ltr">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 assumptions.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
> --<br>
> \ “To have the choice between proprietary software packages, is |<br>
> `\ being able to choose your master. Freedom means not having a |<br>
> _o__) master.” —Richard M. Stallman, 2007-05-16 |<br>
> Ben Finney<br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>