[Pythonmac-SIG] Package Manager idea, adding a URL scheme

[Bob Ippolito]

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