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

[Kevin Ollivier]

Hi all,

While I personally think Jack's approach is the best from a 
functionality point of view, I do agree with Just's position and I 
think we should not be storing any Python executable code into the 
plist files, version checking or otherwise. Doing things like running 
setup.py should take place within package manager, using the plist 
files to determine where said file is, etc.
I think this is bad from a security perspective and like wxPython we've 
seen that module conflicts could occur.

I think the solution to both Just and Jack's problems is to have a 
standard way in Python to store a version number that is NOT inside a 
Python code file. PKG-INFO springs to mind. Now, it doesn't solve our 
immediate problem re: dependencies but remember, we're designing 
software that is not even known by most of the Python community at this 
point. Once it is better known (I agree with Jack about the PEP), and 
people know that writing a simple PKG-INFO file and placing it in the 
root of their module will cause it to work well with PackageManager, 
they will start doing this. It also means we can take advantage of 
PKG-INFO even when PM didn't install the package.

What do you think?

Thanks,

Kevin

On Friday, October 3, 2003, at 07:33  AM, Jack Jansen wrote:

>
> On Friday, October 3, 2003, at 11:15 AM, 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.
>>
>> Apart from availability/version tests, we're going to _need_ receipts 
>> if
>> we want to support uninstalls.
>
> You're absolutely right. The statement I really wanted to make above
> was: "Using receipts for version testing is specifically what I 
> *don't* want".
>
>>> 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.
>>
>> 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.
>
> Not for package X but for dependent packages! Think of the following
> scenario: you maintain package X, that is also in PackMan. Package Y
> depends on package X but you don't maintain it. With a know-it-all
> package manager you cannot install Y to use your X.
>
> There are now three options open to you:
> - trick the package manager to think that it installed X
> - install every package depending on X by hand
> - install two copies of X, one for your development and one
>   through the package manager for use by dependent packages.
>
> All of this falls under my favorite annoyance #4: things that
> get in the way of developers for no obvious reason.
>
>> PackMan is for end users. A certain amount of complexity for
>> _developers_ seems pretty much unavoidable, and would be totally
>> acceptable to me.
>>
>> I strongly feel that executing arbitrary code (even from a trusted
>> source) is a big nono.
>
> Uhm... How about arbitrary setup.py scripts included with packages?
> --
> Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma 
> Goldman
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>