Tarek Ziadé wrote: > On Mon, Aug 23, 2010 at 1:24 PM, M.-A. Lemburg <m...@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.
Please see my example: It is well possible that you have two sets of packages installed which are mutually exclusive, but don't interfere which each other when used by different applications. If an installer were to bar you from installing packages from set 1 if you already have packages from set 2 installed, you wouldn't be able to use those two applications at the same time, even though they don't use a mixed combination of packages from set 1 and 2 (which would conflict). Whether there is a conflict depends on the applications using the packages. The packages themselves are not in conflict. Think of having both Zope and Django installed: one could regard this as conflict, since both provide web server functionality, but in reality they can both coexist in site-packages without any problem. All the other cases (packages using the same module/package name or version dependency conflicts) can easily be figured out by the installer without such an extra "conflicts" field. Could you perhaps point me to a list of things you had in mind with the "conflicts" field ? Perhaps I'm just missing the main idea behind this field. I do see a problem with such a general purpose "conflicts" field, regardless of what the use case is. If the installer prevents packages from being installed by means of defining such a "conflicts" field, this can be used to externally make package sets incompatible, e.g. a package of framework 1 could effectively prevent the installation of a competing framework 2, even though they both can live happily side-by-side on sys.path. And there's nothing the authors of framework 2 could do about this. In the same line of thought, I believe it would be better to change the "obsoletes" field to "obsoleted-by", i.e. the direction changes and gives the author of the obsoleted package full control over what he thinks is a better version of his package, rather than have some other author make that choice for him. That way you avoid the social implications of one package trying to compete against another by means of the "obsoletes" field. In summary: As PyPI grows and we are seeing the first conflicts between package authors trying to push their particular idea of implementing a certain task, we should take such social implications of standards into account and, if possible, design the standards in a way that doesn't encourage such behavior. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 24 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
