On Jan 29, 2009, at 8:29 PM, Mark Sienkiewicz wrote:
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.
This is just one of the example of why packages should not use ">=" in
vain :)
But yep, it gets complex but I think there is ways around this,
specially if this behavior became accepted.
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."
Who does configuration control? Not end users right? So I think this
autoinstall method should be used the same way that webstart is used,
for end users only. It will not take the place of buildout or manual
installation. This is a feature to make python programs easier to run
for the end user. So we can distribute python packages without having
to use py2exe or anything like that.
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?
No it is not. the difference is that you have to today easy_install an
application for it to download its dependencies, it is like saying "I
believe in this package dev team and so I believe they are not bring
harmfull modules to my system". But well... as python doesn't have a
sandbox everytime you run an application you are trusting the
developer... so if this system build a virtual env for each app it
runs all will be ok (as a package that the program brings will not
affect the system configuration).
--
Leonardo Santagada
santagada at gmail.com
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
