[Catalog-sig] PEP 345 Update

[P.J. Eby]

At 02:55 PM 8/23/2010 -0700, Tarek Ziadé wrote:
>On Mon, Aug 23, 2010 at 1:24 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>..
> >
> >> In case of "obsoletes", it _should_ also be possible to install both
> >> of them simultaneously. Maybe some other other distribution depends
> >> on the original one, and can't work with the new one.
> >
> > Agreed.
> >
> > The same is true for conflicting packages: even if packages A and D
> > conflict, one application may use the package combination A,B,C
> > while another may be using D,E,F - both without any conflicts.
>
>But we are in the same scope.
>
>This can be applied for Conflicts because they are supposed to be 
>incompatible.
>
>It's exactly the same incompatibility than having Foo depending on Bar > 1.0
>and Baz depending on Bar < 0.9. Since you can't have two versions of 
>Bar running
>in the same Python packages.
>
>So while Obsoletes allows you to have two times the same package. Conflicts
>indicates that its strictly impossible.

Note that "Conflicts" doesn't necessarily mean you can't install the 
conflicting package, just that it can't be active on sys.path at the 
same time as the conflicting project.  (easy_install -m, for example, 
would have no reason to care about conflicts unless a single 
project's global dependency tree includes both of the conflicting packages.)

So, technically, all an installer has to do is avoid placing 
conflicting packages on the same runtime sys.path, in order to comply 
with Conflicts.

Hm.  Come to think of it, if all Conflicts is saying is, "I have 
modules of the same names as...", then couldn't any installer worth 
its salt figure this out for itself?  (Even PEP 376 already has a way 
to detect conflicting files before installing.)

OTOH, if what it's saying is something like, "you can't import 
asyncore's mainloop and Twisted's mainloop at the same time and 
live", then what value does it have for the install tool, vs. merely 
informing the user?