At 03:01 PM 8/19/2005 -0400, Kevin Dangoor wrote:
On 8/19/05, Jay Parlar firstname.lastname@example.org wrote:
They were both in site-packages, and in easy_install.pth, they were installed in the typical easy_install.py manner. But as the origins of this email thread showed, I was having trouble getting py2exe to see them even there.
Did you try installing them with the -Z (--always-unzip) option? Just curious if that makes any difference to how py2exe works its dependency magic.
I do remember encountering some of these stdlib problems myself, but not since early on when I started playing with setuptools. I only have a handful of the packages I use turned into eggs at this point, though.
Yeah, I'm starting to think that the ultimate solution to this is going to be to build Bob Ippolito's modulegraph into setuptools, and put external import info into the egg metadata at build time. Then tools like py2exe and py2app could just read the metadata for all the external packages you're using. bdist_egg already has to scan all your modules if you don't specify a zip_safe flag, so having it build a dependencies list too probably isn't a big deal.
For that matter, maybe I should add a "basket" command that builds a nice library.zip with pkg_resources, the application, and all its eggs. Then commands like py2exe and py2app could just focus on making the front-end wrappers, rather than on the grunt work of figuring out what modules the application needs.
I'm not sure how well that would work with all of e.g. py2exe's special-casing of various DLLs and whatnot, though. Nonetheless, I'd like to hear Bob and Thomas' thoughts on the idea, as it would let us consolidate some of the infrastructure and maybe make cross-platform apps buildable from a single setup script. (Especially if most of the py2exe-specific or py2app-specific options can be moved to setup.cfg, where they'll only be processed if running that particular command.)