[Grok-dev] zope.location version for blob copy

[Souheil CHELFOUH]

I don't know if it interest anyone but me, but...
Here is a solution without modifying the code :

in your buildout:
[versions]
zope.copy = 3.5.0
zope.location = 3.7.0
zope.copypasteremove = 3.5.2

In your code :

import grok
from zope.interface import alsoProvides
from zope.location.interfaces import ILocation, IRoot
from zope.location.traversing import LocationPhysicallyLocatable
from zope.traversing.interfaces import IPhysicallyLocatable
from zope.app.folder.interfaces import IRootFolder

class FixingLocationInfo(grok.Adapter, LocationPhysicallyLocatable):
    grok.context(ILocation)
    grok.provides(IPhysicallyLocatable)


@grok.subscribe(IRootFolder, grok.IObjectCreatedEvent)
def fix_root_implements(root, event):
    alsoProvides(root, IRoot)


all tests pass and it works with the ICopyHook
This is what I needed. I feel dirty doing that, but...


2009/11/8 Souheil CHELFOUH <trollfot at gmail.com>:
> I did some investigations
> The problems comes from 2 things :
>
> we can not use zope.app.catalog 3.8.0, since it uses zope.intids and
> not zope.app.intids. Therefore :
>
> 1. we need to use zope.app.catalog 3.5.1
> 2. zope.app.catalog 3.5.1 uses
> zope.traversing.interfaces.IPhysicallyLocatable while it should now
> use zope.location.interfaces.ILocationInfo
> 3. While using zope.location.interfaces.ILocationInfo, we run into a
> problem since zope.app.folder 3.4.0 rootFolder does not provide
> zope.location.interfaces.IRoot
> 4. We can not use zope.app.folder 3.5.1 since it uses a too recent
> version of zope.component that breaks Grok's imports
>
> Once this is fixed, it runs perfectly. All tests pass.
> I wonder what could be done about this.
> zope.location 3.7.0 works correctly with zope.app.catalog 3.5.1 and
> zope.app.folder 3.4.0.
> We could publish a 3.5.2 version of zope.app.catalog using
> zope.location 3.7.0 and a zope.app.folder 3.4.1
> I don't think that people will be happy about this.
>
> Other solution is to change Grok to use the last zope.catalog and
> zope.component.
>
> I need a solution for myself, even if I end up monkeypatching. I'd
> rather use the energy to do something constructive.
>
> - Souheil
>
> 2009/11/8 Souheil CHELFOUH <trollfot at gmail.com>:
>> Hello Grokkers !
>>
>> I'm currently working on the Dolmen clipboard functionalities.
>> For a clean handling of the blob copies, i need to use zope.copy.
>> I to use, also, a zope.copy.interfaces.ICopyHook, which is only
>> trigged in zope.location 3.7.0
>> zope.location 3.7.0 works very nicely with an already created
>> application but disturbs the creation of a new one:
>>
>> [...]
>>
>>  File "/home/trollfot/.buildout/eggs/zope.app.catalog-3.5.1-py2.5.egg/zope/app/catalog/catalog.py",
>> line 162, in indexAdded
>>    index.__parent__.updateIndex(index)
>>  File "/home/trollfot/.buildout/eggs/zope.app.catalog-3.5.1-py2.5.egg/zope/app/catalog/catalog.py",
>> line 104, in updateIndex
>>    for uid, obj in self._visitSublocations() :
>>  File "/home/trollfot/.buildout/eggs/zope.app.catalog-3.5.1-py2.5.egg/zope/app/catalog/catalog.py",
>> line 99, in _visitSublocations
>>    uidutil = component.getUtility(IIntIds)
>>  File "/home/trollfot/.buildout/eggs/zope.component-3.4.0-py2.5.egg/zope/component/_api.py",
>> line 207, in getUtility
>>    raise ComponentLookupError(interface, name)
>> ComponentLookupError: (<InterfaceClass zope.app.intid.interfaces.IIntIds>, '')
>>
>>
>> I have been struggling with that for a long time now and I don't want
>> to stay stuck there.
>> Copying is an important features for all kind of applications and this
>> needs to be sorted.
>>
>> It seems that the problems appear at the creation of the indexes.
>> Can anyone help me with that ? It would be nice to fix that behavior
>> in the next grok release and that would allow us to use a more recent
>> version of zope.location (and other packages that depend on it)
>>
>> - Souheil
>>
>