[Distutils] [Catalog-sig] Deprecate External Links

Daniel Holth dholth at gmail.com
Thu Feb 28 19:39:53 CET 2013


On Thu, Feb 28, 2013 at 1:23 PM, PJ Eby <pje at telecommunity.com> wrote:
> Indeed.  I'm hoping that the new tools will make the old ones (e.g.
> setuptools) entirely irrelevant, which is why I'm hammering so hard in
> the PEP discussions on some use cases that eggs do well that wheels
> don't.  I don't want people to have to keep using setuptools for those
> use cases.  (e.g. simple plugin deployment ala Trac)  If the new tools
> handle all of the use cases, then setuptools can die a natural death
> sometime in the next decade or so, so I don't have to be responsible
> for it when I turn old and senile.  (It's already turned me grey as it
> is.)  ;-)

Continued from catalog-sig...

On my obsolete-setuptools checklist:

- include just a small part of the pkg_resources API especially the
"resources" API into a new standalone pkg_resources "pip install
pkg_resources" distribution, backed by a different API. The parts only
installers need would be excluded.
- figure out what to do about the runtime-linker features

I was always rather unhappy about .egg plugins in trac and am used to
using lots of virtualenvs instead, but I think it is right to continue
offering that kind of feature.

Wheel is billed as an installation format but it is intentionally very
similar to egg with revisions to what were in my opinion the most
annoying parts, namely "wait for the packager to catch up when a new
Python comes out" and "the EGG-INFO directory has the same name in all
eggs". There's nothing stopping anyone from writing an "append .pyc
files to this archive" script to overcome what's probably the first "I
don't want to use this as a plugin" complaint. "Don't go crazy with
paths in .data/" would be a second piece of advice for the budding
plugin author.


More information about the Distutils-SIG mailing list