[Zope-dev] zc.relationship - can't pickle module objects

[Gary Poster]

On Mar 16, 2009, at 9:19 AM, Martin Aspeli wrote:

> Hi Gary,
>
>> zc.relationship 2.0 trunk is now essentially a wrapping of  
>> zc.relation
>> code for backwards compatibility.
>
> I see. But 2.0dev on pypi isn't?
>
> What's the story behind zc.relation and the evolution of  
> zc.relationship?

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  
trunk.

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
>> suspect.
>
> 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  
>> makes
>> the code happy, I can release it or help you to do so.  It's  
>> certainly
>> 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
>> regard.
>
> 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  
> and
> plone.relations, it'll be on ZODB 3.8 anyway. It's just a bit more  
> work
> 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
> versions?

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.

Gary