* 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 perfor
* 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 reg
* 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-08 17:51, Roger wrote:
> A bugfix probably for your app, but a feature for zope packages
I thought it is a bug fix (I see no reason why it used the global registry
before, because it is totally equivalent) and it does not change the API
and the semantic of the ZCML directives.
I don't m
* 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 regis
* 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 - Zope-Dev
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 wha
* 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 wou
e it is already very stable). If this
cannot 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://tra
* 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 zope.{interface,component,schema,configurat
* 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 zt
* 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=107147&view=auto
Thanks for the link; z3c.baser
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 me
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 fr
n.
I like your approach, 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 / T
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.sendmail<3.7.0', but it seems to
> me that the BBB import should
* 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 ``zope.security`
* 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
Happy New Year to everybody,
I'm working to isolate a core set of ZTK packages which are independent
from Zope and reusable outside the Zope community. One of them is
zope.security, which can be used (and it is useful, indeed) with non-zope
frameworks too.
While doing it, I'm trying to remove dep
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
https://mail.zop
* 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
* 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.t
* 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-25 07:32, Lennart Regebro wrote:
> On Thu, Dec 24, 2009 at 14:50, Fabio Tranchitella 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
* 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
* 2009-12-24 11:40, Lennart Regebro wrote:
> On Thu, Dec 24, 2009 at 08:26, Fabio Tranchitella 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),
> > becau
* 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
* 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
* 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 projec
.
Best regards.
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.or
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
> > +war
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 messag
* 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
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 - Zope-De
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 messag
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, faassen.
* 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
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 - Zope-D
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.
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
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 conditi
* 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, whi
* 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 zope.
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 zop
* 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 zope.co
* 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
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
https://mail
* 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
https://mail.zo
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 w
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 zope.
* 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.publish
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 grou
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-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 an
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 com
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 PyPi
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 a
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 - Zope-Dev@zo
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 pro
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 - Zope-Dev
Hello,
* 2009-08-08 16:20, Hanno Schlichting wrote:
> On Sat, Aug 8, 2009 at 2:33 PM, Fabio Tranchitella 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 ye
s.cfg
packages = 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. :)
Hello Wolfgang,
* 2009-08-07 11:42, Wolfgang Schnerring wrote:
> [buildout]
> develop = .
> parts = 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 z3c.recipe.kgs (which is a f
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 anythin
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:
> >
>
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
t on top of the frameworks.
Am I correct saying that your idea is to restrict the ZTK to the packages
defined 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
* 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 an
.
Ideally, 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.tr
* 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.tranchite
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 havi
ecause the latter is only used
in zope/app/publisher/xmlrpc/configure.zcml to declare thee views like
this:
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
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 someb
l, remove the circular dependency was my original goal. :)
Thanks.
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
_
1024D/7F961564, fpr 5465 6E
pe.container.directory. I wouldn't add 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 rega
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 depe
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
__
k we should release zope.location (added 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 Tranchit
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
http://mail.zope.org/mailman/li
ase 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.tranchite
* 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
exactly
> a reason for them to choose Debian / 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
* 2009-05-28 13:09, Martijn Faassen wrote:
> What do people think about:
> * the idea of renaming Site to Locus
What is the technical advantage of renaming Site to Locus? To me it looks
just like a (not so necessary) cosmetic change.
Fabio.
___
Zope-Dev
platform for building not-only-web 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 T
I'd be curious 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
/editing objects to the ZODB,
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.
All 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 Consulta
to switch to the zope toolkit/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
91 matches
Mail list logo