* 2011-06-12 22:49, Chris McDonough wrote:
This seems slightly inconsistent with the adaptation worldview imposed by
getAdapter/queryAdapter. I think it would be more consistent if
c.queryAdapter(IFoo, foo) returned foo if foo already implemented IFoo
and there was no other more specific
* 2010-03-30 17:44, Martin Aspeli wrote:
I'm generally for it, we just need to (a) make sure we're not going to
negatively impact performance if we can help it and (b) explain our
rationale.
Not sure I understood correctly what Hanno proposed, but we are not going
to negatively impact
* 2010-03-08 18:16, Fabio Tranchitella wrote:
I'll wait till the week-end to release it, so everybody has the opportunity
to have a word on this topic.
I've released zope.component 3.9.3 with the change I discussed on the list
in the last couple of weeks (ZCML registrations using getSiteManager
* 2010-03-13 16:16, Marius Gedminas wrote:
I'm not entirely sure what the deprecation story is all about (well,
okay, it's about reducing the number of forks and opening the way to
Python 3 compatibility), but I'm a bit uneasy leaving it in such a
halfway state... On the other hand people
* 2010-03-04 20:51, Fabio Tranchitella wrote:
Committed with tests.
If nobody objects, I would like to release a new (bugfix) release of
zope.component with the current trunk. This is the relevant entry from the
CHANGES.txt file:
- The ZCML directives provided by zope.component now register
Hello,
* 2010-03-04 09:22, Baiju M wrote:
I wonder whether we can split ztk.cfg zopeapp.cfg further logically ?
Something like zca.cfg , index.cfg, form.cfg, auth.cfg etc. ? May be we
will end up with one cfg file for each package :)
I don't think we need to split the cfg files: IMHO what
* 2010-03-03 21:35, Tres Seaver wrote:
If the tests all pass, then I would say go ahead and commit it now, but
add tests to verify that the new feature works as you expect.
Committed with tests.
Best regards,
Fabio
___
Zope-Dev maillist -
Hi folks,
the ZCML directives in zope.component register components using the utility
method handler, which looks like:
def handler(methodName, *args, **kwargs):
method = getattr(zope.component.getGlobalSiteManager(), methodName)
In our company-specific framework (which is far far
Hello roger,
* 2010-03-03 11:36, Roger wrote:
Not sure if I understand you correct. But what do you think
about the following:
- implement a new optional attribute useLocal=True
in the directive and then configure the directive action
and make use of the (local) getSiteManager method.
* 2010-03-03 15:33, Stephan Richter wrote:
Mmh, I implemented z3c.baseregistry a long time ago, which allows you to
register components into arbitrary registries.
http://svn.zope.org/z3c.baseregistry/trunk/src/z3c/baseregistry/README.txt?rev=107147view=auto
Thanks for the link;
* 2010-03-03 14:57, Roger wrote:
If all kind of configuration directive processing is done before any kind
of DB root access and relevant event handling (e.g. site hook setup) this
seems fine to me. If not, then we run into troubles with the changes.
I've tried the patch running the whole ztk
* 2010-03-03 19:59, Chris McDonough wrote:
I think it would be useful to have a discussion about grouping some Zope
bits along functional lines for marketing purposes. This is really
independent of any discussion about the ZTK.
I wonder if calling
be done with consensus on zope-dev, but a group of people is really
interested in it, I don't think it can be or should be stopped and, TBH, I
don't see how it can influence the ZTK.
--
Fabio Tranchitella / Tranchitella Kft. http://tranchitella.eu
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D
* 2010-03-03 21:44, Jim Fulton wrote:
The ZTK was created in part to deal with instability issues arising from
people working on parts without testing the whole.
I suppose everybody here agrees that any change to a package which is part
of the ZTK *must* be tested against the whole ZTK. It
, as long as the console script is also provided to
process the queue (as it is now in 3.8.0).
In any way, to keep BBB, we should ensure that users of zope.sendmail will
have the thread running by default, without changing their code.
Thanks.
--
Fabio Tranchitella / Tranchitella Kft. http
Hello,
* 2010-01-13 01:41, Tres Seaver wrote:
The 3.7.0 version breaks Zope 2.12, which still expects to be able to
import QueueProcessorThread from the old location. I worked around the
problem for the moment by pinning 'zope.sendmail3.7.0', but it seems to
me that the BBB import should be
* 2010-01-11 06:25, Chris McDonough wrote:
I don't know exactly where to move this, but making zope.publisher a dep
of zope.i18n would be bad.
Using conditionals (eg. have zope.publisher) in ZCML seems a good solution
to me.
Best regards,
Fabio
___
Hello,
I'm preparing a new major releases for zope.sendmail, merging the
improvements and new features from the repoze.sendmail package. Here there
is a copy of the changelog:
- Removed dependency on ``zope.security``: the security support is optional,
and only available if the
* 2010-01-05 08:26, Fabio Tranchitella wrote:
While doing it, I'm trying to remove dependencies which are zope-specific,
to minimize the overhead for developers who are using the whole zope stack
(like me :)).
Ehm, I meant who are NOT using the whole zope stack.
Fabio
Can somebody please fix zope.contettype on PyPI? We had a 3.5.0 release,
and somebody uploaded a 3.4.3 release which should have been 3.5.1.
I don't have the rights for it.
Best regards,
Fabio
___
Zope-Dev maillist - Zope-Dev@zope.org
* 2009-12-29 21:54, Marius Gedminas wrote:
* Fabio Tranchitella is working to make the zope.testing.doctest
deprecation warning useful by doing scary things like converting
zope.testing.doctest from a module into a package that has all the
code in __init__.py. He asked
* 2009-12-28 13:31, Marius Gedminas wrote:
I think you mean assumes doctest is imported in zope.testing's
__init__.py.
There's no difference between modules or packages for the import
statement, witness
Yes, you are right; any comment on my patches though? I'd love to release a
zope.testing
* 2009-12-25 10:23, Lennart Regebro wrote:
Yes, we did. But now we try to get the deprecation warnings to show up in
the correct place. And we could warn for the usage of some of the names,
but in the message explain that doctest.py is deprecated.
What do you think about the attached patch
* 2009-12-24 11:40, Lennart Regebro wrote:
On Thu, Dec 24, 2009 at 08:26, Fabio Tranchitella kob...@kobold.it wrote:
I've tested the whole ZTK KGS using the current zope.testing's trunk and
the only failing package was zope.minmax (already fixed in the trunk),
because it imported
* 2009-12-24 16:20, Zvezdan Petkovic wrote:
Before I release the egg on PyPI:
1. Should we release as 1.1.2 (a minor change), or
2. Does the removal of dependency on zope.testing warrants a
bump to 1.2.0?
I think 1.1.2 is okey, you are not changing any behaviour of
* 2009-12-25 07:32, Lennart Regebro wrote:
On Thu, Dec 24, 2009 at 14:50, Fabio Tranchitella kob...@kobold.it wrote:
I don't think we can avoid the error, and to be honest I consider the code
in zope.minmax to be wrong.
import zope.testing
x = zope.testing.doctest.DocTestFile
Hello,
I think we should provide a zope.testing package which does not emit
deprecation warnings while running the testrunner on other packages,
otherwise there is no way to really understand why the package you are
working on is using a deprecated API.
I propose the patch attached to this
Hello,
* 2009-12-23 14:33, Marius Gedminas wrote:
@@ -328,6 +327,9 @@
def format_traceback(self, exc_info):
Format the traceback.
v = exc_info[1]
+warnings.simplefilter('ignore')
+from zope.testing import doctest
+warnings.filters.pop()
.
Fabio
* 2009-12-23 14:38, Fabio Tranchitella wrote:
...
___
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
* 2009-12-23 16:13, Benji York wrote:
As for having a broken trunk: I believe that every project needs a head
maintainer that feels personally responsible for the state of a
particular project. They would be in charge of reviewing and approving
branches before they are merged to the project
* 2009-12-23 22:48, Lennart Regebro wrote:
OK, I'm tired. It's only a major undertaking if you remove it completely.
zope.testings tests are mostly a question of running tests. Those should
obviously still use zope.testing.doctest, and then it's a much smaller
problem.
This is exactly what I
* 2009-12-24 07:12, Lennart Regebro wrote:
Yeah, that's fine by me. I see you did some ugly hacks to make it work
like making doctest.py into directory, but I don't have a problem with
that personally.
I've tested the whole ZTK KGS using the current zope.testing's trunk and
the only failing
I fixed the unit tests of the zope.interface package, which were broken by
the last release of zope.testing. Can somebody make a release, or give me
access to the PyPI package? My nickname is kobold.
Best regards.
Fabio
___
Zope-Dev maillist -
* 2009-12-22 22:54, Hanno Schlichting wrote:
I'd rather see a new zope.testing release fixing the BBB foul, which is
much less hassle.
Isn't the new release emitting a deprecation warning? In this case, I'd fix
zope.interface (and all the other packages).
zope.interface has C extensions and
Hello,
I've just committed a simple patch to allow extras in the eggs option of a
z3c.recipe.depgraph-based recipe. While doing it, I just realized that the
0.4 release has not been uploaded to PyPI, where the most recent version is
0.3.
Package index owners for the package are hannosch,
Hello,
I'm wondering if it would be possible to drop the dependency between
zope.location and zope.copy. It makes sense to me because zope.location
depends on zope.copy only because it registers a LocationCopyHook, not
because it is really using anything from that package.
Attached to this
* 2009-11-25 19:35, Tres Seaver wrote:
IFoo()
IFoo(x)
IFoo(x, y)
You can't use an arbitrary number of positional arguments for the
contexts, because we need to support the named / default cases too.
I'm probably saying something very stupid... What's wrong with the it?
Can't we define
Hello,
* 2009-11-16 10:25, Martijn Faassen wrote:
Anyone willing to make a new release of zope.component and zope.sendmmail,
or give me the pypi access to do it?
What's your pypi username?
kobold
Thanks,
Fabio
___
Zope-Dev maillist -
Anyone willing to make a new release of zope.component and zope.sendmmail,
or give me the pypi access to do it?
Thanks,
Fabio
* 2009-11-08 13:35, Fabio Tranchitella wrote:
* 2009-11-06 20:34, Fabio Tranchitella wrote:
I'm going to merge the code on Sunday, if nobody objects.
I merged
Hello,
* 2009-11-06 20:34, Fabio Tranchitella wrote:
I'm going to merge the code on Sunday, if nobody objects.
I merged the branch back to zope.component and fixed zope.sendmail, which
was importing a security-related symbol from zope.component.zcml; I ran the
ZTK tests and I have no failures
Hey Thomas,
* 2009-10-19 10:12, Thomas Lotze wrote:
I'd like to tackle the move of zope.site.hooks to zope.component this
week. While I'm sure that that wouldn't conflict with your work, I would
prefer releasing both refactorings at once as they both involve using the
new scheme of
* 2009-10-14 17:33, Martijn Faassen wrote:
That's more or less what I have in mind. The suggestions are just about
trying to make it prettier.
...
[snip]
I applied your suggestions, and I think now the code is more robust; with
this branch, all the ZTK tests pass except zope.sendmail, which
* 2009-10-12 08:55, Wichert Akkerman wrote:
Perhaps it is an idea to make zope.component an extension for
repoze.zcml? repoze.zcml already exists and works well, and people who
want the extra zope magic can keep using zope.component. I suspect that
is less work than trying to split up
Hello,
* 2009-10-09 15:37, Martijn Faassen wrote:
I'm okay with *not* doing the split up and going with your idea, but I
think eventually such a split up would simplify things. One advantage
would be that someone could examine repoze.zcml and not see distracting
ZCML implementations in
* 2009-10-07 22:40, Martijn Faassen wrote:
I think it would be interesting to review zope.component.zcml and see how
it depends on security, and see whether we cannot make the dependency
optional too.
I fully agree with this, and the main reason why I use a package like
repoze.zcml is to get
* 2009-10-09 13:59, Martijn Faassen wrote:
I propose we create a new zope.componentzcml package that contains the
zope.component.zcml code. This package is *optionally* dependent on
zope.security as well as zope.proxy. It should work with just a
dependency on zope.i18nmessageid and
Hello,
* 2009-10-05 12:15, Martin Aspeli wrote:
Would anyone mind making a 3.5.1 release, or else give me PyPI rights so
that I can do it myself.
Shouldn't this be 3.6.0?
Best regards,
Fabio
___
Zope-Dev maillist - Zope-Dev@zope.org
* 2009-09-30 18:04, Adam GROSZER wrote:
And ZTK sprinting?
I'm not going to the Plone conference (at least officially), but I'd be
interested in the ZTK sprinting. Anyone joining us? :)
Fabio
___
Zope-Dev maillist - Zope-Dev@zope.org
Hello,
* 2009-09-16 15:34, Thomas Lotze wrote:
There's a PathPersistent class in zope.location.pickling which is
decorated with a recent BBB comment, and had been questioned by a XXX
comment for some time before that.
[snip]
Does anyone object to these changes?
+1, I fully agree with
Hello,
* 2009-08-21 21:15, Dan Korostelev wrote:
What about removing the use of zope.deferredimport from zope.location and
make a new major release of zope.location?
+1, just change that to plain imports with # BBB comments.
Would it also be possible to remove the dependency of
Hello,
we deprecated locationCopy and CopyPersistent from zope.locaton.pickling
with the 3.5.3 release (which should have been a new major release, by the
way).
This introduced a new dependency on zope.deferredimport, but I just
realized that according to the decisions taken by the streering
* 2009-08-21 21:07, Dan Korostelev wrote:
IXMLRPCPublisher adapters for zope.container - move them to
zope.container. The IBrowserPublisher adapters that are already there, so
it won't make things worser. The zope.container package may be refactored
later to break dependency on zope.publisher
Hello,
zope.app.testing (which is part of thee ZTK) has failing tests on Python
2.4 introduced by the release 3.7.1 on the 2009-07-21 ; I've just committed
the fix (two lines diff), and I would like to make a new release and update
the ZTK KGS.
I don't have the right to make a new release on
Hello,
zope.index 3.5.2 (which is part of the ZTK set) has failing tests on all
the supported python versions (2.4, 2.5 and 2.6) on 64 bit platforms. These
test failures have been fixed by the 3.6.0 release.
I propose to upgrade zope.index from 3.5.2 to 3.6.0 in the KGS; I already
ran the ZTK
Hello,
* 2009-08-20 15:04, Michael Howitz wrote:
I gave the user 'kobold' (hoping that is you) the owner role on
zope.app.testing.
Thanks, I've just made the release.
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http
Hello,
with the today's changes, the KGS for the Zope Toolkit[1] has no build
failures on Python 2.4, 2.5 and 2.6 for both 32bit and 64bit Linux.
Kudos to everybody to work to achieve this result!
The next steps are:
- Add Windows and MacOS build slaves;
- Move the kgs definition to a better
Hello,
* 2009-08-18 14:57, Jan-Jaap Driessen wrote:
I would like to volunteer OSX buildbot slaves, buildbot master if necessary.
I'm currently running a buildbot master with two salves (linux 32bit and
64bit):
http://buildbot.tranchitella.it/ztk/
It is running the tests in the trunk for
Hello,
After messing up with my old-style Zope3 applications and getting crazy
understanding the interactions between zope.publisher, zope.app.publisher and
zope.app.publication, I decided to try bobo, the lightweight framework Jim
published a couple of months ago.
It worked out very well new
Hello,
* 2009-08-17 18:27, Jim Fulton wrote:
You should also look at the nascent bozo projects, especially bozo.reuse.
Looking at the documentation it looks wonderful stuff! Looking forward to
seeing it. :)
Fabio
___
Zope-Dev maillist -
Hello,
I hope this is the right mailing list for such a question. Why does
chameleon.core removes the meta tag http-equiv=content-type from the
output?
In template.py, line 286:
# Look for an encoding specification in the meta tag
match = utils.re_meta.search(body)
if match is not
Hello,
* 2009-08-13 13:06, Jim Fulton wrote:
So, I think we now have a tool that will let us take the next steps. Can
we all agree on this?
Yey, great! I will update my buildbot instance to use this system.
Fabio
___
Zope-Dev maillist -
Hello,
* 2009-08-08 16:20, Hanno Schlichting wrote:
On Sat, Aug 8, 2009 at 2:33 PM, Fabio Tranchitellakob...@kobold.it wrote:
Log message for revision 102578:
Moved dependency on zope.testing from install_requires to tests_require.
I thought we were not using tests_require yet, as it
I've created a policy draft as well as an initial list of packages on a
wiki page, which I hope will help us to collaborate on the list:
http://wiki.zope.org/zope3/ZTK
I've put into the list the packages that I'd consider part of the ZTK and
that I use in my applications. I don't know
Hello Wolfgang,
* 2009-08-07 11:42, Wolfgang Schnerring wrote:
[buildout]
develop = .
parts = whatever else you need compat
extends = http://url/to/kgs/versions.cfg
# assuming said versions.cfg uses a section called [versions]:
versions = versions
I've done something similar in
= zope.component
zope.interface
zope.event
zope.configuration
If somebody tells me how it is possible to get projects from the
controlled-packages.cfg using zope.kgs, I can modify the recipe code to
understand it. :)
--
Fabio Tranchitella http
* 2009-08-06 08:27, Shane Hathaway wrote:
Sure. Pinned versions are OK for a maintenance branch, but not the
trunk.
Thanks, I just committed the change.
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
, in a couple of weeks we will have a better overview of what does
the ZTK mean to each of us.
Ideas? Comments?
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
* 2009-08-06 15:30, Wichert Akkerman wrote:
How about another one:
* the package has to be usable with all of Zope 2, grok and the Zope 3
application server
Yep, I agree.
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http
as the intersection of the dependencies of zope2, zope3 and grok?
ZTK = intersection ( zope2-dependencies , zope3-dependencies, grok )
I don't think this definition fits our needs, but my skills on gron and
zope2 are too limited to bring counterexamples.
--
Fabio Tranchitella
Hello,
* 2009-08-06 19:30, Martijn Faassen wrote:
We need to get a procedure in place to do compat tests of what's in that
list, dependency graph guarding of what's in that list, and locking down
a KGS for that list. I think that since we have a list doing all these
things is only a matter of
Hello,
* 2009-08-06 18:55, Martijn Faassen wrote:
I was analyzing zope.app.publisher, and I found that it would be possible
to remove its dependency on zope.container because the latter is only used
in zope/app/publisher/xmlrpc/configure.zcml to declare thee views like
this:
view
Hello,
this is the buildout.cfg in zope.tales:
[buildout]
develop = .
parts = test
versions = versions
[test]
recipe = zc.recipe.testrunner
eggs = zope.tales
[versions]
zope.traversing = 3.4.0
zope.app.publisher = 3.4.
Is there a specific reason for
these interfaces to
zope.container.interfaces.
What about adding zope.filerepresentation as an extras_require directory?
If somebody is using zope.container.directory, it is possible to depend on
zope.container [directory].
Best regards.
--
Fabio Tranchitella http://www.kobold.it
was my original goal. :)
Thanks.
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8
Hello,
I'd like to release some packages with fixed/improved dependencies:
- zope.location
- zope.sendmail
- zope.pagetemplate
- zope.app.publisher
- zope.filerepresentation
These packages are already ok in the repository, but I don't have the rights to
do the upload to pypi. Can
=zope.container.traversal.ItemTraverser
permission=zope.Public
/
I think these snippets should me moved to zope.container's configure.zcml,
where we already have other traversers.
Do you agree with this change?
--
Fabio Tranchitella http://www.kobold.it
Free Software
Hello,
I would like to break the dep cycle between zope.container and
zope.filerepresentation. I already prepared the two patches (attached to
this e-mail), but I'm not confident enough with the zope3 repository to
check in them without asking for comments.
Is this the right way to break the
Hello,
* 2009-06-29 10:25, Martijn Faassen wrote:
Seems like a bug at first glance. Feel free to add the dependency back
(though I hope we can look into removing it again).
I would love to, but I don't have (yet) commit rights on svn.zope.org. :)
Thanks,
Fabio
miss dependency on
zope.deferredimport, it is ok in trunk but not yet released);
- I think we should release zope.sendmail (not it depends on transaction
instead of ZODB3, it is ok in trunk but not yet released).
Thanks.
--
Fabio Tranchitella http://www.kobold.it
Hello,
it looks like zope.sendmail should depend on transaction (because that's
what it is using, importing it) and not on the full ZODB3.
Am I missing something?
Thanks,
Fabio
___
Zope-Dev maillist - Zope-Dev@zope.org
* 2009-06-24 11:39, Jim Fulton wrote:
The main problem for Zope2 is that the current stable upstream branch
(2.12) still requires python2.4.
My fault, I meant 2.11 (which is the current stable).
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer
of Plone will happen at the end of the
year, which is already too late for Ubuntu Karmic (next stable release).
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
/ Ubuntu in this case.
We already have python2.5 and python2.6; after the release of stable
(either Debian or Ubuntu), we have to provide security support for all the
packages, and supporting three different versions of python is too much
work.
--
Fabio Tranchitella http
applications), and it would be a shame
to loose it.
To make explicit: I am not talking just about maintaining the ZMI, I'm
talking about making zope3 a *real* user-friendly web framework, as (for
example) grok is already right now.
Thanks.
--
Fabio Tranchitella http://www.kobold.it
/repoze/whatever is fashionable today,
but I suppose it would be quite painful for us.
If the question was who is interested in zope3, the application server,
and willing to maintain it, I'd answer me.
Best regards.
--
Fabio Tranchitella http://www.kobold.it
Free Software
in all, we manage applications in
a similar way we manage plone sites in zope2.x.
If this specific feature is going to be removed, I'm willing to support and
maintain it.
Best regards.
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http
,
as well as configuring local components.
I am sure that we are using only a small subset of the features ZMI offers
right now, but I suppose we are not the only one, and I really think that
maintaining and supporting it is important for the community.
Best regards.
--
Fabio Tranchitella
to know if anybody else is using ZMI for anything other than
this; if this is the typical usage scenario, than reducing it to a simple
UI is a good idea.
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
88 matches
Mail list logo
