On May 31, 2007, at 2:47 PM, Dieter Maurer wrote:

Jim Fulton wrote at 2007-5-31 14:15 -0400:
I fear my colleagues responsible to maintain the productive versions
would not be happy:

  They want the system to be as stable as possible.

  If they need to introduce a new component, they usually
  prefer to just add this one component. Only if this forces
  other updates, they reluctantly will make them.

The motivation for this behaviour: even if a newer version
is supposed to be backward compatible, it often has slightly different
behaviour which may trigger bugs in the other parts of a complex

I agree, but this control should occur at at a different place.  I
suggest that when deploying or releasing an application or system,
you want to fix all of the versions so that a released or deployed
configuration is repeatable and so that changes are introduced in a
controlled way.  This can be done in a number of ways.  You can have
an application meta-package that specifies all of the versions, or,
if you are using buildout, you can use buildout's facilities for
fixing versions.

For individual reusable "library packages", you want to make the
dependencies as non-restrictive as possible so as to maximize
flexibility and reusability.

I agree but not to specify a minimal version and instead to assume
that always the latest release version must be used does not
maximize but reduce reusablitity.

Look at the following szenario:

  In a given system module "A" is installed in version "M.m".

  For some reason, another module "B" in the system cannot work with
  "A" in any version "M.m'" with "m' > m".

I think a ' is missing above. I assume you mean that B requires "A <=M.m".

I know that this violates your assumption that any newer minor release
  is compatible with any older one (in the same major release).
  Unfortunately, such things happen....

Sure. For example, then A doesn't follow the rules and people will have to use an inconvenient specification for it. This will often be the case for non-Zope packages. For example, if Python was a distribution, it would, sadly, have this property.

  Now assume we want to install module "C" which needs "A" in version

Given the backward-compatibility policy of A, C's author has made an error.

If "M.*" implicitly means: the newest minor release in the "M" series,
then "C" cannot be installed in the hypothetical system.

It means that any version of A in the M series should work. It doesn't mean that the latest is required. If the requirements of the "system" listed B before listing C, then a version of A compatible with B would get used and that would also work with C.

If, on the other hand, if C is listed before B, then, using the current setuptools algorithm, the latest version of A will be used and will be incompatible with B. (Eventually, we'll switch to a better algorithm.)

If, on the other hand, the dependency is expressed by "A >=M.m, <= M.9999",
then "C" can be installed.

Assuming that this is C's dependency, it doesn't make any difference. If C is named before B, you'll still get a version conflict.

If your suppositions are only a form of introduction for the "M.*" syntax
(or "M*", if you prefer) but does not affect the semantics of "M.*",
i.e. if "M.*" means 'needs the module in *any* "M" version',
then I have no objections.

That's exactly what I meant. In fact, I meant exactly what I said, which was that:

"project_name V.*" would be equivalent to "project_name >=V, <V. 99999"


Even for me "M.*" is nicer than "M.99999".

More importantly, IMO, "A M.*" is nicer than "A >=M, <M.99999".

I also think that:

  "A M" is nicer than "A M.*".


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to