On Fri, Mar 21, 2008 at 06:30:33PM -0400, Phillip J. Eby wrote: > At 10:17 PM 3/21/2008 +0000, Floris Bruynooghe wrote: >> On Fri, Mar 21, 2008 at 03:02:25PM -0400, Phillip J. Eby wrote: >> > At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote: >> > > Joachim> I think, the uninstall should _not_ 'rm -rf' but only >> 'rm' the >> > > Joachim> files (and 'rmdir' directories, but not recursively) that it >> > > Joachim> created, and that have not been modified in the >> meantime (after >> > > Joachim> the installation). >> > > >> > >That's not sufficient. Suppose file C (e.g. /usr/local/etc/mime.types) is >> > >in both packages A and B. >> > > >> > > Install A - this will create C >> > > Install B - this might overwrite C, saving a copy, or it might retain >> > > A's copy. >> > > Uninstall B - this has to know that C is used by A and not touch it >> > >> > Correct. However, in practice, B should not touch C, unless the file >> > is shared between them. >> > >> > This is a key issue for support of namespace packages, at least if we >> > want to avoid using .pth files. (Which is what setuptools-built >> > system packages do for namespace packages currently.) >> > >> > Of course, one possible solution is for both A and B to depend on a >> > "virtual package" that contains C, such that both A and B can install >> > it if it's not there, and list it in their dependencies. But this is >> > one of the handful of open issues that needs to be resolved with Real >> > Life Package Management people, such as Debian, Fedora, etc. [...] >> I'm not familiar with namespace packages as I've never used one, but I >> assume it is just an empty directory with one (empty?) __init__.py >> file in it? > > It's not empty; it has to contain a namespace declaration. There's > another approach that can work around the absence of the __init__.py, by > using .pth files, but it's messy, and I'd like to get rid of it if > possible.
So __init__.py contains some data, but it's static regardless of which sub-packages are installed? So far so good as that doesn't influence things on package-management level. I knew about the .pth hack but as you say it's messy and I'm glad you prefer to get rid of it too :-). >> The only way I can see Debian handling that is by having >> a Debian package providing exactly that __init__.py and all other >> Debian packages needing that namespace package will depend on it. >> >> However, this is shouldn't worry anyone other then Debian I think. > > Alas, it'll probably affect most package managers. > > >> If >> a distribution needs to depend on somthing it will depend on whoever >> provides the module *inside* the namespace package, not on the >> namespace itself. So the fact that no distribution provides the >> namespace.__init__.py file shouldn't have to worry other users of the >> python installdb. > > Well, somebody still has to create the __init__.py, and own it for > purposes of uninstallation. Ok, true. The virtual distribution thing (or an other solution) might be needed for this. But what I was trying to say was that other package managers should keep their hands off Debian's /usr/lib IMHO. >> Since easy_install and others shouldn't be messing with debian >> packages in /usr/lib (they should be using /usr/local/lib or >> ~/.local [1]) this won't be a problem. > > If the new PEP (262 redux) contains anything about actual directory > locations on any system of any platform (other than as examples), I'll > consider it a failure. Thinking about specific locations while talking > about the new PEP should be considered a segmentation fault. :) I think I agree that the PEP should not detail locations (and relative paths inside the installdb is a good point), but I do think it's part of this discussion so that the installdb can cope with the different directory situations. You can't expect the system and a user to be able to write to the same installdb. A problem along this line: The system (e.g. Debian) has a namespace package installed and a few of it's sub-packages (/usr/lib). The local admin wants a new sub-pacakge of this namespace which should go into e.g. /usr/local/lib (and is not available in the system). You now have: $system/namespace/__init__.py $system/namespace/sub1/__init__.py $local/namespace/__init__.py $local/namespace/sub2/__init__.py But this doesn't work in Python! The only solution I can think of is that the local admin has to install the entire namespace package again and make sure it ends up before the system one on sys.path. This is slightly ugly I think. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
