On Thu, Oct 9, 2008 at 11:23 PM, Wichert Akkerman <[EMAIL PROTECTED]> wrote: > > Previously Christopher Barker wrote: >> So, is there a way to turn off the use of pkg_resources in paste? > > No, paste relies on it to handle entry points in various places. That is > a very popular pattern that more and more things are starting to use.
Popular, but it's still on unstable ground because Setuptools isn't built into Python yet,. This is just one of a series of problems people have when installing Pylons. It's worth remembering that there aren't many packages that depend on others, much less a multilevel dependency -- Pylons and TurboGears are about it. Unfortunately that puts the onus on us to either fix the Setuptools problems ourselves, complain to the developers, or make Pylons/Paste less dependent on Setuptools. The last alternative seems to be the easiest. Hell may freeze over before Python fully supports Setuptools or provides an alternative. The whole idea of importing an application by entry point when you already know what the module is called and it's already been installed is kind of funny. But in this case, the problem seems to be not entry points or namespace packages but pkg_resources.require. The purpose of pkg_resources.require, according to its documentation, is to guarantee version dependencies are satisfied and to activate eggs that are along sys.path but not on it. I tend to think this whole concept is obsolete now that you can install different versions into different virtual environments. I don't know of anybody who has installed multiple versions of a package into the same directory, and then had two applications that each used pkg_resources.require to activate a different version. On the other hand, I know people who have hesitated to use pkg_resources.require because that makes the application or library depend on Setuptools. Chris's point is, why not just import the thing first, and then if that doesn't succeed you can try some fancy magic to activate it. We're going to try instantiating the server and app manually (using NicerConfigParser to get the config variables, and ignoring the 'use' variable), and see if that bypasses enough of the dependency checking to satisfy py2app. In a GUI application you can't run the full Paster anyway; you have to load the server and app in Python code and then call the server. So we're already going a bit low level, and this will just be lower still. We also want to try bbfreeze on the Mac so we'll be a guinea pig for it. But we have to deliver the application by the end of November so we can't use something that "might work but on the other hand it may crash in the user's face". So it'll depend on how stable it is, and whether it produces a "one-click install" package like users expect. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
