On Thu, Aug 27, 2009 at 8:10 PM, Tres Seavertsea...@palladion.com wrote:
Stephan Richter wrote:
You can not require a minor version in setup.py.
Huh? setuptools doesn't care about how many dots are in the dependency.
What Stefan probably meant here was: You *shouldn't* require minor
versions
On Wed, Aug 19, 2009 at 10:40 AM, Reinout van Reesrein...@vanrees.org wrote:
On 2009-08-18, Hanno Schlichting ha...@hannosch.eu wrote:
I wrote http://pypi.python.org/pypi/plone.recipe.alltests, which tries
to do something similar at least.
Ha! That works fine and we're going to use
On Tue, Aug 18, 2009 at 4:07 PM, Reinout van Reesrein...@vanrees.org wrote:
Question: is there an existing recipe that does this? Main point is that I
don't want to specify the dependencies that are to be tested by hand, so that
seems to rule out z3c.recipe.compattest. But there's been so
On Fri, Aug 7, 2009 at 3:26 PM, Martijn Pietersm...@zopatista.com wrote:
The following checkin fixed this particular problem:
http://svn.zope.org/Acquisition/trunk/src/Acquisition/_Acquisition.c?rev=102564view=rev
The acquisition slice wrapper accepted Py_ssize_t arguments, but then
passed
On Sun, Aug 2, 2009 at 6:34 PM, Jim Fultonj...@zope.com wrote:
2. Some of the tests only pass if run separately, due to test
interactions. Presumably, this means that other tests aren't cleaning
up after themselves. I think we need a standard automated way to run
each package's tests
On Sun, Aug 2, 2009 at 8:30 PM, Tres Seavertsea...@palladion.com wrote:
I think I have fixed the ExtensionClass and Acquisition problems for
64-bit machines: I released new eggs to PyPI for them:
Awesome!
You wouldn't be interested to look at the C code in Persistence and
Zope2 itself? ;-)
On Sun, Aug 2, 2009 at 10:41 PM, Chris McDonoughchr...@plope.com wrote:
That said, why does Zope 2.1.2 use the zope.index textindex? The Zope 2
implementation is still very superior.
The current policy for the test runs is to test both all direct
dependencies and all transitive dependencies
On Sun, Aug 2, 2009 at 11:35 PM, Chris McDonoughchr...@plope.com wrote:
There's no way any release of Zope 2 should depend on zope.index, at least
until its index implementations are as good as the ones in Zope 2 itself. I
don't know if in the short term (for a release) that means that the
On Thu, Jul 30, 2009 at 7:43 PM, Tres Seavertsea...@palladion.com wrote:
Hanno Schlichting wrote:
I'd like to push code and ZCML from Products.Five into the appropriate
places in Zope2.
+1 in general, as long as we don't let any zope.app dependencies leak
out while this happens.
Hhm
On Mon, Jul 27, 2009 at 2:57 AM, Martin Aspelioptilude+li...@gmail.com wrote:
Hanno Schlichting wrote:
The ZopeTestCase classes themselves don't set up any of the ZCML
structure right now and I'd like to keep it that way.
True. This isn't a ZCML, thing, though. :)
The thread local itself
On Sun, Jul 26, 2009 at 5:21 PM, Martin Aspelioptilude+li...@gmail.com wrote:
The problem is that the interaction threadlocal isn't set up, so you get
an AttributeError.
It's easy to fix: just call Products.Five.security.newInteraction()
before the test is run.
Is this something that should
Hi.
I'd like to push code and ZCML from Products.Five into the appropriate
places in Zope2.
For example event.zcml registering events for OFS items, should live
in the OFS package. i18n.zcml setting up stuff for the request or the
publisher should live in the ZPublisher package, security
On Sat, Jul 18, 2009 at 2:08 PM, Stefan H. Holekste...@epy.co.at wrote:
All failures appear to be due to the new box running Linux x86_64.
Tests still pass fine on the Mac.
Any experience with this? MemoryError in Acquisition? WTH?
I don't have any experience with either 64-bit nor can I
On Sat, Jul 25, 2009 at 8:01 PM, Shane Hathawaysh...@hathawaymix.org wrote:
Hanno Schlichting wrote:
I kind of suspect that we are seeing the results of
http://www.python.org/dev/peps/pep-0353 though.
That is very likely. BTW, that PEP links to a handy tool that reveals most
64 bit
On Mon, Jul 13, 2009 at 1:28 PM, Thomas Lotzetho...@thomas-lotze.de wrote:
We've started a new package, five.hashedresource, that is supposed to
integrate z3c.hashedresource into Zope2. Just to make sure not to step on
someone's toes: is it OK to just create such a package in that namespace?
like an obvious omission.
Can someone shed some light on this and tell me what is supposed to happen here?
Thanks,
Hanno
On Sat, Jul 4, 2009 at 8:03 PM, Tres Seavertsea...@palladion.com wrote:
Hanno Schlichting wrote:
Log message for revision 101181:
Correctly handle unauthorized exceptions
On Tue, Jul 7, 2009 at 2:31 AM, Tres Seavertsea...@palladion.com wrote:
Hanno Schlichting wrote:
Log message for revision 101616:
Revert r101557 and put back version pins for zodbcode and
zope.app.interface. These are actual dependencies of zope.app.zcmlfiles,
which in turn is a test
On Thu, Jul 2, 2009 at 12:30 PM, Jim Fultonj...@zope.com wrote:
zope.app.module provides support for persistemt modules.
zope.app.interface provides support for persistent interfaces. Both
rely on a highly experimental zodbcode. I don't have a problem with
these being projects, but I don't
On Thu, Jul 2, 2009 at 3:41 PM, Jim Fultonj...@zope.com wrote:
On Jul 2, 2009, at 7:58 AM, Hanno Schlichting wrote:
and zope.app.zcmlfiles still have a hard
dependency on zope.app.interface though.
I don't think zope.app.zcml files should be in it either. It was intended
as a bridge
On Wed, Jul 1, 2009 at 7:08 AM, Wolfgang Schnerringw...@gocept.com wrote:
I think it would be useful to standardize on *one* compatibility testing
method for the ZTK (and then document it).
I think it would be good if someone actually would define what the ZTK
includes in terms of packages ;)
On Wed, Jul 1, 2009 at 6:01 PM, Fred Drakefdr...@gmail.com wrote:
I've made a source distribution available via PyPI:
http://pypi.python.org/pypi/zope.interface/
Windows users would likely be thankful if someone with the appropriate
tools and know-how to build Windows binary distributions
On Tue, Jun 16, 2009 at 10:35 PM, Patrick Gerkendo3cc...@googlemail.com wrote:
A testcase in my code fails, and after a lot of digging, I am finding that
the reason are wrong results from the catalog. The catalog returns bad
results because he caches the results in the request.
My test
On Sun, Jun 21, 2009 at 9:38 PM, Laurence Rowel...@lrowe.co.uk wrote:
Jim Fulton wrote:
I don't agree. The semantics are different. For example, you often
want to traverse to things in a template that you don't want to expose
via URL. We currently (or last time I checked) expose ++resource+
On Wed, Jun 17, 2009 at 2:38 PM, Alex Clarkacl...@aclark.net wrote:
On 2009-06-17, Martin Aspeli optilude+li...@gmail.com wrote:
In Zope 2, your views *also* support acquisition, because until Zope
2.12 at least, they have to in order to have security. So you can do
self.REQUEST on the view,
On Wed, Jun 17, 2009 at 2:38 PM, Alex Clarkacl...@aclark.net wrote:
On 2009-06-17, Martin Aspeli optilude+li...@gmail.com wrote:
In Zope 2, your views *also* support acquisition, because until Zope
2.12 at least, they have to in order to have security. So you can do
self.REQUEST on the view,
Stephan Richter wrote:
On Thursday 28 May 2009, Roger Ineichen wrote:
btw, you are pointing to a good direction. Didn't we talk
about reload global configuration during runtime years ago?
BTW, plone.reload looks really promising.
For all I know plone.reload works and people use it during
Zope Tests Summarizer wrote:
Summary of messages to the zope-tests list.
Period Sun May 24 12:00:00 2009 UTC to Mon May 25 12:00:00 2009 UTC.
There were 8 messages: 8 from Zope Tests.
Test failures
-
Subject: FAILED (failures=1) : Zope-trunk-alltests Python-2.4.6 : Linux
Chris McDonough wrote:
On 5/25/09 12:37 PM, Tres Seaver wrote:
Debate, anyone?
+1.
+1, you? ;)
Hanno
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related
Hi.
Malthe Borch wrote:
The z3c.pt package shouldn't have difficult dependencies; it depends
on zope.i18n = 3.5 but reasons unknown to me (Hanno CC'ed).
The zope.i18n 3.5 dependency is used for the optimized i18n support in
Chameleon. I ported all the performance tweaks we made in Plone and
Chris McDonough wrote:
I tried to go after this today (reversing the dependency setup between
zope.formlib and zope.app.form). There are hundreds of changes that need to
be
made to move interfaces to zope.formlib. I made them (more or less
mechanically) but then couldn't get the tests
Chris McDonough wrote:
On 5/14/09 11:05 PM, Chris McDonough wrote:
- It depends on zope.filerepresentation but depends only on its interfaces
IReadDirectory, IWriteDirectory, and IDirectoryFactory.
(zope.filerepresentation has 32 transitive dependencies).
I found out that
Chris McDonough wrote:
I've created two codependent branches of zope.container and
zope.lifecyclevent:
[...]
I don't know if merging this stuff is reasonable. I do understand the
difference between lifecycle events and container events and the events I
moved out are definitely container
Chris McDonough wrote:
I did a bit of research on the direct zope.app.* dependencies of
zope.formlib.
- I looked into its dependency on zope.app.pagetemplate.
It defines two named templates in its form.py module using
The ViewPageTemplateFile class from zope.app.pagetemplate.
Chris Withers wrote:
Andreas Jung wrote:
but I see no option for using such a list for tracker notifications.
I suggest to add a pseudo member to the Zope 2 dev team and configure its
mail address to some new mailman list on lists.zope.org where ppl
can subscribe/unsubscribe at their own joy
Chris Withers wrote:
Given that the source of bug #372632 appears to be code related to
allowing views on exceptions in Zope 2, I thought I'd try use this method.
Try following the description given in the changelog at
http://svn.zope.org/Zope/branches/2.11/doc/CHANGES.txt?view=markup under
Martijn Faassen wrote:
Wichert Akkerman wrote:
[snip]
But you can use a lot of the Zope Toolkit with Zope 2.10, which is an
enormous benefit.
No, you can't, as far as I can tell. You'd have to remove Zope 3
entirely from Zope 2.10, and Plone relies on Zope 3, so this sounds
unfeasible.
Stephan Richter wrote:
Plone is using z3c.form. We are currently in the process of releasing
z3c.form
2.0, which has a massive amount of new features, which are very useful. As a
z3c.form developer I want to stay compatible with the current Plone release,
because (a) the code gets tested
Martijn Faassen wrote:
Martijn Faassen wrote:
What is the date that
you would feel comfortable about giving up Python 2.5 compatibility in
Zope Toolkit packages? I'm not leaving this thread without at least
*some* decision about this. :)
Oops, I meant of course giving up Python 2.4
Andreas Jung wrote:
On 05.05.09 17:36, Jens Vagelpohl wrote:
On May 5, 2009, at 17:23 , Andreas Jung wrote:
Unfortunately I can't get SVN 1.5 get working on my Mac.
SVN 1.5 from Fink works perfectly fine here.
Macports seems to provide only 1.6 - I see no option for reverting to
1.5 with
Tres Seaver wrote:
Hanno Schlichting wrote:
As a side note, we just started the community discussion about moving at
least to Zope 2.11 / 3.4 for Plone in a release by the end of this year.
This should take away some of the burden with Zope 3.3, but will not
change the Python 2.4 situation
Tres Seaver wrote:
Hanno Schlichting wrote:
Tres Seaver wrote:
Zope 2.12 with its many changes is seen as too risky to introduce into
our current stable series or into any release that aims to be released
as final by the end of this year.
For what value of risky? If you are that risk
Chris Withers wrote:
Lennart Regebro wrote:
Or, we could release 2.12 soon, and then start working on 2.13, a
version that explicitly is for people who want to move towards the
Zope Toolkit, and may not be completely backward compatible.
This would be my vote.
Right now the story for
Roger Ineichen wrote:
Betreff: Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/
Added some BBB code to setDefaultSkin
I don't mind if the skinnable story gets less intermingled
with the request story in a new zope.skinnable package and
breaks some backwards compatibility at that
Hi.
Roger Ineichen wrote:
Log message for revision 99518:
Added some BBB code to setDefaultSkin to allow
IBrowserRequest's to continue to work without configuring any
special adapter for IDefaultSkin. Lot's of code inside Zope2
relying on using the request object without tons of CA
Uli Fouquet wrote:
I put the sources in a private repository meanwhile. I'd prefer to put
the sources into Zope repository again, but if this is legally too
difficult, they will stay hosted elsewhere.
Why not merge it back to the original recipe in the collective now? Just
tell me your
Hi.
Roger Ineichen wrote:
Roger Ineichen wrote:
Then there's some tests and description missing proving that
intent. All I could read in the changelog and the skinnable
tests was pointing in the other direction: Making it possible
to use the Skinnable concept without relying on
Andreas Jung wrote:
I have no problem with the changes. You have my blessing if Hanno is ok
with the changes from the Plone prospective.
I'm OK with the changes from the Plone perspective.
I do however have a concern from the Zope perspective ;)
What I'm worried about is what kind of
Martijn Faassen wrote:
What do people feel about dropping Python 2.4 support in the Zope
Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave
vaguely as we *still* don't have a canonical list) only have to work in
Python 2.5 (and preferably 2.6), not Python 2.4 anymore.
Chris Withers wrote:
I'm also about -sys.maxint on these changes for Zope 2.12 as I'd like to
see 2.12 out the door as soon as possible.
Then we have a conflict of interest. My main goal for Zope 2.12 is to be
based on the Zope Toolkit 1.0 release and loose quite some more stuff.
That in
Andreas Jung wrote:
Please give feedback.
Cool!
Would you mind adding the versions.cfg from the Subversion tag to
http://download.zope.org/Zope2/index/2.12.0a4/versions.cfg ?
Makes for a bit more sensible URL compared to
http://svn.zope.org/*checkout*/Zope/tags/2.12.0a4/versions.cfg
Thanks,
Andreas Jung wrote:
Especially: using virtualenv --no-site-packages?
Most certainly not.
/home/xpmt/local/lib/python2.4/site-packages/zdaemon-2.0.2-py2.4.egg/zdaemon/zdoptions.py
does not look like zdaemon 2.0.4, which is listed in the index at
Andreas Jung wrote:
I just released
http://pypi.python.org/pypi/zope.z2release/0.1
that allows us to build an Zope 2 related index based
on the versions.cfg file of the Zope 2 package. Easy_installing
becomes pretty easy using this approach:
virtualenv foo
cd foo
source bin/activate
Stefan H. Holek wrote:
Do we still care about Python 2.4 + Zope 2.12? Do we go Python 2.6 only?
We still care about Python 2.4, I made a premature checkin of a new
zope.session version that is BBB incompatible. Bad me only tested under
Python 2.6 before checking in.
Hanno
On 20.04.2009, at
Uli Fouquet wrote:
Very interesting. Thank you very much, Roger! Right now I have some
problems with zdaemon as told in my reply to Christian. But if everybody
likes it, also Grok/grokproject will go that way :)
Hhm, for Plone 4 I was so far considering to not use zdaemon at all
anymore. Both
Tobias Rodäbel wrote:
On 19.04.2009, at 10:52, Andreas Jung wrote:
I just released Zope 2.12.0a2:
http://pypi.python.org/pypi/Zope2/2.12.0a2
doc/CHANGES.rst is missing in the source distribution on pypi:
Damn, I just finished uploading the Windows binary eggs for this release.
The PyPi
Andreas Jung wrote:
Hanno will build an a3 release soon (since I am on travel with no access
to my machines). Blame setuptools and SVN 1.6.
Zope 2.12.0a3 is released including Windows binary eggs for Python 2.4
to 2.6.
Cheers,
Hanno
___
Zope-Dev
Ethan Jucovy wrote:
How about just monkeypatching the active negotiator?
{{{
negotiator = getUtility(zope.i18n.interfaces.INegotiator)
orig = negotiator.getLanguage
negotiator.getLanguage = lambda foo, bar: 'fr'
text = my_page_template()
negotiator.getLanguage = orig
}}}
Haven't
Andreas Zeidler wrote:
Chris Withers wrote:
https://bugs.launchpad.net/zope2/+bug/360761
Now, who knows how to fix it? ;-)
this has been fixed in http://svn.zope.org/?view=revrev=99191
Wonderful, if Chris can confirm this, I'll make a new Acquisition release.
Hanno
Lennart Regebro wrote:
On Wed, Apr 15, 2009 at 17:09, Martin Aspeli optilude+li...@gmail.com wrote:
I didn't even realise Zope 2.12 was meant to run with Python 2.4. I
thought it was 2.5/2.6 only. Guess I was wrong.
I thought the same, and I'm sure at least Jim said that 2.4 support is
Chris Withers wrote:
Hanno Schlichting wrote:
Andreas Zeidler wrote:
Chris Withers wrote:
https://bugs.launchpad.net/zope2/+bug/360761
Now, who knows how to fix it? ;-)
this has been fixed in http://svn.zope.org/?view=revrev=99191
Wonderful, if Chris can confirm this, I'll make a new
Chris Withers wrote:
Hanno Schlichting wrote:
This has include/Acquisition, but is that actually being used?
If not, then why is it included like that?
These are only the header files of Acquisition. Some of the C extensions
of the Zope2 egg depend on those headers.
Liar! ;-)
Ok, sigh
Chris Withers wrote:
Hanno Schlichting wrote:
how would I force recompilation in a buildout environment?
Via python setup.py build_ext -i -f - works in all environments.
Deleting the .so files is probably another way.
I guess that equates to:
bin/buildout setup path/to/setup.py
Hi.
Uli Fouquet wrote:
As Grok is now approaching the 1.0 release we (i.e. some Grok developers
and me) want to have a 'compliant' way to offer paster-based serving of
Grok instances.
I'd love to have the same for Plone, but failed to find any canonical
definition of compliant the same way
Chris Withers wrote:
A little gotcha in 2.12 is that, because Versions are now gone, you get
some weird errors when you try and view the ZMI using an older Data.fs.
The following fixed it for me:
cp = app.Control_Panel
cp._objects = tuple([i for i in app._objects if
Martin Aspeli wrote:
Declaring things dead has a tendency to become a self-fulfilling
prophecy, and probably not something we should do lightly.
I didn't mean to imply that we should declare Zope 3 dead based on this
mailing list thread. This is a big decision that might warrant a Zope
Chris Withers wrote:
If you try and iterate over an instance of this class, you get an
AttributeError: __iter__. This doesn't make a lot of sense, since you
*don't* get an error like that if you iterate over an instance of:
class X:
def __getitem__(self,i):
return 1
The change
Martin Aspeli wrote:
So, here is what I'd like to propose, ideally for Zope 2.12:
1) Use an event handler to ensure that any permission / declared in
ZCML actually creates a valid, Zope 2 permission. I have working code
for this here which we could put in Products.Five with ease.
+1
Chris Withers wrote:
Dieter Maurer wrote:
Tres has earlier proposed a meta egg to represent versions.cfg in
a setuptools only (non buildout) environment.
A meta egg is an egg that only list dependencies and does not contain
code of its own.
Indeed, so we'd need 2 eggs for Zope 2 :-(
Roger Ineichen wrote:
Betreff: [Zope-dev] who wants to maintain Zope 3?
Is anyone interested in maintaining Zope 3?
/me is certainly not
With Zope 3 I mean:
I think we should take a look if we can build a minimal
setup which Plone, Grok and other projects can use. Do you think
there
Chris McDonough wrote:
On 4/11/09 9:40 AM, Chris Withers wrote:
Zope 4 is built using Zope Toolkit 1.0, as is Grok, repoze.cfg, and
something else
repoze.bfg is actually *not* build with the Zope Toolkit at least as Zope
Toolkit is defined by the Steering Group. It uses only
Zvezdan Petkovic wrote:
On Apr 10, 2009, at 11:32 AM, Hanno Schlichting wrote:
We do have the use-case of allowing trusted people to add templates or
code TTW and many other things like data level and view based
security.
The RestrictedPython case however is something we will gladly give up
Tres Seaver wrote:
Hanno Schlichting wrote:
Lennart Regebro wrote:
So it's highly likely that Zope 2.12 is the last release of Zope2 that
Plone is going to use. Maybe a Zope 2.13 once Python 2.7 is released
might be of interest to Plone. But otherwise I don't see any reason for
a new Zope
Tres Seaver wrote:
I don't know how the 'alltests' script is being built, or I would have
run the tests myself and found the failure.
You run bin/buildout -c alltests.cfg and then bin/alltests
Hanno
___
Zope-Dev maillist - Zope-Dev@zope.org
Chris Withers wrote:
Apologies for the current test failure on trunk, why doesn't the
following testrunner run the zdaemon tests?
The testrunner recipe only puts the things in its own eggs section onto
the test path, so you need to do:
[test]
recipe = zc.recipe.testrunner
eggs =
Zope2
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
I think renaming Zope 2 to Zope Classic will be easy. If the Zope 2
developers are okay with this, let's go right ahead. Not much discussion
needed. Zope 2.11 becomes Zope Classic 11. It's a huge version number,
but Zope Classic is
Lennart Regebro wrote:
This is only mildly confusing. It can also only get better with time,
as Plone seems to continue away from Zope 2 and onto the framework,
which means we in the future may end up with Plone, Grok and BFG being
app servers on the Zope Framework.
The current line of
Hi,
Christian Theune wrote:
for some reason chameleon.zpt gives the following output:
html
head
/head/htmlheadgt;
body
/body/htmlgt;
The template seems fine, anybody seen that before?
As with all bug reports, exact version numbers (including the lxml
version) and the
Dieter Maurer wrote:
Unless newer SVN versions improved on this: using different
access protocols is hampered by svn:external as they were (still
are?) required to be absolute urls (including the protocal).
This way, the access protocol may change in between of a checkout
(involving
Tres Seaver wrote:
Roger Ineichen wrote:
Log message for revision 97754:
Use applySkin from new location zope.publisher.skinnable
instead of zope.publisher.browser.
This change breaks older packages who might expect a 3.5.x version to
have compatible dependencies: it impliictly
Hi.
Chris Withers wrote:
Got zope.interface 3.5.1.
Any chance someone could roll and release a Windows binary egg for this?
I just uploaded binary Windows eggs for Python 2.4, 2.5 and 2.6.
Hanno
___
Zope-Dev maillist - Zope-Dev@zope.org
Tres Seaver wrote:
Andreas Jung wrote:
Please look at the getPackages() method taking the version*cfg files
into account. So all versions should be pinned. However there is
obviously a difference between using buildout with pinned versions
and setuptools or a small undetected hole in the
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 who wants to use the
Dan Korostelev wrote:
2009/3/10 Hanno Schlichting hanno...@hannosch.eu:
Either you have a dependency and declare it or you don't have a
dependency. Since we don't want to use extras anymore, I think this
calls for another package which depends on zope.password and zope.schema.
I still don't
Chris Withers wrote:
I think documenting that something is going to go away is useful, but
ultimately, people only really worry about it when something stops working.
I think it's not that simple. Look at the amount of work people put into
the Zope stack in recent month to get rid of
Martijn Faassen wrote:
The deprecation system is a system that is intended to help developers
upgrade their code and that allows us to remove certain deprecated
features after a while.
* we have quite a few of these developers who are not happy about the
deprecation system.
* we've
Hi.
Martijn Faassen wrote:
No volunteers to help produce such a list?
Attached you'll find my suggestion for the list. It is based on the
Zope2/Plone perspective: Which packages do those two actually use from
all the zope.* packages.
I suspect the set will initially be a bit larger to
Martijn Faassen wrote:
I know opinions are divergent about 'extra' dependencies in setup.py.
These ar dependencies that effectively make a single project with a
single dependency structure into a number of virtual packages that
each can have a separate list of dependencies. Such a virtual
Martijn Faassen wrote:
Perhaps it's time to deprecate the deprecation system.
From my personal view, I think the deprecation system works in certain
cases in its current form. It does not work as the only means of
documenting API changes for the evolution of software.
I tend to think of
Tres Seaver wrote:
Tres Seaver wrote:
Log message for revision 97465:
Branch removing zope.deferred.
This checkin is the branch I had in mind when sketching out a
non-CPython-only zope.component story today.
Wonderful, +1
I think the change makes sense from the perspective of
Martijn Faassen wrote:
The main innovations in concepts are the name Zope Framework to
distinguish it from the Zope 3 application server and the
core/extra concept. These are all hopefully descriptions of what
are current practices, simply making them more explicit.
From what I read we do
Martijn Faassen wrote:
It might be we are able to establish a framework team without
elections by just picking out the bunch of people who are interested in
this.
That's been the Plone approach to creating the framework team. Some
people just decided to do it and didn't even bothered to ask
Tres Seaver wrote:
- How many projects are there which are going to need a Zope 3.5
release (as opposed to updates to some of the packages traditionally
part of Zope3)? I would bet that this set is smaller than the first.
For instance, I know that Zope 2.12 *says* it will rely on 3.5,
Jim Fulton wrote:
On Feb 24, 2009, at 11:12 AM, Tres Seaver wrote:
- - Using TestRequest involves pulling in all of zope.publisher, a
*big*
dependency; Shane wants to reduce such dependencies.
OK, I don't agree that zope.publisher is a big dependency, especially
for code that is
Martijn Faassen wrote:
Hanno Schlichting wrote:
[snip]
P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the
dependency graph ;)
That's a cool resource! (the general dependencies folder there)
Are you removing indirect dependencies before generating the graphs?
Yep
Stephan Richter wrote:
On Tuesday 24 February 2009, Hanno Schlichting wrote:
+This version of Zope2 is compatible with and is based on Zope 3.5.
Zope 3.5 has not been released. ;-) In fact development has just started.
What
KGS version do you guys use?
This one:
http://download.zope.org
Stephan Richter wrote:
On Tuesday 24 February 2009, Hanno Schlichting wrote:
We are still in early alpha here. By the time we move on to beta, 3.5
will hopefully have stabilized a bit.
What is your time frame for Zope 2.12?
We'll have a first alpha in the next days. Beyond that we aim
Martijn Faassen wrote:
Hanno, would you consider also generating graphs for the grokcore.* packages?
Can you point me to a buildout or virtualenv-friendly way of getting an
environment with those? Than it should be rather trivial to do for me.
Hanno
Tres Seaver wrote:
Hanno Schlichting wrote:
Andreas Jung wrote:
On Mon, Feb 23, 2009 at 17:46, Tres Seaver tsea...@palladion.com wrote:
Creating an instance from the SVN checkout itself doesn't work for me
either for the same reason. The created scripts try to use the general
Python
Tres Seaver wrote:
Hanno Schlichting wrote:
I looked at this, but guessing or reliably getting to the zopepy script
wasn't possible. So I added an explicit option to the script instead and
documented it. You can now use:
bin/mkzopeinstance --python=bin/zopepy
on the SVN trunk. You can
Tres Seaver wrote:
Using __setitem__ and __delitem__ has security implicatinos for
untrusted code: how are you addressing them?
Maybe I'm missing some knowledge about the security machinery then. I
thought the methods wouldn't be available to untrusted code at all, as
they start with an
401 - 500 of 620 matches
Mail list logo
