-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 P.J. Eby wrote: > At 02:47 PM 8/26/2010 +0200, Alexis Métaireau wrote: >> Right, the installation *will not* cause problems, but they will >> apear after that. If so, we have two choices: >> - First is to tell nothing to the user about that, and I think >> that's a good option, as it could result in a end user bad >> experience (if that's not handled at the installation level, what >> will handle this?) >> - Second is to prompt the user about what he want to do: Do we have >> to install the release/distribution, even if it can cause problems >> while running them? Are you sure you want to install both, even if >> it could lead to such issues ?, etc. > > Informing the user about the conflict isn't a bad idea... but then > again, it sounds like something that would normally be covered in a > project's README. > > Notice here the difference between the Python environment and a Linux > distribution: the distribution is not merely *installing* software, > it is also *deploying* it in some sense -- such software is > preconfigured as well as installed, and integrated with the system as a whole. > > However, that same software as released by its author is not so > integrated and preconfigured, and thus, these conflict issues cannot > necessarily even be *known* in advance by the author. > > IMO, then, the very ideas of Obsoletes and Conflicts are broken in > the software *distribution* context, vs. the software "integration" > or "deployment" context. System packagers can make these kind of > evaluations in the context of their supported integration. > > However, with the exception of informing people about an obsoleted > package of theirs, these are not judgments that can be made so > unequivocally by the individual author of a piece of software, as > they have no overview of the integrated whole (as a system > integrator/distributor does). > > > >>> In other words, none of the above is actually a use-case for having >>> a "Conflicts" field. >> I have pain to imagine use cases where conflicts could raise at the >> *installation* level too, but the question seems to be: "do we need >> something to describe installation-related conflicts, or run-related >> conflicts ? In debian apt system, conflicts are described for >> "on-run" issues, IIRC. > > ...and they're described relative to a specific runtime environment, > which won't really be the case for the individual Python package author. > > >>> Here's the thing: so far I'm the ONLY person in the discussion who >>> has even offered an example of when Obsoletes would be used... and >>> for the two examples I gave, I would totally be willing to make a >>> new release for them to include that field, if there was some >>> benefit (e.g. user notification) to having the field. >> And that's the use case described in the PEP. So, now, we have to >> choose if it's acceptable to make a new release for updating this >> field, or not. > > I was just pointing out that so far, 100% of the people who have > given use cases for Obsoletes are fine with having to issue a new > release to make it Obsoleted-By. ;-) > > (However, PyPI already allows metadata field editing of an > already-released package, so as long as the new field were added to > the existing editable fields, that'd be fine too.) > > > >>> (Note that forked packages using the same API only conflict because >>> of *installing conflicting files* -- so if you're thinking of a >>> fork as your example here, it is leading you to confuse the ideas >>> of Obsoletes and Conflicts.) >> I was not thinking about a fork, but about a new rename. That said, >> I must admit that the difference between the two fields is sometimes >> hard to see. > > At this point, the only reasonable use of either is to inform the > user about something, and in the case of Obsoletes, it's not > necessarily even the user who's doing the installing! If somebody > installs Foo that depends on RuleDispatch, they are not necessarily > in a position to port Foo to using PEAK-Rules. So, only in the case > where you are declaring a direct dependency from your package to the > obsoleted package, or where you are directly installing the obsoleted > package, do you even need to know anything about it. > > In the case of conflicts, conflicts presuppose a specific runtime > environment if the conflict is runtime environment related, and > again, at best all that can be done is to inform the user. > > If the conflict is runtime-process related (e.g. two libraries > registering the same Python hook), then only a project that declares > dependencies to both is affected, and only that project's authors > need to be informed. > > Given these conditions, it isn't clear that any of these three cases > (obsoletes, environment conflict, in-process conflict) constitute > something that an installation tool should be informing an end-user > about, vs. the developer or integrator who's declaring the > dependencies in the first place. > > For example, it might make sense for developer-side tools like > setuptools and buildout to check that one's declared dependencies > don't have conflicts before pushing out an sdist or bdist or doing an > install, and to warn for any obsoleted dependencies. In contrast, an > end-user tool like pip or easy_install would have little reason to > check any of this, as their user isn't really affected by anything > but environment-level conflicts that are unlikely to arise as an > immediate result of installing the software. > > > >> +1. This series of mails point out that we definitely need to talk a >> bit more about the usability of the fields. >> Maybe are we missing something here, and maybe arent we talking >> about the same type of conflicts. In any case, we need to clarify >> all this *before* doing the implementation stuff. > > I think that the main thing being missed is that these fields are > being copied from a completely different kind of use case: the > concept of a "package" as a bundle of preconfigured software that is > also pre-integrated with a uniform operating environment. In that > context, it is the curators of that overall environment who are in a > position to make judgments regarding what is a "conflict", or what > packages will "obsolete" each other in the context of that environment. > > Lacking such an overall curator organization in the PyPI environment > (and not desiring one, anyway, since PyPI is inherently a software > distribution *catalog* rather than a platform of its own), these > fields make very little sense. They are perhaps most useful as a > centralized way to pass along notifications to developers (or to > curator/integrators of system packages), but have little or no impact > on the software installation process itself. > > I also suspect that if you ask those curator/integrators of system > packages, that they will say that the information in these fields > would be of little value to them in any case, as it's unlikely that > the author will *know* about the kinds of conflicts they'd be > concerned about in their packaging process. But it would certainly > be worth asking them. > > More to the point though... I wonder whose idea it was to have these > fields in the first place? Neither PEP 314 nor PEP 345 don't really > say, "Oh, such and such people asked for these fields for thus-and-so > use cases", and in the absence of such requestors and use cases, it > would probably be best just to drop them entirely. (Unless of course > Fred offers a description of what his actual use case for Conflicts > is/was, and it doesn't fall into one of the categories previously discussed.)
FWIW, I helped add those fields to PEP 345, in the context of making the switch from "module / package"-centric values to distribution-centric ones. The requirements came out of a sprint at PyCon 2009, with input from both the Debian / Ubuntu Python packager (Matthias Klose) and one of the Fedora packagers (Toshio Kuratomi). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkx4KTQACgkQ+gerLs4ltQ7AFwCgycG3CP9sDjKMfOljCS69c72r ayAAn1rr/aeWVrhQdUjMbuWyAi7efgez =SfA+ -----END PGP SIGNATURE----- _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
