[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