On Thu, Feb 28, 2013 at 1:23 PM, PJ Eby <[email protected]> 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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
