Nabble - Grok

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-10T08:59:11Z

Roger Erens, on 2009-11-10:

>
> On Tue, Nov 10, 2009 at 12:32, Maurits van Rees wrote:
>> Roger Erens, on 2009-11-10:
>>> I don't understand; can you elaborate? I mean, someone who can edit
>>> buildout.cfg is also able to edit setup.py. Or isn't that the issue?
>>
>> If the setup.py is in your own package, say a package you wrote for a
>> client: sure.
>>
>> But here the point is that for example the setup.py in the official
>> grok egg should *not* pin exact versions (and for the record: it does
>> not currently). If we had for example said in the setup.py
>> "install_requires=['setuptools==0.6c9']" then someone who wanted to
>> use setuptools 0.6c11 would be *forced* to edit the setup.py of their
>> local copy of the grok egg and that is not good.
>>
>> Is that clearer?
>
> Yes, thanks. I had never given the setup.pys in eggs any
> thought. But this is just about the point w.r.t. the exact versions
> vs. the minimum versions in setup.py; how about the point
> w.r.t. empty vs. non-empty setup.py?

If you have a dependency you should specify it, otherwise your package
will not work. You cannot depend on users of your package to read the
pypi page of your package and add any dependencies themselved manually
to their buildout.cfg.

I encountered that in an own package recently.
Products.eXtremeManagement (project management tool in Plone) depended
on xm.tracker in its setup.py. xm.tracker needed egenix-mx-base (for
the mx.DateTime module) but did not specify this in its dependencies.
The reason was that egenix-mx-base was not on pypi at the time so the
dependency could not be resolved by buildout anyway. This was
described in the readme and on pypi, but someone did not read that and
the missing dependency caused errors on his plone site.

There is some middle ground of course. For example at Zest Sofware if
we build a package for a client and it needs a third party product we
usually do not specify this in the setup.py but only in the
buildout.cfg. The package is not going to be reused anyway. This way
the information is in one place.

And if you are in Plone land and you have a package that needs Plone
and works on Plone 3.0 and higher, you cannot specify 'Plone>=3.0' as
Plone is only eggified since 3.2. So if you put this in your setup.py
you make it hard for people on Plone 3.0 and 3.1 to use your package.
(Some fake-eggs might help but I have not tried.)

--
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-10T07:50:49Z

On Tue, Nov 10, 2009 at 12:32, Maurits van Rees <m.van.rees@...> wrote:

> Roger Erens, on 2009-11-10:
>> On Fri, Nov 6, 2009 at 19:17, Maurits van Rees
>><m.van.rees@...> wrote:
>>> Sebastien Douche, on 2009-11-06:
>>>> On Fri, Nov 6, 2009 at 16:30, Maurits van Rees
>>>><m.van.rees@...> wrote:
>>>>> Minimum versions in setup.py is fine, exact versions not.
>>>>
>>>> It could be great to use buildout to pin minimum versions and let
>>>> setup.py empty.
>>>
>>> -1. That would just mean you allow a user to pick a version that you
>>> know is not going to work.
>>
>> I don't understand; can you elaborate? I mean, someone who can edit
>> buildout.cfg is also able to edit setup.py. Or isn't that the issue?
>
> If the setup.py is in your own package, say a package you wrote for a
> client: sure.
>
> But here the point is that for example the setup.py in the official
> grok egg should *not* pin exact versions (and for the record: it does
> not currently). If we had for example said in the setup.py
> "install_requires=['setuptools==0.6c9']" then someone who wanted to
> use setuptools 0.6c11 would be *forced* to edit the setup.py of their
> local copy of the grok egg and that is not good.
>
> Is that clearer?

Yes, thanks. I had never given the setup.pys in eggs any thought. But this is just about the point w.r.t. the exact versions vs. the minimum versions in setup.py; how about the point w.r.t. empty vs. non-empty setup.py?

Cheers,

Roger

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

signature.asc (279 bytes) Download Attachment

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-10T07:50:43Z

On Tue, Nov 10, 2009 at 12:32, Maurits van Rees <m.van.rees@...> wrote:

signature.asc (279 bytes) Download Attachment

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-10T03:32:55Z

Roger Erens, on 2009-11-10:

> On Fri, Nov 6, 2009 at 19:17, Maurits van Rees
><m.van.rees@...> wrote:
>> Sebastien Douche, on 2009-11-06:
>>> On Fri, Nov 6, 2009 at 16:30, Maurits van Rees
>>><m.van.rees@...> wrote:
>>>> Minimum versions in setup.py is fine, exact versions not.
>>>
>>> It could be great to use buildout to pin minimum versions and let
>>> setup.py empty.
>>
>> -1. That would just mean you allow a user to pick a version that you
>> know is not going to work.
>
> I don't understand; can you elaborate? I mean, someone who can edit
> buildout.cfg is also able to edit setup.py. Or isn't that the issue?

If the setup.py is in your own package, say a package you wrote for a
client: sure.

But here the point is that for example the setup.py in the official
grok egg should *not* pin exact versions (and for the record: it does
not currently). If we had for example said in the setup.py
"install_requires=['setuptools==0.6c9']" then someone who wanted to
use setuptools 0.6c11 would be *forced* to edit the setup.py of their
local copy of the grok egg and that is not good.

Is that clearer?

Cheers,

--
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-09T16:05:30Z

On Fri, Nov 6, 2009 at 19:17, Maurits van Rees
<m.van.rees@...> wrote:

> Sebastien Douche, on 2009-11-06:
>> On Fri, Nov 6, 2009 at 16:30, Maurits van Rees
>><m.van.rees@...> wrote:
>>>> We adopted a strict "pin everything" policy that includes any
>>>> packages, even the build infrastructure. This works pretty well for
>>>> us.
>>>
>>> +1
>>>
>>> Minimum versions in setup.py is fine, exact versions not.
>>
>> It could be great to use buildout to pin minimum versions and let
>> setup.py empty.
>
> -1. That would just mean you allow a user to pick a version that you
> know is not going to work.

I don't understand; can you elaborate? I mean, someone who can edit
buildout.cfg is also able to edit setup.py. Or isn't that the issue?

Roger
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Proposal: Base Grok on ZTK 1.0

2009-11-09T12:56:37Z

I did try to apply the changes on the current trunk (in a branch I killed)
It works flawlessly, with exactly the same fixes.
Though , this very same branch didn't work very good with grok 1.0 as it was.

2009/11/9 Jan-Wijbrand Kolman <janwijbrand@...>:

> Michael Haubenwallner wrote:
>> *Update*: Souheil Chelfouh (trollfot) and me joined in IRC this evening
>> and implemented the whole thing. All tests pass, it extends ZPT 1.0dev
>> and works with Python2.6.
>>
>> There is a working branch now at
>> http://svn.zope.org/grok/branches/d2m-ztk-support/
>>
>> Please give it a try with your recent Grok1.0 application and let us
>> know how it works out for you.
>
>
> __very__ cool.
>
> I'll play with it tomorrow with our application to see what happens.
>
> One problem that needs attention before we think of moving to a 1.1 release:
>
> AFAIK the trunk of grokcore.view contains other changes too besides the
> fixes that were needed for the ZTK-1.0 support. We need to review those
> changes OR release a ZTK-1.0 compatible version of grokcore.view based
> on most recent released version.
>
> Anyway, can't wait to play with it. Great!
>
> regards,
> jw
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> https://mail.zope.org/mailman/listinfo/grok-dev
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Proposal: Base Grok on ZTK 1.0

2009-11-09T12:56:10Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan-Wijbrand Kolman wrote:
> AFAIK the trunk of grokcore.view contains other changes too besides the
> fixes that were needed for the ZTK-1.0 support. We need to review those
> changes OR release a ZTK-1.0 compatible version of grokcore.view based
> on most recent released version.
>

We based it in grokcore.view 1.12.2
Using the trunk was a too big first step.

Regards
Michael

- --
http://blog.d2m.at
http://planetzope.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr4geoACgkQl0uAvQJUKVZTVgCeKZt0Hh87Mc5RQfHVQXlr6YIx
1WMAoKcljGVTJBeNrFPpLk6xqhfZ4fjY
=7tUu
-----END PGP SIGNATURE-----

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Proposal: Base Grok on ZTK 1.0

2009-11-09T12:51:32Z

Michael Haubenwallner wrote:
> *Update*: Souheil Chelfouh (trollfot) and me joined in IRC this evening
> and implemented the whole thing. All tests pass, it extends ZPT 1.0dev
> and works with Python2.6.
>
> There is a working branch now at
> http://svn.zope.org/grok/branches/d2m-ztk-support/
>
> Please give it a try with your recent Grok1.0 application and let us
> know how it works out for you.

__very__ cool.

I'll play with it tomorrow with our application to see what happens.

One problem that needs attention before we think of moving to a 1.1 release:

AFAIK the trunk of grokcore.view contains other changes too besides the
fixes that were needed for the ZTK-1.0 support. We need to review those
changes OR release a ZTK-1.0 compatible version of grokcore.view based
on most recent released version.

Anyway, can't wait to play with it. Great!

regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Proposal: Base Grok on ZTK 1.0

2009-11-09T12:40:13Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Haubenwallner wrote:

> Update the versions.cfg to conform to the ZTK 1.0 spec.
>
>
> launchpad blueprint is at
> https://blueprints.launchpad.net/grok/+spec/ztk-support
>
> Proposal and current change report is at
> http://wiki.zope.org/grok/ZTKSupport
>
> Changes are minimal (grokcore.view, grokdocs and a few tests).
> More testing with existing applications is needed.
> Supports Python2.6
>

*Update*: Souheil Chelfouh (trollfot) and me joined in IRC this evening
and implemented the whole thing. All tests pass, it extends ZPT 1.0dev
and works with Python2.6.

There is a working branch now at
http://svn.zope.org/grok/branches/d2m-ztk-support/

Please give it a try with your recent Grok1.0 application and let us
know how it works out for you.

Regards
Michael

- --
http://blog.d2m.at
http://planetzope.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr4fi0ACgkQl0uAvQJUKVbbcACgr1OAk/mzvURmvUTZzciYEfAk
bG4Anjh5gXCJWk9CpSugNP6LwDXR5UWP
=TZkP
-----END PGP SIGNATURE-----

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Proposal: Base Grok on ZTK 1.0

2009-11-09T00:38:58Z

Hi Michael,

this is awesome, thanks for your effort...

Christian

> Oh man, i'm so +1000 on this one
> I'd work on that if people don't mind
> I badly need newer versions of most packages.
>
> 2009/11/9 Michael Haubenwallner<michael@...>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Update the versions.cfg to conform to the ZTK 1.0 spec.
>>
>>
>> launchpad blueprint is at
>> https://blueprints.launchpad.net/grok/+spec/ztk-support
>>
>> Proposal and current change report is at
>> http://wiki.zope.org/grok/ZTKSupport
>>
>> Changes are minimal (grokcore.view, grokdocs and a few tests).
>> More testing with existing applications is needed.
>> Supports Python2.6
>>
>> Please comment.
>>
>> Regards
>> Michael
>>
>> - --
>> http://blog.d2m.at
>> http://planetzope.org
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAkr3zLgACgkQl0uAvQJUKVawvwCeLcvIuAc3eEYMmlxSqnZ7Or0n
>> togAmwaQhRVcUMkdfnJemwCRBHqzoqtS
>> =Dq5s
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> Grok-dev mailing list
>> Grok-dev@...
>> https://mail.zope.org/mailman/listinfo/grok-dev
>>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Proposal: Base Grok on ZTK 1.0

2009-11-09T00:06:16Z

Oh man, i'm so +1000 on this one
I'd work on that if people don't mind
I badly need newer versions of most packages.

2009/11/9 Michael Haubenwallner <michael@...>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Update the versions.cfg to conform to the ZTK 1.0 spec.
>
>
> launchpad blueprint is at
> https://blueprints.launchpad.net/grok/+spec/ztk-support
>
> Proposal and current change report is at
> http://wiki.zope.org/grok/ZTKSupport
>
> Changes are minimal (grokcore.view, grokdocs and a few tests).
> More testing with existing applications is needed.
> Supports Python2.6
>
> Please comment.
>
> Regards
> Michael
>
> - --
> http://blog.d2m.at
> http://planetzope.org
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkr3zLgACgkQl0uAvQJUKVawvwCeLcvIuAc3eEYMmlxSqnZ7Or0n
> togAmwaQhRVcUMkdfnJemwCRBHqzoqtS
> =Dq5s
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> https://mail.zope.org/mailman/listinfo/grok-dev
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Proposal: Base Grok on ZTK 1.0

2009-11-09T00:03:04Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Update the versions.cfg to conform to the ZTK 1.0 spec.

launchpad blueprint is at
https://blueprints.launchpad.net/grok/+spec/ztk-support

Proposal and current change report is at
http://wiki.zope.org/grok/ZTKSupport

Changes are minimal (grokcore.view, grokdocs and a few tests).
More testing with existing applications is needed.
Supports Python2.6

Please comment.

Regards
Michael

- --
http://blog.d2m.at
http://planetzope.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr3zLgACgkQl0uAvQJUKVawvwCeLcvIuAc3eEYMmlxSqnZ7Or0n
togAmwaQhRVcUMkdfnJemwCRBHqzoqtS
=Dq5s
-----END PGP SIGNATURE-----

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: zope.location version for blob copy

2009-11-08T12:51:09Z

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@...>:

> 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@...>:
>> 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
>>
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: zope.location version for blob copy

2009-11-08T12:24:44Z

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@...>:

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

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

zope.location version for blob copy

2009-11-08T11:26:29Z

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
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Grok should run on python 2.6

2009-11-06T23:46:29Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin Teague wrote:
> It'd be nice to be able to do these migrations piecemeal, first do the
> work to bump a Grok app to Python 2.6, then do the work to migrate the
> app to ZTK 1.0. Well, obviously through the magic of Buildout it's
> already easy to do this, but doing a Grok release which just bumps the
> packages just enough to get to 2.6 would be good.

As i found out the ZTK 1.0 is a KGS. I changed Grok to include the ZTK
1.0 versions (this is changing 82 out of 113 package releases).

Buildout succeeded immediately. I had to change a single package
(grokcore.view) and 5 tests to make all tests run. The grokwiki sample
app starts and works. Python2.6 is supported too.

I am very surprised this worked at all and that easy.

I now need to test the setup against real applications written for Grok
1.0. Please let me know if there are any so far.

I proposed to make Grok 1.1 implement the changes
https://blueprints.launchpad.net/grok/+spec/ztk-support

Regards
Michael

- --
http://blog.d2m.at
http://planetzope.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr1JdUACgkQl0uAvQJUKVa6UQCfekV4fJVVO/wEEsCxUVmfo/NP
AAIAoKbbFV16oiZhufK7M4DvmkBkr0bZ
=089K
-----END PGP SIGNATURE-----

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-06T10:17:24Z

Sebastien Douche, on 2009-11-06:

> On Fri, Nov 6, 2009 at 16:30, Maurits van Rees
><m.van.rees@...> wrote:
>>> We adopted a strict "pin everything" policy that includes any
>>> packages, even the build infrastructure. This works pretty well for
>>> us.
>>
>> +1
>>
>> Minimum versions in setup.py is fine, exact versions not.
>
> It could be great to use buildout to pin minimum versions and let
> setup.py empty.

-1. That would just mean you allow a user to pick a version that you
know is not going to work.

--
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-06T10:04:22Z

On Fri, Nov 6, 2009 at 16:30, Maurits van Rees
<m.van.rees@...> wrote:
>> We adopted a strict "pin everything" policy that includes any
>> packages, even the build infrastructure. This works pretty well for
>> us.
>
> +1
>
> Minimum versions in setup.py is fine, exact versions not.

It could be great to use buildout to pin minimum versions and let
setup.py empty.

--
Sebastien Douche <sdouche@...>
Twitter: http://bit.ly/afkrK (agile, python, open source)
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-06T07:30:33Z

Hanno Schlichting, on 2009-11-06:

> On Fri, Nov 6, 2009 at 11:45 AM, Jan-Wijbrand Kolman
><janwijbrand@...> wrote:
>> I'm ambivalent about this topic: pinning the versions of zc.buildout and
>> setuptools and related packages in the version list of a project.
>
> I think the correct solution to this problem is to release a new
> bugfix release of Grok (grokproject?), which has an updated setuptools
> version in it ;-)
>
> At least in the Plone-world we depend quite heavily on buildout and
> have had several times where changes in buildout broke recipes or
> where newer versions of recipes only work with newer versions of Plone
> itself.
>
> We adopted a strict "pin everything" policy that includes any
> packages, even the build infrastructure. This works pretty well for
> us.

+1

Minimum versions in setup.py is fine, exact versions not.

Pinning exact versions in a buildout config file still allows anyone
to override them when problems like these occur, so that is still fine.

--
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-06T05:08:28Z

On Fri, Nov 6, 2009 at 11:45 AM, Jan-Wijbrand Kolman
<janwijbrand@...> wrote:
> I'm ambivalent about this topic: pinning the versions of zc.buildout and
> setuptools and related packages in the version list of a project.

I think the correct solution to this problem is to release a new
bugfix release of Grok (grokproject?), which has an updated setuptools
version in it ;-)

At least in the Plone-world we depend quite heavily on buildout and
have had several times where changes in buildout broke recipes or
where newer versions of recipes only work with newer versions of Plone
itself.

We adopted a strict "pin everything" policy that includes any
packages, even the build infrastructure. This works pretty well for
us.

Just my 2cent :)
Hanno
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grokproject pins setuptools, zc.buildout et.al.

2009-11-06T03:10:33Z

On 2009-11-06, Jan-Wijbrand Kolman <janwijbrand@...> wrote:
>
> So there's my "ambivalence": should we really pin versions of
> buildout-related infrastructure and even setuptools in projects or not?

I don't think it is needed to pin them here. They don't influence the
run-time behaviour and don't conflict with something else. (Well, setuptools
could have influence with entry points).

Minimal versions are handy. Require at least setuptools 0.6c11 to prevent
subversion 1.6 related errors. (Technical note: distribute has no problem
with such a setuptools minimal dependency: it will just say "yep, that's me"
in the places that matter).

Reinout

--
Reinout van Rees - reinout@... - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

grokproject pins setuptools, zc.buildout et.al.

2009-11-06T02:45:33Z

Hi,

I'm ambivalent about this topic: pinning the versions of zc.buildout and
setuptools and related packages in the version list of a project.

But this is the situation:

A project built with grokproject will have a versions.cfg file that is a
copy of the latests grok "kgs" file found online and in addition will
have list the following packages:

Paste = 1.7.2
PasteDeploy = 1.3.2
PasteScript = 1.7.3
setuptools = 0.6c9
collective.recipe.template = 1.4.0
z3c.evalexception = 2.0
z3c.recipe.dev = 0.5.3
z3c.recipe.i18n = 0.5.3
z3c.recipe.mkdir = 0.3.1
zc.buildout = 1.1.1
zc.lockfile = 1.0.0
zc.recipe.egg = 1.1.0
zc.recipe.filestorage = 1.0.1

Now we have the situation that there's a newer setuptools package
released, that I have installed in my virtualenv (as it fixes for one an
ugly bug related to subversion 1.6 and up). Having installed
setuptools0.6c11 in my virtualenv conflicts during buildout with the
version listed in my newly created project. Ugh.

So there's my "ambivalence": should we really pin versions of
buildout-related infrastructure and even setuptools in projects or not?
If it were not pinned, I would not have had a problem, where the
intention of pinning these packages was to prevent any problems from
happening in the first place.

Opinions?

regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

five.grok manual

2009-11-05T01:07:49Z

Hi folks,

I've just finished a relatively detailed manual on using five.grok in
Plone. It is aimed largely at people using the Dexterity type system,
since Dexterity also provides other grokkers and encourages people to
use the Grok approach, but it is not Dexterity-specific.

It also serves as a Zope Component Architecture primer, using Grok for
all the examples.

I would think about 80% of this would apply to "plain Grok" as well,
with minor modifications (like not importing from five.grok in the
examples).

Note that I've chosen not to describe certain things that five.grok
supports, because I don't feel they fit into the Plone model or have
some other issues that make me uncomfortable recommending them. I have
attempted to list those on the last page of the manual.

You can find the manual here:

http://plone.org/products/dexterity/documentation/manual/five.grok

Consider this an open invitation to borrow any and all part of this (an
attribution would be nice) for grok.zope.org if you want to use it to
build the same kind of thing for "plain Grok". In particular, I think
the "ZCA intro" would be useful; at least I couldn't find a good ZCA
primer that wouldn't confuse people with a Grok mindset, wanting to use
Grok syntax.

Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Grok should run on python 2.6

2009-11-04T23:21:22Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin Teague wrote:

> mmm, adding Python 2.6 support would be nice.
>
> Here are the versions that I'm using to override the Grok 1.0 versions
> to get Python 2.6 compatibility:
>
> mechanize = 0.1.9
> zope.app.appsetup = 3.8.0
> zope.app.component = 3.5.0
> zope.app.container = 3.6.1
> zope.app.testing = 3.5.6
> zope.testbrowser = 3.5.1
> zope.session = 3.8.1
>
> But AFAIK the Zope Toolkit is also Python 2.6 compatible, so when
> that's ready (I haven't been following the status of the ZTK to
> closely yet) migrating Grok to ZTK will also provide 2.6
> compatibility.
>
> It'd be nice to be able to do these migrations piecemeal, first do the
> work to bump a Grok app to Python 2.6, then do the work to migrate the
> app to ZTK 1.0. Well, obviously through the magic of Buildout it's
> already easy to do this, but doing a Grok release which just bumps the
> packages just enough to get to 2.6 would be good.

Kevin, thank you for your information. I just needed to add the next
possible release of zope.app.form to your versions listing - there is no
more zope.app.component.back35 in zope.app.component3.5.0.
Here is my config to run with Python 2.6

[buildout]
extends = buildout.cfg

[versions]
mechanize = 0.1.9
zope.app.appsetup = 3.8.0
zope.app.component = 3.5.0
zope.app.container = 3.6.1
zope.app.form = 3.6.3
zope.app.testing = 3.5.6
zope.testbrowser = 3.5.1
zope.session = 3.8.1

This makes at least a Grok trunk checkout build, test and run under
Python 2.6.

Btw, i changed etc/site.zcml.in too, as the grok.View permission is not
existing anymore.

I wonder how these changes will work with existing projects though.

It would be nice to get some hints on how to migrate the trunk to ZTK 1.0

Regards
Michael

- --
http://blog.d2m.at
http://planetzope.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkryfPIACgkQl0uAvQJUKVaeuQCbBjlKD4J66D/1Uf/Fdy6wUQQp
2DQAoIihH0IxfWjj7zZy+tFI3Ml3ZH7e
=25Ij
-----END PGP SIGNATURE-----

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Grok should run on python 2.6

2009-11-04T17:24:52Z

mmm, adding Python 2.6 support would be nice.

Here are the versions that I'm using to override the Grok 1.0 versions
to get Python 2.6 compatibility:

mechanize = 0.1.9
zope.app.appsetup = 3.8.0
zope.app.component = 3.5.0
zope.app.container = 3.6.1
zope.app.testing = 3.5.6
zope.testbrowser = 3.5.1
zope.session = 3.8.1

But AFAIK the Zope Toolkit is also Python 2.6 compatible, so when
that's ready (I haven't been following the status of the ZTK to
closely yet) migrating Grok to ZTK will also provide 2.6
compatibility.

It'd be nice to be able to do these migrations piecemeal, first do the
work to bump a Grok app to Python 2.6, then do the work to migrate the
app to ZTK 1.0. Well, obviously through the magic of Buildout it's
already easy to do this, but doing a Grok release which just bumps the
packages just enough to get to 2.6 would be good.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Grok should run on python 2.6

2009-11-03T23:31:33Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Who is able to sketch the effort to make Grok available on Python 2.6 -
i remember it took me half a day to patch the eggs to run on Python 2.6
a year ago ( http://blog.d2m.at/2008/10/03/from-the-labs/ ).

Lets do it now and make it a Grok 1.1 release.

Regards
Michael

- --
http://blog.d2m.at
http://planetzope.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrxLdUACgkQl0uAvQJUKVaXeQCeMppM9+s1WWEm1miq9QzOlb+E
ay0AoKItxMek+zgh4fzXGhcI8RmYmee7
=Qiyw
-----END PGP SIGNATURE-----

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grok.url() requiring a request object a bit inconvenient

2009-11-03T08:40:56Z

Jan-Wijbrand Kolman wrote:
> There're a couple of packages out there that do get to the "global"
> request. We should look that these packages for inspiration when
> implementing grok.global_request(). On the top of my head there is:
>
> * hurry.resource (or is it hurry.zope.resource)

The latter (hurry.zoperesource), as hurry.resource doesn't know anything
about Zope.

> * zope.globalrequest

I think the simplest thing would be to simply make Grok depend on
zope.globalrequest and import the method to get the global request into
the grok namespace.

I'm +1 on that approach.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: url() method on JSON component

2009-11-03T08:36:13Z

Hey,

Jan-Wijbrand Kolman wrote:

> Proposal:
>
> Not only the url() method is useful for JSON (and maybe even the REST)
> components, but so are the application_url() method and the response
> property.

I think certainly we need them for the REST components too. It's very
common one wants to generate a URL when writing a RESTful protocol.

> The url() method and the response property is defined in
> grokcore.view.View. We could split out these into a seperate baseclass.
> grokcore.view.View will then inherit from this baseclass.
>
> In grok we will define a mixin class derived from this baseclass that
> adds the application_url() method. The JSON and REST components can then
> inherit from this mixin class.

Sounds reasonable. We practically have that mixin class already in the
form of components.View in grok. The only differences are that it's a
mixin and doesn't have the flash() method.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Is HTML the only editor for tutorials?

2009-11-03T01:45:50Z

Yes, I was adding a new tutorial. Now I notice that I have to deselect
editing with visual editor. The link required me to scroll the window
so I didn't find it yesterday.

Mvh Sebastian

2 nov 2009 kl. 23.06 skrev Steve Schmechel:

> Is the problem with a new tutorial?
> I can still pick the Text Format - "reStructured Text" in the
> dropdown list when editing an existing tutorial.
>
> (It still always defaults to "Plain Text", so you have to pick it
> each time. I tend to use the "Edit with external application"
> option, for convenience and the fact I don't have to make that
> selection with each edit.)
>
> I am not sure what else to suggest. I haven't come across this
> problem.
>
> Steve
>
> --- On Mon, 11/2/09, Sebastian Ware <sebastian@...> wrote:
>
>> From: Sebastian Ware <sebastian@...>
>> Subject: [Grok-dev] Is HTML the only editor for tutorials?
>> To: "Grok list" <grok-dev@...>
>> Date: Monday, November 2, 2009, 1:42 PM
>> I can't change editor to ReST, but I
>> have some text that is allready
>> formatted that way. Do tutorials only have HTML-editors
>> these days?
>>
>> Mvh Sebastian
>>
>>
>> _______________________________________________
>> Grok-dev mailing list
>> Grok-dev@...
>> https://mail.zope.org/mailman/listinfo/grok-dev
>>
>
>
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grok.url() requiring a request object a bit inconvenient

2009-11-03T01:40:37Z

2 nov 2009 kl. 21.43 skrev Jan-Wijbrand Kolman:

> Sebastian Ware wrote:
>> And this is an inconvenience because I have to figure out how to get
>> the request object, and then repeat that code whenever I use
>> gork.url()...
>
> Not with my previous proposal formalizing the "hack" of retrieving the
> request with something like grok.global_request(). This would not
> require a change in grok.url() and at the same time retrieving the
> request will not force you to repeat code.
>

You are right, that would be great solution for me!

Mvh Sebastian

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: Is HTML the only editor for tutorials?

2009-11-02T14:06:39Z

Is the problem with a new tutorial?
I can still pick the Text Format - "reStructured Text" in the dropdown list when editing an existing tutorial.

(It still always defaults to "Plain Text", so you have to pick it each time. I tend to use the "Edit with external application" option, for convenience and the fact I don't have to make that selection with each edit.)

I am not sure what else to suggest. I haven't come across this problem.

Steve

--- On Mon, 11/2/09, Sebastian Ware <sebastian@...> wrote:

> From: Sebastian Ware <sebastian@...>
> Subject: [Grok-dev] Is HTML the only editor for tutorials?
> To: "Grok list" <grok-dev@...>
> Date: Monday, November 2, 2009, 1:42 PM
> I can't change editor to ReST, but I
> have some text that is allready
> formatted that way. Do tutorials only have HTML-editors
> these days?
>
> Mvh Sebastian
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> https://mail.zope.org/mailman/listinfo/grok-dev
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: easy_install without https access

2009-11-02T12:58:02Z

Jan-Wijbrand Kolman schrieb:
> Uwe Hoffmann wrote:

>> grokproject) fails when accessing https://launchpad.net .
> Just curious: what packages that grok requires (directly or indirectly)
> are actually downloaded from launchpad?
>

# easy_install grokproject
Searching for grokproject
Reading http://pypi.python.org/simple/grokproject/
Reading https://launchpad.net/grok

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: easy_install without https access

2009-11-02T12:44:30Z

Uwe Hoffmann wrote:
> Hi,
>
> not sure if this is the correct ML (it's not a development question).
>
> I'm sitting behind a proxy and the easy_install process (starting with
> grokproject) fails when accessing https://launchpad.net .
> My question: Is it possible to use a https-free installation or is
> https always required (e.g. another entry pypi package).

Just curious: what packages that grok requires (directly or indirectly)
are actually downloaded from launchpad?

regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: grok.url() requiring a request object a bit inconvenient

2009-11-02T12:43:20Z

Sebastian Ware wrote:
> And this is an inconvenience because I have to figure out how to get
> the request object, and then repeat that code whenever I use
> gork.url()...

Not with my previous proposal formalizing the "hack" of retrieving the
request with something like grok.global_request(). This would not
require a change in grok.url() and at the same time retrieving the
request will not force you to repeat code.

regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

Re: post 1.0 Grok development wishlist

2009-11-02T12:38:00Z

Hi Sylvain,

Sylvain Viollon wrote:

> On Mon, 26 Oct 2009 09:59:59 +0100
> Sylvain Viollon <sylvain@...> wrote:
>
> Hello,
>
> Anybody have any idea about I proposed here ?
>
> Anybody is interested about the topic ?
>
>> So if there is people interested to brainstorm, I am all open.
>>
>> If JW and Jan Jaap are interested maybe we can setup some kind of
>> local sprint a Friday afternoon at Infrae to talk about it (since we
>> are in the same city).

I think your ideas are interesting and yes indeed, we're very close
togteher and so we can easily "mini sprint" on these topics! I'd very
much like that idea! Let's do that!

regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev