On Tue, May 19, 2009 at 9:29 PM, A. Cavallo <a.cava...@cavallinux.eu> wrote: >> > It is solved in other languages.. for example perl.. and delphi >> I don't know much about perl, and even less about delphi, but I am >> pretty sure it does not solve the problem of overwriting files from a >> package with an installation outside the control of the package >> manager. > > On a sytem a possible solution would be: > > /usr/lib/python2.5/site-package/foobar <- The os managed one > /usr/lib/python2.5/site-package/foobar-2.0 <- The alternatives > /usr/lib/python2.5/site-package/foobar-2.1 > > and using something (in the python interpreter) > > import foobar (imports the foobar) > import foobar requires >= 2.1 (imports foobar 2.1 or above)
This does not solve the discussed problem. If you revwrite foobar-2.0 with foobar-2.0 installed from sources, you don't know whether you will break the system. You will most likely do so, because of difference filesystem conventions, for example. And what will happen when you will do apt-get remove foobar-2.0 (on a .deb system) ? Most likely, as the set of files installed from sources are not exactly the same as the set of files installed by dpkg, the uninstall will be broken. Specially in the case of configuration files, or daemon, this may be quite serious. >> >> There is no simple solution to the following situation: >> - install setuptools from ubuntu -> files get into /usr >> (/usr/lib/python2.5/site-packages, etc...) > > setuptools is the problem;) It tries to do too many things imho. The discussion has nothing to do with setuptools, or even python for that matter. The problem is that overwriting files managed by the software management system without its consent is bound to be broken, on any system (including windows). That's why you should avoid installing from sources into the locations managed by the OS, be it /usr for unix, or C:\Windows on windows, etc... David -- http://mail.python.org/mailman/listinfo/python-list
