2009/3/11 Roger Ineichen d...@projekt01.ch:
Betreff: [Zope-dev] Proposal: refactoring of zope.app.security
- Move IAuthentication and other interfaces into new
zope.authentication package. Also move there PrincipalSource and the
checkPrincipal utility function. Also move there the
Hi All,
Now we have 'setuptools' as a dependency for all packages.
(I guess this is to make Buildout happy ?)
So, it is certain that 'pkg_resources' module will be always
available as it is bundled with 'setuptools'. If that is the case,
why do we need a fall-back import of 'pkgutil' to
Hi,
the data converter for objects raises a ValueError if it can't find a
factory. This is caught by the validation machinery around it and
displayed to the user with 'There were errors'. This isn't helpful as
the user isn't told whats going on and he won't be able to do anything
about it.
The
On Mar 11, 2009, at 8:24 AM, Baiju M wrote:
Hi All,
Now we have 'setuptools' as a dependency for all packages.
(I guess this is to make Buildout happy ?)
No, it is because setuptools is needed for namespace packages.
So, it is certain that 'pkg_resources' module will be always
2009/3/11 Dan Korostelev nad...@gmail.com:
Hi people!
One of most large packages that really wants to be refactored but
still wasn't touched is zope.app.security. It has much in it and it
brings many dependencies, including zope.app.form and company. And
even some zope.* packages, like
Hanno Schlichting wrote:
Dan Korostelev wrote:
This was done to avoid dependency on zope.schema. However, I also find
it very useful to have that vocabulary in zope.password. I think we
can add it to the vocabulary submodule without adding dependency on
zope.schema at egg level, because one
Hey,
If it's more convenient to have the vocabulary available in
zope.password, by all means add it there.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML
Hi there,
Okay, having read the whole thread, there seem to be two forces pulling
on zope.password:
* it'd be nice if zope.password had the vocabulary so that you didn't
have to include zope.app.authentication anymore just to get it.
* it'd be nice if zope.password didn't need any extra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
On Mar 11, 2009, at 8:24 AM, Baiju M wrote:
Hi All,
Now we have 'setuptools' as a dependency for all packages.
(I guess this is to make Buildout happy ?)
No, it is because setuptools is needed for namespace packages.
Hey,
Dan Korostelev wrote:
One of most large packages that really wants to be refactored but
still wasn't touched is zope.app.security.
In fact we did touch it a bit, moving some bits from it into
zope.security. And your zope.password work affected its dependencies of
course. But I know
Dan Korostelev wrote:
2009/3/11 Roger Ineichen d...@projekt01.ch:
Betreff: [Zope-dev] Proposal: refactoring of zope.app.security
- Move IAuthentication and other interfaces into new
zope.authentication package. Also move there PrincipalSource and the
checkPrincipal utility function. Also
Hey,
Dan Korostelev wrote:
If there's no more opinions/objections/suggestions, I'd start refactoring.
See my replies just now. I'm in favor of starting the refactoring work,
as long as you do it step by step.
Regards,
Martijn
___
Zope-Dev maillist
On Wednesday 11 March 2009, Christian Theune wrote:
Objections for changing this?
No. As long as all the tests pass, everything is game for z3c.form 2.0. :-)
Regards,
Stephan
--
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
On Wednesday 11 March 2009, Martijn Faassen wrote:
I think the latter is the least important right now, especially since
zope.component and zope.schema are already very foundational libraries.
So just add the vocabulary to zope.password if that is the only new
dependencies it will pull in as a
Hi,
2 weeks ago, I've implemented a support for nested group into the
branch svn://svn.zope.org/repos/main/z3c.form/branches/sagblmi-nestedgroup
All test pass and no compatibility issue.
Can I merge it to the trunk?
Regards
Laurent Mignon
___
2009/3/11 Laurent Mignon laurent.mig...@softwareag.com:
Hi,
2 weeks ago, I've implemented a support for nested group into the
branch svn://svn.zope.org/repos/main/z3c.form/branches/sagblmi-nestedgroup
All test pass and no compatibility issue.
Can I merge it to the trunk?
I think yes, if
Dan Korostelev wrote:
2009/3/11 Martijn Faassen faas...@startifact.com:
[snip]
You would expect from the naming that bits of zope.app.authentication
would end up in zope.authentication as well.
Yep, that can be expected from the naming, but really,
zope.app.authentication is just one of
Dan Korostelev wrote:
2009/3/11 Martijn Faassen faas...@startifact.com:
[snip]
- Move global principal registry, its IPrincipal/IGroup
implementations and its directives into new zope.principalregistry
package.
Why not name it zope.principal?
It sounds confusing to me. Also, the global
Dan Korostelev wrote:
[snip]
Well, as I said before, I wanted to use zope.password in my old Pylons
application that only uses zope.interface currently. I don't expect it
to be developed in more zope-ish way (though I don't expect it to be
developed much in near future :)), so I'd like to
Hi there,
Stephan Richter wrote:
[snip]
In my opinion going for an extra here just to avoid this is speculating
a bit too much right now. Do we really have users that want to use
zope.password and really don't want zope.component and zope.schema? If
so, we'll hear from them when they speak up
Laurent Mignon wrote:
Hi,
2 weeks ago, I've implemented a support for nested group into the
branch svn://svn.zope.org/repos/main/z3c.form/branches/sagblmi-nestedgroup
All test pass and no compatibility issue.
Can I merge it to the trunk?
What's the use case for this?
Martin
--
Hi people!
As a part of zope.app.security refactoring process, I extracted local
(persistent) permissions to new zope.localpermission. And I faced
one problem and I'm not sure about its resolution.
Originally, I wanted to only move the zope.Public permission
declaration into zope.security,
On Mar 11, 2009, at 10:29 AM, Martijn Faassen wrote:
Since Jim says you're not missing something, I'm going to add to the
Zope Framework Steering Group decisions that this is enough and we
could clean up __init__.py's to this if we would want to.
So, let me try to understand the decision
Hey,
Dan Korostelev wrote:
As a part of zope.app.security refactoring process, I extracted local
(persistent) permissions to new zope.localpermission. And I faced
one problem and I'm not sure about its resolution.
Originally, I wanted to only move the zope.Public permission
declaration
On Wed, Mar 11, 2009 at 10:56 PM, Zvezdan Petkovic zvez...@zope.com wrote:
On Mar 11, 2009, at 10:29 AM, Martijn Faassen wrote:
Since Jim says you're not missing something, I'm going to add to the
Zope Framework Steering Group decisions that this is enough and we
could clean up __init__.py's
2009/3/11 Martijn Faassen faas...@startifact.com:
You should write up a short description of what zope.principalregistry
does. In fact whenever we propose a new package we should describe its
mission statement in just a couple of lines. That'll help us think
about it better.
I'll add a short
Hey,
Zvezdan Petkovic wrote:
On Mar 11, 2009, at 10:29 AM, Martijn Faassen wrote:
Since Jim says you're not missing something, I'm going to add to the
Zope Framework Steering Group decisions that this is enough and we
could clean up __init__.py's to this if we would want to.
So, let me
2009/3/11 Martijn Faassen faas...@startifact.com:
Dan Korostelev wrote:
Originally, I wanted to only move the zope.Public permission
declaration into zope.security, because that permission name is
special and always available. As for other permissions
On Wed, Mar 11, 2009 at 3:22 PM, Shane Hathaway sh...@hathawaymix.org wrote:
Nit: In this case, two lines are better than one.
import pkg_resources
pkg_resources.declare_namespace(__name__)
There's no need to use the lesser known __import__ function when an
ordinary import statement
2009/3/11 Martijn Faassen faas...@startifact.com:
Oh, and on the topic, one more time: can we have a steering group
decision on the package requirements for zcml statements? Are we doing
extras for them or simply skipping them?
Sorry, I wasn't clear that there was an open question and I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hi there,
Stephan Richter wrote:
[snip]
In my opinion going for an extra here just to avoid this is speculating
a bit too much right now. Do we really have users that want to use
zope.password and really don't want
On Wed, Mar 11, 2009 at 1:52 PM, Dan Korostelev nad...@gmail.com wrote:
2009/3/11 Martijn Faassen faas...@startifact.com:
You should write up a short description of what zope.principalregistry
does. In fact whenever we propose a new package we should describe its
mission statement in just a
2009/3/12 Benji York be...@zope.com:
On Wed, Mar 11, 2009 at 1:52 PM, Dan Korostelev nad...@gmail.com wrote:
2009/3/11 Martijn Faassen faas...@startifact.com:
You should write up a short description of what zope.principalregistry
does. In fact whenever we propose a new package we should
Hey, people!
While working on splitting authentication interfaces and
PrincipalSource from zope.app.security to new zope.authentication
package, I discovered that PrincipalSource uses some functions from
zope.site, which is unacceptable dependency.
Those functions are getNextUtility and
Benji York wrote:
On Wed, Mar 11, 2009 at 1:52 PM, Dan Korostelev nad...@gmail.com wrote:
2009/3/11 Martijn Faassen faas...@startifact.com:
You should write up a short description of what zope.principalregistry
does. In fact whenever we propose a new package we should describe its
mission
Hey,
Dan Korostelev wrote:
The zope.principalregistry is an non-persistent implementation of
IAuthentication that allows us to define principals via zcml (the
principal directive and company) or with simple python calls. It's
also quite useful for tests.
It defines the registry and the ZCML
Dan Korostelev wrote:
2009/3/11 Martijn Faassen faas...@startifact.com:
[snip]
If it doesn't introduce new dependencies, I think a few more definitions
of permissions in zope.security won't hurt (only those commonly used).
I'd like that better than introducing a new package. Do you think this
I decided to start a new branch of that, because there's no still
response on my requests for a release. Here's the last message:
Let's decide that and make a release of zope.component so we could
move forward on adapting other packages to recent removal of BBB
interfaces.
Here's three
Hey, community.
As a part of zope.app.security refactoring process, a new package has
been created - zope.authentication. It basically contains
IAuthentication and other auth-related interfaces, as well as
PrincipalSource. So it's intended to define a basic concepts and
contracts of principal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Dan Korostelev wrote:
2009/3/11 Martijn Faassen faas...@startifact.com:
Oh, and on the topic, one more time: can we have a steering group
decision on the package requirements for zcml statements? Are we doing
extras for
Hi,
Sorry for doing this by email rather than unit test, but I'm a bit
over-stretched at the moment.
plone.z3cform has a backport of z3c.form trunk's TextLines widget
(when's that release coming, any ideas?).
In using it, I discovered that the converter (converter.py on z3c.form
trunk) does
Hey, people!
The refactoring of zope.app.security is now almost done. There's still
some polishing work to do and two little issues to resolve. One of
them is the zope's common permissions. Most of zope.* and zope.app.*
(and other) packages define some security protections for their
classes and
Martin Aspeli wrote:
Hi,
Sorry for doing this by email rather than unit test, but I'm a bit
over-stretched at the moment.
plone.z3cform has a backport of z3c.form trunk's TextLines widget
(when's that release coming, any ideas?).
In using it, I discovered that the converter
On Thu, Mar 12, 2009 at 12:52 AM, Shane Hathaway sh...@hathawaymix.org wrote:
Martijn Faassen wrote:
Since ``setuptools`` is a dependency of our packages anyway, we
can instead do the following::
__import__('pkg_resources').declare_namespace(__name__)
Feel free to use that
On Wednesday 11 March 2009, Martin Aspeli wrote:
It's confusing to users when the widget renders the value in seemingly
random order. :)
+1 on the first and second E-mail.
Regards,
Stephan
--
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
45 matches
Mail list logo
