On Mar 16, 2009, at 9:19 AM, Martin Aspeli wrote:
> Hi Gary,
>> zc.relationship 2.0 trunk is now essentially a wrapping of
>> code for backwards compatibility.
> I see. But 2.0dev on pypi isn't?
> What's the story behind zc.relation and the evolution of
Briefly, I wanted a package that only included the bit I used, the
index (in zc.relation, the catalog). I abstracted it, made sure that
zc.relation had 100% test coverage, and changed the names and the API
in a backwards incompatible way. I also added a bunch of new
features, like a transitive index for hierarchies.
See http://pypi.python.org/pypi/zc.relation#changes for details.
zc.relationship trunk then depended on zc.relation, and existed to
provide backwards compatibility while not forcing me to maintain two
versions of the same codebase. The upgrade path that the zc.relation
PyPI doc describes from a zc.relationship index to a zc.relation index
has been used in production, IIRC, but it requires zc.relationship
I would be quite happy to release zc.relationship trunk as 2.0, if it
helped you: it was used in production. If the ZODB 3.8-only issue is
not a show-stopper then that's a good approach, and hopefully pretty
easy for everyone.
>> You guys are the main clients for zc.relationship at this point, I
> Possibly, yes. ;-)
>> As I see it, your relatively reasonable options are these:
>> - MOST WORK: Move the plone.relation code to depend on zc.relation.
>> There is an upgrade path for the old indexes. You would need to copy
>> over the old zc.relationship relationship containers to the Plone
>> package. IIRC, Alec's tests of those bits were good, and you could
>> just keep the bits from zc.relationship you needed. ZODB module path
>> issues in legacy databases would be among the more annoying bits of
>> this approach, though we all know the usual solutions there.
> I think we'd need Alec to find the time to do this if it's to happen,
> but it does sound like the better option.
Perfect world, sure.
>> - LESS WORK: See how zc.relationship trunk works for you. If it
>> the code happy, I can release it or help you to do so. It's
>> been sitting around long enough. Then at least you are sitting
>> (indirectly) on top of zc.relation, the package that (for instance)
>> Martijn F.'s Grok work exercises. This would be my preferred
>> compromise between effort and migration. The problem here is that it
>> probably does depend on ZODB 3.8, and I'd rather not make the
>> zc.relation code support the older spellings, so that's probably out
>> for you unless you want to make a concrete counter-proposal in this
> Well, having a version that only works with ZODB 3.8 isn't *terrible*,
> it's just annoying. If and when Plone actually ships with five.intid
> plone.relations, it'll be on ZODB 3.8 anyway. It's just a bit more
> for people wanting to use it.
Gotcha. Your choice. FWIW, this was the path I intended/hoped you
guys would follow when I did the work to make zc.relationship sit on
top of zc.relation.
>> - LEAST WORK: Figure out what's wrong with zc.relationship 1.1. What
>> you described sounds trivial to fix, and I don't have any ethical
>> issues over only supporting the most recent release of the 1.x line,
>> so I don't want to think about the earlier releases. I suspect this
>> is what you want. We can make a 1.1.1 release and you can move on.
> Hopefully. Do we know that zc.relationship 1.1 works with both ZODB
That would be a significant point of its existence, so I certainly
hope so. I'm 80%+ confident that it does, and would regard not
supporting 3.7 as a bug that I'd be willing to fix.
> What's the difference between 1.1.1 and 2.0dev on pypi?
I intended that 1.1.1 would simply make the absolutely minimal changes
necessary for you to be able to use the 1.1 branch. It would not have
any of the 2.x changes at all.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -