On 2 Aug, 2010, at 3:27, Christopher Barker wrote: > Ronald Oussoren wrote: >>> This is a problem in general with all ctypes uses. In fact, ctypes >>> reminds me a bit of py2app in the sense that it has some built-in >>> algorithms for searching for dynamic libs, and that these fail fairly often. >> Please file bugs for that, I'm pretty sure that ctypes is supposed to >> implement the same algoritms as the platform dynamic linker. > > IIUC, on OS-X, the full path to a dll is specified when linked -- it sure > seems that way. > > So there is no "normal search path". But anyway, what I've seen is pacakges > that don't find macports stuff, etc. > > I've had to patch the package to make it work at all -- I haven't tried to us > py2app on any of those yet though. When I do, I'll post a bug report here, > though.
It would be better to post ctypes issues on bugs.python.org, that way the issue won't get lost and all python contributers can see the issue and work on it. > >> W.r.t. py2app: I consider cases where py2app doesn't find modules or >> shared libraries bugs and should be fixed, either by making the core >> smarter or by adding recipes. Please post reports about issues, >> especially when you can reproduce them in smallish examples (or at >> least examples that you can share with the outside world). > > will do. > > But there aer some cases where dynamic importing is simpily goign to fail, > and you can get a lot of those covered with recipes that bring in big 'ol > packages that aren't needed, but I'm not sure I always want that. Dynamic imports will always be a problem, and we need a way to specify the required behaviour in the setup.py script. As an example, when I use SQLAlchemy in a project there should be a clean way to specify which drivers I want in the setup.py script, and the SQLAlchemy recipe should have a way to get to this information and should also have a way to error out when the user hasn't specified which database drivers he wants. > > And if the dynamic import is part of your own code, then it shouldn't be a > recipe anyway. Maybe, maybe not. I wouldn't mind adding a public API for external recipes, that way you could add recipes for your own libraries. > > But yes, the mainstream packages should all "just work". > >>> As for py2app, maybe the ctypes recipe could patch ctypes to look >>> in a particular place in the bundle, and then the user could >>> specify which libs ctypes used, and py2ap would put them in the >>> bundle. >> Yes, but that will require some additional trickery to ensure that >> ctypes looks in this special location before looking at the full name >> specified by the caller. > > yup. Maybe not worth it. I haven't looked at the ctypes code yet. I would be worth it if it can be done with little effort, but not when it requires major engineering. > >> Actually finding which libraries are loaded using ctypes will sadly >> enough be impossible in general, although recipes could be used for >> the popular libaries. > > Agreed. > > Thanks, > > -Chris > Ronald
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
