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

[Bob Ippolito]

On Friday, Oct 3, 2003, at 05:15 America/New_York, Just van Rossum 
wrote:

> [Just]
>>> I don't think PackMan needs to be extensible to such an extent. Am
>>> I right that the current Python snippets only do version checks?
>>> Receipts would work just as well, provided we limit version
>>> checking to packages installed through PackMan. I think that's a
>>> reasonable constraint.
>
> [Jack]
>> No, receipts are specifically what I *don't* want. I want PackMan to
>> do actual tests of what is available.
>
[Just]
> Apart from availability/version tests, we're going to _need_ receipts 
> if
> we want to support uninstalls.

Distutils could/should make the Receipts.  If this gets into distutils, 
this problem is pretty much solved for all but the 
user-copied-this-to-site-packages-themselves case, but they're pretty 
much on their own as far as I'm concerned :)

[Jack]
>> The problem with receipts is that it causes a package manager to live
>> in a completely self-centered world: it knows about everything it
>> installed itself and nothing else. This means that if I'm an active
>> developer on package X I always have to go out of my way, because the
>> package manager doesn't know that I've built and installed it myself.

[Just]
> I don't follow: if you're building/installing package X yourself, why
> would you then want to use PackMan for package X also? I see it pretty
> much as an either/or situation.
>
> PackMan could still detect the availability of package X, and warn the
> user that it wasn't installed by PackMan itself, and therefore can't
> tell which version it is. With imp.find_module() this can even be done
> without doing an actual import -- which touches on another pet peeve of
> mine, see below.

I agree with Just here.

[Jack]
>> I've come across this problem with Fink, SGI-inst and various other
>> install managers. I want to build and install Python myself, and if
>> someone reports a problem with package Y that depends on Python I
>> want to use Fink to install Y, but let Y use my copy of Python (so I
>> can test whether the bug has disappeared with my fix, let's assume
>> for the discussion). This always turns out to be difficult without
>> learning the internals of the package manager in question.
>
[Just]
> Hm, this sounds like a reason to clearly document what PackMan does and
> how it works. And to keep it dead simple.
>
> PackMan is for end users. A certain amount of complexity for
> _developers_ seems pretty much unavoidable, and would be totally
> acceptable to me.

I agree with this too, I don't think that our target audience is Jack, 
Just, Ronald, and Bob who are probably half the people who would want 
to build Python on the Mac themselves.  Personally, if someone else had 
a database of precompiled modules I could install then I'd use theirs, 
so long as it was up to date and the modules had a tendency to work 
when I tried them.  I'm not terribly often changing the code of someone 
else's module and recompiling it (other than to get it to work on the 
Mac), and when I do that the version number is more or less undefined.  
I am the only one in possession of that particular modified package, 
neither the author or maintainer created it, and there will be another 
at some point with a higher version number created by the official 
source who may or may not received and implemented my changes.  As long 
as Package Manager has a certain amount of overrides so that I could 
(a) MAYBE be warned that "what you have is not an official version (as 
last seen by this database), are you sure you want to replace yours?" 
-- This check may be slow to do for large packages (would require 
calculating a hash, but maybe file sizes would be enough?). (b) have 
the option to install a package nomatter what PackMan thinks, 
unconditionally, if I've checked enough boxes then I think that would 
cover every use case for me personally.

[Just]
> I strongly feel that executing arbitrary code (even from a trusted
> source) is a big nono. I already have problems with doing arbitrary
> imports: we've seen that this can cause problems for packages/modules
> that have import side effects (not that _that's_ a good thing, but it
> isn't under our control). But we've had this discussion before, and I
> don't think we're likely to agree here...

I'm with Just on this.  Besides, if we do find that PackMan's 
version-detection-features can't do something in the future we could 
always issue a PackMan or pimp upgrade.

-bob