[Pythonmac-SIG] Package Manager idea, adding a URL scheme
bob at redivi.com
Fri Oct 3 15:55:21 EDT 2003
On Friday, Oct 3, 2003, at 15:38 America/New_York, Just van Rossum
> 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.
More information about the Pythonmac-SIG