About the Conflict field. it seems true there is two kind of conflicts:
we can install both Django and Zope at the same time, for example, and I
would not consider them as conflicting, even if they could start a
server on the same port.
But, there is some cases, where the conflict field is useful. For
instance, when two releases propose the same python modules to import,
or when they rely on the same configuration files for instance. While
the first case seems to be covered by the "Provides" field, the second
one does not seems to be covered at all.
There is also the example Fred quoted about interfaces, here is the quote:
A new package which provides an interface that was once provided
elsewhere should generally be declared in conflict with older versions
of the package where the interface was originally provided (though not
in conflict with newer versions that pull the interface from the new
package).
This pattern has occurred frequently as the Zope community has worked
to reduce the dependencies on the zope.app packages, and there's been
no way to declare the conflicts.
What I understand here, is that some interface was firstly provided in a
release, but then provided by another one. So both can provide it, and
we need a way to mark them as conflicting. Here, that's not obsoleting,
as just part of the functionalities are provided in the new release.
After a bit of thinking, I think I agree with PJE when saying that we
need to put on some examples of how the fields are to be used, in the
clients.
About what have been stated on the "conflict" and "obsolete" fields. I
agree that it would be nice if the way of the relation have been
changed, but Merwok pointed out that will force the maintainer of the
old release to create a new release just for that. That's true, and
maybe can we avoid creating a new release just for that. If the METADATA
file is available to download by clients from PyPI, we can regenerate it
without regenerating a new release for that. Maybe can we find a way to
point this release as obsoleted by another one.
"Conflict" and "Obsoletes" seems to be needed, here, as they cover
different use cases. Now, we have to deal with what the installer
*should* or *shouldnt* do, but it seems to be another point...
...that's still need to be answered.
If the "Ham" release have been obsoleted by "Egg", and if "Spam" relies
on "Ham", and "Ham" is installed, that's fine, and the installation can
go on.
Now, if we try to install "Towel", that relies on "Egg", and we have
already "Ham" installed, we should just state there is a conflict here.
By that, I mean that the releases should not be replaced by another
ones, even if the new ones obsoletes the old one.
the "conflict" field covers another type of conflict, also needed: it
would just be used in the way: "both A and B releases can't be
*installed* on the same time, whatever could be the cause". I'm agreeing
with you while you're saying that *installation* dependencies are
different from *run* dependencies, I've understood the "conflict" field
as an "installation" dependency, and think too that is needed to be
clear about this in the PEP.
Thanks all for your responses to this thread, that's a joy to see so
much enthousiasm and debate about this !
Cheers,
Alexis
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
