[Distutils] GUI for Python package Management

Mark Sienkiewicz sienkiew at stsci.edu
Thu Jan 29 23:29:28 CET 2009


>>
>> I very much dislike things that automatically download and install 
>> software.  An automatic installer may find a different version of a 
>> supporting package every time I install software on another machine.
>
> if the application asks for the different version then yes it should 
> download the version that was asked for and installed for that 
> application. It will only find a different version each time if the 
> application asks for it.

Here is an example of the scenario I am trying to avoid:

Suppose the package foobar asks for "xyzzy > 2.3".

On machine Fred, I install foobar on Tuesday.  I do not even know that 
foobar needs xyzzy, so unless I watch the install closely, Fred may have 
xyzzy 2.4 installed. 

On machine Barney, I install foobar on Wednesday.  I do not know there 
was a new release of xyzzy overnight, but Barney now has xyzzy 2.5 
installed.

Six months from now, my user says "YOUR program is broken - it doesn't 
do the same thing on Fred and Barney".

I figure out that it is the version of xyzzy, then decide that the 
correct answers come when I use 2.4.  It was automatically installed, so 
I don't have a copy of it in my archive of source code.  I try to 
download it, but I can only find 2.5, 2.6, and 2.7 online.

What do I do?

Compare with:

On machine Fred, I install foobar on Tuesday, but I use --no-automatic.  
It says "You must have xyzzy > 2.3".

I download xyzzy 2.4 to my collection of source code, install it on 
Fred, then install foobar.  Everything works.

On Wednesday, I install, on Barney, xyzzy 2.4 from my collection of 
source code and my own package foobar.

Six months from now, my user sees that my program does the same thing on 
Fred and Barney.

>
>> I keep careful track of what is installed on all my machines.  If the 
>> tool automatically installs any version other than the one I 
>> specified, then the tool is working _against_ me.  I don't need that.
>
> No it is working like the application writer specified it.

I agree, except for the part where you said "No". :)

I think the correct description is  "Yes!  It is working like the 
application writer specified it, but it is making proper configuration 
control difficult."

>> Ideally, there would be a flag that says "if you can't find 
>> something, give me an error -- do not attempt to download/install 
>> anything".  But it would be helpful if it can tell me "Package xyzzy 
>> is missing, but you can get it from here:..."
>
> This I agree, it should have a way to ignore some requests or even all 
> requests of the application that is launched, maybe even have a 
> configuration file somewhere (or a registry key, or a plist file 
> depending on the os) that override the default, which I think should 
> be give the running application the version that it specifies 
> (standard packaging version rules apply, if it asks for package >=1.0 
> then any version newer than 1.0 is sufficient)

Good point -- we need two options here:

1. do not download/install anything, just raise an error

2. use the version module XXX that I have, even though the package says 
it is not suitable


>
> But this is just a proposition that I think will never be able to work 
> with python without security or only signed and pre approved packages 
> on pypi.

Is it really different from what setuptools already does?

Do we know how CPAN handles security?

Mark S.



More information about the Distutils-SIG mailing list