On Aug 13, 5:47 pm, Michael Pedersen <[email protected]> wrote: > Well, if it's going away, it's going away. I'll simply have to provide a > path to help extension developers migrate forward.
Don't worry about that too much; setuptools 0.7 will support PEP 376, which means that there will be a reasonably clean migration path for applications using entry points to move to using future (3.x only) stdlib APIs to do the lookups. Even if I got hit by a bus and thus didn't implement a migration, you could still just write a little code to call the planned pkgutil extensions in PEP 376 to find and read the entry_points.txt files. (For that matter, you could just ship pkg_resources.py with your project and ignore setuptools altogether at that point.) I would also assume (perhaps incorrectly) that if the distutils2 team really wants to replace setuptools, it would make sense for them to include reasonable migration paths for setuptools features, in order to give people a reason to switch. > 1) there are a number of people who will not use any application that relies > > > on setuptools, so be prepared to listen to some people gripe > > 2) be prepared for some pain when/if you ever need to change to whatever > > the replacement for entrypoints ends up being > > I think that both those points are more simply stated as "It doesn't matter > what you do. You are going to make a very vocal group of developers and > users upset. Get ready for it." Heh. Ain't that the truth. But if you wrap the pkg_resources calls inside your API, then you can at least shield your users from most switching pains. The biggest pain will be that if a plugin stopped using setuptools, and distutils2 didn't support a way to do entry points, they'd have to just write entry_points.txt by hand and have distutils2 drop it into their .pkg-info directory on installation. Given that entry_points.txt is just a plain-text version of what you put in your setup.py for entry points already, it's probably not a big deal. (Especially since AFAIK, distutils2 is abandoning setup.py in favor of a setup.cfg, so the entry points would likely be the least of your pain for migrating.) > I'd be willing to drop setuptools, but I do need something to provide > equivalent functionality. The entrypoints of setuptools is the only > popularly deployed/deployable item that I'm aware of. Pretty much everything else out there is single-framework or single- application specific (i.e., Zope, Twisted, etc.) Eggs and pkg_resources, OTOH, were mostly written to create a generic platform for plugin deployment and discovery -- easy_install was practically an accidental side effect. ;-) -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
