On Friday, Oct 3, 2003, at 15:38 America/New_York, Just van Rossum wrote: > Kevin Ollivier wrote: > >> I think PackMan needs to generally support installing external >> libraries (Python in general is great as a wrapper for C++ modules), > > As Bob and Ronald said, if feasable, linking such a lirbrary statically > causes the least problems. <nitpick>Well, I said feasible ;) Which is correct spelling over here in the US, not sure about elsewhere</nitpick> >> but I think the solution to the cross-platform is to have platform >> specific databases, as Jack has been doing. You can still have >> cross-platform packages (i.e. all Python source), they just need to >> be added to each of the platform specific databases. The >> platform-specific packages can just point to a different install file >> on each platform. The only problem is that for some people this is >> doing three times the work when it's really redundant. > > I'm not so much worried about the database part, but I do worry about > whether there is a cross platform notion of what a library _is_. On OSX > we have the luxury of having frameworks that can contain lots of stuff. > But should packman be able to install (for example) Tcl/Tk on other > unixy platforms? On Windows? I'm feeling rather pessimistic about that, > so I tend to think that installing external libraries is beyond the > scope of PackMan. On Windows you can throw the DLLs somewhere near python.exe or the .pyd files (I forget which) and it will probably find them. This is solvable, and I see PackMan being a big hit for Windows users. I have a Windows machine at work and could figure this out once we're to that point, but I really only care about OS X. On OS X we can definitely put stuff wherever we need to and be able to find it. I'm already doing this with the SDL libraries, though in retrospect I want to shove them in the Python tree and include some metadata somewhere so that bundlebuilder will know that whenever it bundles pygame it should also bring over the frameworks. bundlebuilder *could* troll the mach-o header of the .so's for @executable_path/../Frameworks and do this right now without modification of the installation process. Another problem I've had with bundlebuilder is that some packages put "resource files" in their package, for example pygame includes the default .icns file and at least one .ttf that it needs for correct operation. It would be nice if pygame could tell bundlebuilder (by external metadata or directly) that it needs to have all of its files included in a plain way, not be shoved in a zip file. On Linux.. I don't know. Linux will typically already have dependencies like Tcl/Tk installed, and Linux users will probably be using something other than PackMan to install Python modules sanctioned by the OS vendor anyways (i.e. apt-get, rpm, whatever). I think that there are way too many flavors of linux to even think about where to find or put things (stuff that doesn't traditionally go in site-packages, that is) and users are more likely to have say, changed their ld.so.conf and put the module somewhere crazy than to change the search path on Windows or OS X. -bob
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4