Re: [Zope-dev] Supporting interworking with repository branches on github
On Wed, 23 Nov 2011 09:50:49 -0500, Tres Seaver tsea...@palladion.com wrote: Second, it is already feasible to work with modern VCSes against the existing SVN repository: I've been doing it with bzr for literally years now; I know of lots of documentation on using git against SVN as well. Of course, Github is more than a VCS, but its main advantage over other solutions lies in being able to accept casual contributions from non-core developers, which is hardly in scope for the early phases of the Zope4 effort. github enables a peer review process: while everybody who signed the plone committer agreement could just commit to the plone repo, we do pull-requests and somebody else with commit rights checks the request and merges. It's not about git locally - I'm doing that for years, too - it's about git server side. florian -- Florian Friesdorf f...@chaoflow.net GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpSyonnQW6KB.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] security.public/private/protected decorators
Hi Matthew, Alan,
as discussed during ploneconf2011 I wrote the decorators:
security.public
security.private
security.protected
as successors to their declareX pendants.
All new code is fully covered (except a raise).
@all: please review AccessControl r123394 - r123399
security.protected('permission') returns a decorator and it should be
ensured that all those decorators are actually called, i.e. that the @
isn't missing.
flo
--
Florian Friesdorf f...@chaoflow.net
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpL1PCNZa8O3.pgp
Description: PGP signature
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] security.public/private/protected decorators
Sorry, forgot to Cc a couple of people involved in discussion and
solution included in this mail.
On Wed, 16 Nov 2011 19:33:56 -0800, Florian Friesdorf f...@chaoflow.net wrote:
Hi Matthew, Alan,
as discussed during ploneconf2011 I wrote the decorators:
security.public
security.private
security.protected
as successors to their declareX pendants.
All new code is fully covered (except a raise).
@all: please review AccessControl r123394 - r123399
security.protected('permission') returns a decorator and it should be
ensured that all those decorators are actually called, i.e. that the @
isn't missing.
flo
--
Florian Friesdorf f...@chaoflow.net
GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpdXIYoRPGZW.pgp
Description: PGP signature
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Neoplanta Sprint coming up, Novi Sad, 21st - 29th November 2010
Hi, the Neoplanta sprint in Novi Sad (Serbia) is coming up in less than two weeks. So far we are 11 developers and are able to host 15-20. If you are interested, have a look at the coactivate page: http://www.coactivate.org/projects/neoplanta-sprint/project-home and feel free to ask, e.g. about topics! If we can assist you in booking a hostel/hotel or arranging transfer from the airport (Belgrade) to Novi Sad, please let me know - we have native speakers to ease the process. hope to see you in Novi Sad! florian -- Florian Friesdorf f...@chaoflow.net GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgplYHu6X5ahy.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML is dead, long live DTML ;-)
On Sun, Sep 05, 2010 at 11:13:05AM +0800, Tim Hoffman wrote: Hi Florian I use a model based generation approach (from enterprise architect) however even archgenxml has templates for large amounts of boiler plate under the hood. Have you actually looked at the src of archgenxml, if you did you will notices it uses dtml for templating the code output ;-) Once did, but wasn't aware of any dtml, come to think of it, there is some reason to it ;) -- Florian Friesdorf f...@chaoflow.net GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp9485K58h0p.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML is dead, long live DTML ;-)
On Sun, Sep 05, 2010 at 08:49:39AM +0800, Tim Hoffman wrote: Please note that DTML is a dead (and horrid) technology. Martin But zpt is horrible for doing non html/xml based things ;-), What do you think is good alternative in the zope eco system now for templating other types of things (sql, python ...) ? I would use a templating system for things that are easy to template (html/xml) and where more complex logic can be offloaded to a real programming language like python (as zpt does). Using a templating system for a programming language is I think a different programming paradigm than zope's component architecture and contrary to code reusage. With code generators like ArchGenXML or agx you are able to create models for your software on a more abstract level than based on templating, so I would not use templating but model-based code generation instead. florian -- Florian Friesdorf f...@chaoflow.net GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpD9QHMx5IZs.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] env var support for zc.buildout
Hi Jim, hi Christian,
any further thoughts on this?
best regards
florian
On Fri, Apr 09, 2010 at 05:23:36PM +0200, Florian Friesdorf wrote:
On Fri, Apr 09, 2010 at 10:16:51AM -0400, Jim Fulton wrote:
We currently use it for 5 very similar sites that share one repository
but use 5 checkouts of it:
base.cfg
[buildout]
parts = instance
develop = ...
eggs = ...
zcml = ...
[instance]
...
site-1.cfg
[buildout]
eggs +=
zcml +=
testenv.cfg
[buildout]
extends =
base.cfg
${env:site}.cfg
stuff for testenv
deploy.cfg
[buildout]
extends =
base.cfg
${env:site}.cfg
stuff for deploy
% site=site-1 ./bin/buildout -c deploy.cfg
Your extends usage seems a bit convoluted. Why not just have:
- deploy.cfg extend base.cfg
- site1-1.cfg etc extend deploy.cfg
Then you'd just:
% ./bin/buildout -c site-1.cfg
That would mean:
- 1 base.cfg
- 1 deploy.cfg
- 1 testenv.cfg
- 5 site-specific extending deploy.cfg
- 5 site-specific extending testenv.cfg
total: 13 files
Site-specific information reside in two cfgs, which is error-prone.
In contrast to our current setup, with env var support, without
the need to duplicate information.
- 1 base.cfg
- 1 deploy.cfg
- 1 testenv.cfg
- 5 site specific cfgs
total: 8 files
Site-specific information could be factored out, as in the setup with
env var support:
testenv-site-1.cfg:
[buildout]
extends =
testenv.cfg
site-1.cfg
Information would not be duplicated but the amount of files increases to
18.
Further we use a dev environment tailored for local individual
development in contrast to the testenv which is meant for the customer
to be kept up-to-date about the development, without e.g. PDBDebugMode.
With that dev environment the numbers are 18 (with site-specific info
in three places) or 23 vs. 9 files.
This idea can be taken further to mass hosting in dedicated instances
but based on one buildout, or branches of one buildout that share the
majority of stuff.
Other use cases coming to my mind:
- ip address for zope to listen on: instead of hard-coded 8080 or
127.0.0.1:8080, you can have ${env:MYPROJECT_LISTEN} and people being
involved in several projects can choose in order to have several
buildouts running in parallel
- location of the Data.fs: I like to have the Data.fs outside of the
buildout dir for development, which enables the use of 'git clean
-xdf', i.e. wiping everything which is not tracked.
I like the idea of the need to configure the name of the environment
section:
[buildout]
environment=env
extends = ${env:...}
At the time the extends are processed, the whole buildout section is
already read into the options dict, so configuration of the name of the
environment section is easily possible and can be used to trigger the
substitution code:
if extends:
envsecname = options.get('environment')
if envsecname:
# do variable substitution like in my patch
# if no environment is specified nothing changes
# continue normally
I would not pop() the options, so the name of the environment section
can be queried by other parts of buildout. Likewise, extends could not
be pop()'ed - both then would need to go onto a list, which buildout
checks, in order not to complain about them being unused.
If I could get commit acces to svn.zope.org, I would further work on
this in a separate branch, more effective than via patches. Committer
agreement I can fax/email. I am not committing to branches that don't
belong to me, without prior consultation. So far I have commit access to
the plone repo, which might be meaningless or at least a minor sign of
credibility.
I hope I could clarify the usefulness of env var support.
florian
--
Florian Friesdorf f...@chaoflow.net
GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367
Jabber/XMPP: f...@chaoflow.net
OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
--
Florian Friesdorf f...@chaoflow.net
GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367
Jabber/XMPP: f...@chaoflow.net
OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] env var support for zc.buildout
On Mon, Apr 19, 2010 at 10:28:37AM -0400, Jim Fulton wrote:
On Mon, Apr 19, 2010 at 10:00 AM, Florian Friesdorf f...@chaoflow.net wrote:
Hi Jim, hi Christian,
any further thoughts on this?
Not at this time. This is on my to-do list to look at.
I think your use case would be better handled through
normal command-line option specification, as in:
buildout -c deploy.cfg buildout:extends+=site1.cfg
but that doesn't work. I think that should work and want
to look at why it doesn't.
That'd be nice and would be sufficient for my current use case. And the
discussion about environment variables we could continue on the base of
this being functional.
I took a look at it and so far came up with two docstrings (attached).
I think I could simplify _open and make extends work as expected, in
case you are comfortable with delegating that (see also 'desired
behaviour' in the docstring for _open (attached).
florian
--
Florian Friesdorf f...@chaoflow.net
GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367
Jabber/XMPP: f...@chaoflow.net
OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
From 186e8d9452c228ec68a229efde629b11d8add1db Mon Sep 17 00:00:00 2001
From: Florian Friesdorf f...@chaoflow.net
Date: Mon, 19 Apr 2010 19:14:04 +0200
Subject: [PATCH 1/2] docstring for _update_section
---
src/zc/buildout/buildout.py | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/src/zc/buildout/buildout.py b/src/zc/buildout/buildout.py
index 7d5ed47..c13fbfe 100644
--- a/src/zc/buildout/buildout.py
+++ b/src/zc/buildout/buildout.py
@@ -1373,6 +1373,27 @@ def _dists_sig(dists):
return result
def _update_section(s1, s2):
+update s1 by instructions from s2
+
+'+' and '-' operators are understood, without an operator, s2 overwrites
+s1.
+
+A section in a config file (somefile.cfg) as base for s2:
+[somesection]
+key1 = value1
+key2 += value2
+key3 -= value3
+
+Will arrive in the dictionary s2, like:
+{
+'key1': ('value1', 'somefile.cfg'),
+'key2 +': ('value2', 'somefile.cfg'),
+'key3 -': ('value3', 'somefile.cfg'),
+}
+
+The ' +'/' -' will be stripped of the key and the value in s1 altered
+accordingly.
+
s2 = s2.copy() # avoid mutating the second argument, which is unexpected
for k, v in s2.items():
v2, note2 = v
--
1.6.6.2
From aabd5ddda35bdcf557d49b7615ad1bd8ad2daf90 Mon Sep 17 00:00:00 2001
From: Florian Friesdorf f...@chaoflow.net
Date: Mon, 19 Apr 2010 19:27:12 +0200
Subject: [PATCH 2/2] docstring for _open incl. temporary comments from analysis
---
src/zc/buildout/buildout.py | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/src/zc/buildout/buildout.py b/src/zc/buildout/buildout.py
index c13fbfe..6222f37 100644
--- a/src/zc/buildout/buildout.py
+++ b/src/zc/buildout/buildout.py
@@ -1272,6 +1272,49 @@ def _open(base, filename, seen, dl_options, override):
Open a configuration file and return the result as a dictionary,
Recursively open other files based on buildout options found.
+
+
+Notes from analyzing the code here and in Buildout.__init__:
+
+override is use to update dl_options and passed on to recursive calls of
+_open
+
+dl_options is updated with values from override and passed on to recursive
+calls of _open.
+
+extends-cache defined in either dl_options or override is used as
+extends_cache
+
+_open is used in Buildout.__init__, where it always receives a copy of
+data['buildout'] as dl_options, i.e. the implicit feature of updating
+dl_options is not used.
+
+_open is used by itself recursively, where it always uses the very same
+dl_options. However, it also passes on override and updates dl_options each
+time with override.
+
+The only two keys that justifiy the dl_options and override parameters are
+extends-cache and extends, and currently they are only used for
+extends-cache.
+
+
+current behaviour:
+- extends-cache can be defined anywhere and is overruled in the expected
+ order: user_defaults, configuration file, command line
+- extends currently is only processed if defined in the configuration file
+ we are opening, not if it is passed via dl_options or override, i.e it is
+ not used if defined in user_defaults or on the command line.
+
+
+desired behaviour:
+- extends should be possible on the command line modifying a definition in
+ the configuration file
+- extends should be possible in user_defaults, resulting in user_defaults
+ being derived from processing its extends and then being discarded
+ (optional)
+- _open should not work on any arguments, but only return data it extracted
+ from the file it is supposed to open, following extends from
Re: [Zope-dev] env var support for zc.buildout
On Fri, Apr 09, 2010 at 10:16:51AM -0400, Jim Fulton wrote:
We currently use it for 5 very similar sites that share one repository
but use 5 checkouts of it:
base.cfg
[buildout]
parts = instance
develop = ...
eggs = ...
zcml = ...
[instance]
...
site-1.cfg
[buildout]
eggs +=
zcml +=
testenv.cfg
[buildout]
extends =
base.cfg
${env:site}.cfg
stuff for testenv
deploy.cfg
[buildout]
extends =
base.cfg
${env:site}.cfg
stuff for deploy
% site=site-1 ./bin/buildout -c deploy.cfg
Your extends usage seems a bit convoluted. Why not just have:
- deploy.cfg extend base.cfg
- site1-1.cfg etc extend deploy.cfg
Then you'd just:
% ./bin/buildout -c site-1.cfg
That would mean:
- 1 base.cfg
- 1 deploy.cfg
- 1 testenv.cfg
- 5 site-specific extending deploy.cfg
- 5 site-specific extending testenv.cfg
total: 13 files
Site-specific information reside in two cfgs, which is error-prone.
In contrast to our current setup, with env var support, without
the need to duplicate information.
- 1 base.cfg
- 1 deploy.cfg
- 1 testenv.cfg
- 5 site specific cfgs
total: 8 files
Site-specific information could be factored out, as in the setup with
env var support:
testenv-site-1.cfg:
[buildout]
extends =
testenv.cfg
site-1.cfg
Information would not be duplicated but the amount of files increases to
18.
Further we use a dev environment tailored for local individual
development in contrast to the testenv which is meant for the customer
to be kept up-to-date about the development, without e.g. PDBDebugMode.
With that dev environment the numbers are 18 (with site-specific info
in three places) or 23 vs. 9 files.
This idea can be taken further to mass hosting in dedicated instances
but based on one buildout, or branches of one buildout that share the
majority of stuff.
Other use cases coming to my mind:
- ip address for zope to listen on: instead of hard-coded 8080 or
127.0.0.1:8080, you can have ${env:MYPROJECT_LISTEN} and people being
involved in several projects can choose in order to have several
buildouts running in parallel
- location of the Data.fs: I like to have the Data.fs outside of the
buildout dir for development, which enables the use of 'git clean
-xdf', i.e. wiping everything which is not tracked.
I like the idea of the need to configure the name of the environment
section:
[buildout]
environment=env
extends = ${env:...}
At the time the extends are processed, the whole buildout section is
already read into the options dict, so configuration of the name of the
environment section is easily possible and can be used to trigger the
substitution code:
if extends:
envsecname = options.get('environment')
if envsecname:
# do variable substitution like in my patch
# if no environment is specified nothing changes
# continue normally
I would not pop() the options, so the name of the environment section
can be queried by other parts of buildout. Likewise, extends could not
be pop()'ed - both then would need to go onto a list, which buildout
checks, in order not to complain about them being unused.
If I could get commit acces to svn.zope.org, I would further work on
this in a separate branch, more effective than via patches. Committer
agreement I can fax/email. I am not committing to branches that don't
belong to me, without prior consultation. So far I have commit access to
the plone repo, which might be meaningless or at least a minor sign of
credibility.
I hope I could clarify the usefulness of env var support.
florian
--
Florian Friesdorf f...@chaoflow.net
GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367
Jabber/XMPP: f...@chaoflow.net
OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpi3ZxMihuvn.pgp
Description: PGP signature
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] env var support for zc.buildout
On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote: On 04/08/2010 04:27 AM, Florian Friesdorf wrote: environment variable support for zc.buildout, including extends! https://bugs.launchpad.net/zc.buildout/+bug/557769 works for me so far Uhm ... interesting. I never noticed our recipe not to work with extends. Can you give me an example? actually, i just assumed from looking at buildout.py - extends is processed before the whole Buildout ist up. As far as I understand your recipe is not even loaded when buildout would need that variable lookup. But, I saw you recipe after I implemented and never tried it... -- Florian Friesdorf f...@chaoflow.net GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp8gyGAw8Rvy.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] env var support for zc.buildout
On Thu, Apr 08, 2010 at 02:24:53PM +0200, Christian Theune wrote:
Hi,
On 04/08/2010 12:59 PM, Florian Friesdorf wrote:
On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote:
On 04/08/2010 04:27 AM, Florian Friesdorf wrote:
environment variable support for zc.buildout, including extends!
https://bugs.launchpad.net/zc.buildout/+bug/557769
works for me so far
Actually the env recipe was more of a hack to get going and then we
forgot to propose getting it into buildout.
OTOH handling it as a recipe allows for some other nice tricks, e.g.
overriding by extensions.
Maybe a specialised part-name, like versions would be helpful so that
buildout could pre-populate that part during initialisation and then
allow configurations to override individual values.
that would be nice indeed, but again would not work for extends
We currently use it for 5 very similar sites that share one repository
but use 5 checkouts of it:
base.cfg
[buildout]
parts = instance
develop = ...
eggs = ...
zcml = ...
[instance]
...
site-1.cfg
[buildout]
eggs +=
zcml +=
testenv.cfg
[buildout]
extends =
base.cfg
${env:site}.cfg
stuff for testenv
deploy.cfg
[buildout]
extends =
base.cfg
${env:site}.cfg
stuff for deploy
% site=site-1 ./bin/buildout -c deploy.cfg
On your specific patch: you sure about that direct regex match for the
expanding variables in the extends option?
I'd prefer using the logic from Options, but that relies on
self.buildout being an actual buildout already. I patched that up and
actually succeeded to use Options for extends, but had some failing
tests.
The direct regex is only used at _open-time on extends.
The only thing coming to my mind, why one would avoid a direct regex, is
performance and the performance penalty should be minimal like that.
However, I'm happy to be told different.
I wonder what Jim thinks about the topic.
me too
Uhm ... interesting. I never noticed our recipe not to work with
extends. Can you give me an example?
actually, i just assumed from looking at buildout.py - extends is
processed before the whole Buildout ist up. As far as I understand your
recipe is not even loaded when buildout would need that variable lookup.
But, I saw you recipe after I implemented and never tried it...
I just played with that scenario. Something that doesn't work with our
recipe:
a.cfg:
[buildout]
parts = x
[x]
recipe = zc.recipe.egg
eggs = zope.interface
foo = ${env:bar}
buildout.cfg:
[buildout]
extends = a.cfg
[env]
recipe = gocept.recipe.env
In the tests contained in the patches are even more sophisticated
scenarios :)
--
Florian Friesdorf f...@chaoflow.net
GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367
Jabber/XMPP: f...@chaoflow.net
OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpuqLKskApSf.pgp
Description: PGP signature
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] env var support for zc.buildout
On Thu, Apr 08, 2010 at 09:01:58AM -0400, Jim Fulton wrote: On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune c...@gocept.com wrote: I wonder what Jim thinks about the topic. I have mixed feelings. Accessing environment variables seems reasonable on some level, however: - I'd worry about the choice of the virtual section name. env or environment seems too likely to break existing buildouts. - I worry a bit about making buildout's programming language even more sophisticated. Florian, can you describe why you want to use environment variables in extends? The mail written during lunchtime made it out before I read this one... -- Florian Friesdorf f...@chaoflow.net GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpGXhmMsnbP6.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] env var support for zc.buildout
On Thu, Apr 08, 2010 at 04:45:30PM +0200, Adam GROSZER wrote: Maybe you should take a look at keas.build. Tho not repo based, but solves such almost identical sites cases. I will take a look into it, but for my use case it seems overkill and depends on svn, without support for git. -- Florian Friesdorf f...@chaoflow.net GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgphiyhJdcnhB.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] env var support for zc.buildout
environment variable support for zc.buildout, including extends! https://bugs.launchpad.net/zc.buildout/+bug/557769 works for me so far -- Florian Friesdorf f...@chaoflow.net GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgphCZk6xzeiG.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] paula code preview
Hi *, paula's code entered now the collective (https://svn.plone.org/svn/collective/paula/). Central component (currently) for testing is paula.suite, which uses paula.examples for testing. Paula is an authenticator plugin for PAU that uses content objects as authentication and property providers for principals. Interoperation with PAU ist working, the test is in paula.suite.README.txt paula.plonepas a layer for using paula.suite within PlonePAS will follow soon, as well as support for group content. Code reviews/comments are highly welcome. thx florian pgpQRekFYLG1Z.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] paula code preview
On Thu, Aug 14, 2008 at 07:24:16PM +0200, Florian Friesdorf wrote: Hi *, paula's code entered now the collective (https://svn.plone.org/svn/collective/paula/). Central component (currently) for testing is paula.suite, which uses paula.examples for testing. Paula is an authenticator plugin for PAU that uses content objects as authentication and property providers for principals. Interoperation with PAU ist working, the test is in paula.suite.README.txt paula.plonepas a layer for using paula.suite within PlonePAS will follow soon, as well as support for group content. Up-to-date state information is in https://svn.plone.org/svn/collective/paula/STATE.txt. I will keep that file updated... Code reviews/comments are highly welcome. thx florian pgpOlFC8etCkJ.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond
On Fri, Jul 18, 2008 at 05:00:50PM +0200, Hermann Himmelbauer wrote: Am Freitag, 18. Juli 2008 03:55 schrieb Florian Friesdorf: (..) In case you store your userdata in RDB, you do not need InternalPrincipal at all. I currently see to options: 1. custom AuthenticatorPlugin, AuthenticatedPrincipalFactory and FoundPrincipalFactory from principalfolder.py. Your AuthenticatorPlugin would need to return PrincipalInfo objects. Further, you write an event handler that listens for FoundPrincipalCreated and AuthenticatedPrincipalCreated, which puts all needed/wanted properties onto the Principal object, which was created by one of the factories. Those properties can be real python properties with get,set,del methods, which you can use to get,set,del the actual propety values wherever they may come from, e.g. an RDB. Hmmm, interesting approach. But would that also mean that the principal may hold also sensitive information, e.g. the password? Are there any security concerns about doing so? You won't need it for authentication, so it would be sufficient to support setting the password through the principal object, which then would transparently work on the RDB. Sure it's possible, that's what I did. But it was quite complicated and I had to dig very deep into Zope3 code to do that. This is definitely no option for a Zope developer who needs to quickly set up a cookie-less application. Did you make your cookie-less credentials plugin available somewhere? I can send you my code, if you like. However, it's somehow a little bit ugly due to some Zope3 internals I could not understand/solve. Would be nice to have it, though I don't know whether I'll have the time for a closer look and eventually help you with Z3 stuff, at least until Aug 18th (end of GSOC). What I moreover think about is why not to pull the PAU stuff out of zope.app and create a package such as zope.authentication. This may be more generic. I think most of the code assumes running inside the zope application server using ZODB (Persistent), so it won't be useful outside. To sum it up, during authentication, user information is needed four times: 1) In customization of authplugin.authenticateCredentials (to check for correct login/pass) 2) In the Authenticated PrincipalFactory, or, better, in a subscriber to that event which stuffs out the principal with all needed data 3) For getPrincipal() calls (Two in my case for every request, no clue why and where they are called). In case of a not-so-fast access to user data (such as in my case, where RDB queries have to be issued), caching can heavily improve the performance. So, it seems, a good idea would be to create some caching-related package that integrates nicely with the PAU. I am not sure, whether this can be generalized or should be specific to where the data is coming from. Yes, many thanks to you, too. And I would also be very interested in hearing comments about this from others. It seems there aren't too many people using PAU... BTW. I also send this to Roger Ineichen, as he also suffered from shortcomings of zope.app.authentication and built his own z3c.authentication, which is also an interesting read. (Although I could not yet find time to play around with it). Interesting, will have a look. florian pgp9NebvvmwK8.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond
On Wed, Jul 16, 2008 at 10:20:58AM +0200, Hermann Himmelbauer wrote: Am Mittwoch, 16. Juli 2008 05:48 schrieb Florian Friesdorf: InternalPrincipal is a persistent object used to store the data of principals in a PrincipalFolder, PrincipalInfo is returned upon successfull authentication and handed to FoundPrincipalFactory, which extracts some information and returns Principal objects. Ok, this is how I see it, too. But let me describe my understanding more specific: I see it that way that applications with authentication will normally have something like a user object, which stores all related authentication/user information. This user object may reside in a RDB, a text file, or, as here, in a PrincipalFolder (as an InternalPrincipal). I would put the object in quotation, too, as for example in RDB it isnt an object at all, but simply authentication data + properties and, yes, this corresponds to InternalPrincipal. If I understand it right, a Principal is an entity that is the result of an authentication process and holds all needed information for authorization. However, it is not designed to store user specific information, e.g. login names, user names and the like. And PrincipalInfo is somehow a specific aggregation of user data, which can be used throughout the application. This object may have to be inherited to an extended MyPrincipalInfo object, as many applications may need extra info from this object. So, both the Principal and PrincipalInfo objects have to be created out of the user object, it is not possible to create a Principal out of a PrincipalInfo and reverse. I think you are wrong here: zope.app.authentication.authentication.PluggableAuthentication.authenticate is the place to look at. 1. a PrincipalInfo object is got by calling authenticateCredentials from an authplugin 2. this is handed to an AuthenticatedPrincipalFactory, which returns a Principal object So, PrincipalInfo is internal to PAU and as far as I figured does not leave it. Objects that leave PAU are those created by AuthenticatedPrincipalFactories, for authentication, and by FoundPrincipalFactories, for searches - In case of PrincipalFolder that is Principal objects in both cases. Throughout my application, I have the following scenarios: - I need to display some user data (e.g. in a logged in viewlet): I'd use PrincipalInfo. I would use the principal object - I need to check for authorization somewhere in my application: I'd use the Principal. yes - I need to administer the user, e.g. change password etc.: I'd use the user object (InternalPrincipal) for that. I would again use the principal object, which transparently performs the changes wherever they are necessary, i.e all properties of the user are available from the Principal object and changes to them will happen on their actual source. - ??? In my application, all I have is the principal (request.principal). So I need a viable way to retrieve PrincipalInfo and User/internalPrincipal objects. How would I do that? principal is all you need, if it does not carry what you want, you can subscribe to FoundPrincipalCreated and AuthenticatedPrincipalCreated events and stuff on it whatever you need. - user object: There seems to be no zope3 support for that yet - so it seems I have to do this manually (some getUser(login) function, get the login from request.principal.id[lenAUTH_PREFIX):], not very pretty, though.). principal is the user object - PrincipalInfo: Don't really know - perhaps by somehow getting the PAU object and iterating over the authentication modules, calling some getPrincipalInfo method? I personally would favour some adapters, e.g.: InternalPrincipal = IInternalPrincipal(request) PrincipalInfo = IPrincipalInfo(request) In case you store your userdata in RDB, you do not need InternalPrincipal at all. I currently see to options: 1. custom AuthenticatorPlugin, AuthenticatedPrincipalFactory and FoundPrincipalFactory from principalfolder.py. Your AuthenticatorPlugin would need to return PrincipalInfo objects. Further, you write an event handler that listens for FoundPrincipalCreated and AuthenticatedPrincipalCreated, which puts all needed/wanted properties onto the Principal object, which was created by one of the factories. Those properties can be real python properties with get,set,del methods, which you can use to get,set,del the actual propety values wherever they may come from, e.g. an RDB. 2. you could further write your own factories and return whatever object you would like to represent your user in case of searches and in case of authentication. I think option1 is optimal for your use case, based on what you described so far. The current documentation leaves many of the above points open, or at least, did not describe them in a way so that I could understand them. Read the README.txt, look at the doctest in authentication.py
Re: [Zope-dev] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond
On Mon, Jul 14, 2008 at 09:50:25AM +0200, Hermann Himmelbauer wrote: (..) 1) No way to pass PAU-related information to form-code: In PAU, the (..) As I using PAU within Plone and PlonePAS to handle the credential extraction and form stuff, I can't say anything about PAU's capabilities of doing that. However, I wrote it down and will eventually look into it. 2) Lack of documentation: The entities Principal, InternalPrincipal, PrincipalInfo are very confusing to a newbie, I still don't get the big picture. InternalPrincipal is a persistent object used to store the data of principals in a PrincipalFolder, PrincipalInfo is returned upon successfull authentication and handed to FoundPrincipalFactory, which extracts some information and returns Principal objects. 3) Lack of plugins: No plugin for URL-rewriting, e.g. cookie-less browsers (retrieving auth-information from URL) etc. I don't know about URL-rewriting, but you should be easily able to write your own credentials plugin to extract whatever you like from a request object. I personally needed to write an authentication plugin for a SQLAlchemy based RDB, and was confused a lot of how/why to create Principal / PrincipalInfo objects: Should I create my own Principal/PrincipalInfo objects in order to stuff information into them that my application needs? Most probably that could work. How excactly should I cache user data so that a single browser request does not lead to multiple RDB queries? And where in the big picture is the User entity? (It's probably the InternalPrincipal object, I assume)... You don't need InternalPrincipal objects, they are specific to PrincipalFolder, IMHO. I think you need: - custom authenticator plugin, that authenticates against RDB and has a dictionary as cache: key = login, value = password; - custom foundprinciplefactory, that generates Principal objects from RDB data, again using a simple key=login,value=Principal dictionary as cache; - eventually a custom credentials plugin, that for your point 3. (..) So I would very, very much suggest to dig into PAU first and fix those shortcomings before porting it to Plone/Zope2. Exactly what I am doing :) Thank you very much for your feedback. florian pgpanEfbeSGFw.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond
On Sat, Jul 12, 2008 at 02:04:32PM +0100, Martin Aspeli wrote: I think it's worth displaying some sensitivity to the context of Google Summer of Code here. I too worry that PAULA may throw the baby (PAS) out with the bathwater. However, GSoC is an excellent incubator of RD, and has secondary goals such as bringing more people into the community and engaging with students so that they become the future contributors of our projects. Shooing them down in flames is not going to help. I see my work clearly in the RD area, too, and I would like to take it as an opportunity to get further involved with Plone and Zope development. Sorry, if I am kicking off flames on the way there ;) I wish that some of these discussions had been had in the open so that more people could weigh in. However, most people who aren't used to the open source way (and plenty who are, even) find it difficult to address a whole community on a public mailing list and understand the nuances of the responses. That very thing is part of the learning curve that GSoC seeks to address. point taken On balance, I think it's great that Florian is exploring new territory here. PAULA may or may become a part of Zope and/or Plone in the future. It may be that we use bits of it and let other bits evolve separately. It may be that it dies, but at least then we have a clear idea about what PAU is and what benefits it can bring. The notion of having a bridge component certainly sounds sensible to me. So, please, let's not be too harsh until we've seen the final product and given it a fair chance. thank you very much for supporting my idea florian PS: Did you intentionally not post to plone-developer's? As all of them are on zope-dev, too? pgpFu54UVRDDr.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond
On Thu, Jul 10, 2008 at 10:56:19PM +0200, Wichert Akkerman wrote: Previously Florian Friesdorf wrote: Hi *, within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages. All documents describing the project, as well as links to the code can be found here: https://chaoflow.net/projects/gsoc2008/z3membrane-ldap The one thing I am missing is: why? Well, Zope moved onwards from PAS to PAU and I think Plone should too, because: - PAU is way more pythonic and cleaner than PAS/PlonePAS, it is easier to write stuff for PAU; - we should use as much as possible of Zope3 and avoid custom solutions, increasing the mutual benefit of all Zope3-based projects. I am writing a PlonePAS plugin, that makes the world of PAU available to Plone, i.e. we can profit from whatever is available for PAU right now and becomes available in the future. Further, I am enabling pure zope3 content as source for users and groups, not only usable for Plone, but for all Zope3-based projects. And the resulting code is cleaner and easier to maintain and understand. For me, it is more a question of: why not? PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins. PAU is doing things different than PlonePAS/PAS, but I don't see how the current functionality of PlonePAS/PAS could not be achieved with PAU? Yes, there are a lot more plugins for PAS than for PAU, but that does not contradict, writing another PAS plugin, that makes all future auth plugin writing easier. Whether PAU could/should replace PlonePAS/PAS at some point, is a completely different story. It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate. At least, two months ago, when I started with my project, membrane did not support non-AT content and I don't know of any other project doing it; b-org is all archetypes. florian pgpLxDusES6DJ.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond
On Thu, Jul 10, 2008 at 05:01:49PM -0400, Philipp von Weitershausen wrote: Wichert Akkerman wrote: Previously Florian Friesdorf wrote: Hi *, within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages. All documents describing the project, as well as links to the code can be found here: https://chaoflow.net/projects/gsoc2008/z3membrane-ldap The one thing I am missing is: why? PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins. It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate. Exactly. I don't mean to pee on anybody's parade here, but IMHO Wichert is right. To be constructive, I think it'd be much more interesting to investigate hooking Plone up to an external authentication mechanism such as repoze.who. The main goal of the project is: to enable non-AT content as source for users and groups! On that base it was accepted as a GSOC project for Plone. The original idea was to extend membrane; after looking into it more closely, my mentor (Jens W. Klein) and me agreed, that doing it from scratch, using PAU is easier, future plugin writing will be easier and the whole Zope3 community could benefit from it, too. That is why the original proposal was discussed only on plone-dev and why I sent the mail now to zope-dev as well. Nobody has to use it later ;) but the circle of people who could benefit from my project, if they would like to, is definitely bigger doing it via PAU. And those people who want non-AT content-based users and groups, will get a fully functional PAU as well, which again they don't need to use for anything further, if they don't want to... florian pgpZ2VeLRwiKt.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] PAULA: bringing Zope 3's authentication to Plone and beyond
Hi *, within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages. All documents describing the project, as well as links to the code can be found here: https://chaoflow.net/projects/gsoc2008/z3membrane-ldap The code is not very interesting right now, but now would be the time to take any influence on what will be created during the next month - I am planning to continue to work on the project after the SoC. I will keep you updated on major advancements of the code. regards florian pgpzsuZPKGBBl.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] PAULA: bringing Zope 3's authentication to Plone and beyond
Hi *, within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages. All documents describing the project, as well as links to the code can be found here: https://chaoflow.net/projects/gsoc2008/z3membrane-ldap The code is not very interesting right now, but now would be the time to take any influence on what will be created during the next month - I am planning to continue to work on the project after the SoC. I will keep you updated on major advancements of the code. regards florian pgpcAnljBl3DE.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
