>> get_transaction() is more troublesome than _just_ that, alas: there
>> are about 160 instances of it across the stitched-in lib/python/zope,
>> and Products/Five, code. This causes lots of new deprecation warnings
>> when running the tests. These are easy to repair with 1-2 hours easy
>> editing work, but again Zope trunk doesn't own the lib/python/zope
>> code (where almost all of these appear).
> Right, lib/python/zope is actually Zope X3.0.0, and we didn't expect
> we'd need to *update* Zope X3.0 in order for it to work with Zope 2.8.
I know. That's why I pushed and pushed to get the branch merged
"early" -- I knew _something_ would go wrong, I just didn't know what
Jim and I knew about the ZODB-3.4-in-Zope-2.8 plans for quite a while,
but I doubt that even Brian was aware of them. There's no way you
could have known -- not your fault.
> The new ZODB version is having some repercussions there. Zope X3.0 was
> released against an older version of ZODB. I'm really at a loss at what
> to do there. I can spend time trying to shut up Zope X3 I guess, if that
> is the only option... What is the recipe of changing get_transaction(),
> is this documented somewhere?
It is, but it would go faster if I did it. I rewrote all uses of
get_transaction() in the Zope and Zope3 trunks on Monday, so I'm in
practice. For the most part they amount to no more than what Jim
said, but there are trickier cases than commit().
Suggestion: I make a new copy of
stitch that into Zope trunk (change the lib/python svn:externals to
point to the new copy), do all the get_transaction() edits there, and
repair the IDataManager glitch there too. This could easily be done
before lunch today (my time <wink>).
If people are agreeable, help me pick a name for the new copy; I have
no idea what the "pr1" is supposed to mean in the current name, but
would like to stick to whatever naming convention is in use there.
> I don't think Five has much in the way of fundamental get_transaction(); ...
That's right -- it's almost all under lib/python/zope/.
> Perhaps we should make a X3.0.1. This is fairly long overdue
> Alternatively, we could make a branch for use in 2.8. I don't
> think this would really be a problem.
Above, I'm volunteering to do the latter. Somehow I get the
impression that sticking an unplanned X3.0.1 release on the critical
path for Zope 2.8 wouldn't go over well here <wink>.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -