Hey,
Fabio Tranchitella wrote:
[snip]
I still think that starting from a very small list, allowing zope committers
to
add packages making an explicit commitment to maintain them would give us a
better overview of what does ZTK mean for each of us.
I'm of the opposite opinion; let's start
Fabio Tranchitella wrote:
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
About the text on the wiki page:
Addition of new packages
A new package can be added to the
Hey,
Wolfgang Schnerring wrote:
[snip]
After we reach a consensus on how to do it (I'm in favor of the way
outlined above, of course ;-), I'd like to add a step-by-step
walkthrough of the day-to-day development of a package somewhere below
http://docs.zope.org/zopetoolkit/process/index.html,
Jim Fulton wrote:
(Note that I'm using more precise jargon: project rather than
package. In the Python world, the word package means a module
that is implemented as a directory rather than a file. A project is a
collection of software for which we create distributions. We should
generally be
Hey,
Wolfgang Schnerring wrote:
* Fabio Tranchitella kob...@kobold.it [2009-08-07 11:46]:
* 2009-08-07 11:42, Wolfgang Schnerring wrote:
http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg
IMHO the KGS testing should be done using the controlled-packages.cfg
Hey Jim,
[optional integration and dependencies]
Would it be possible to turn this into a guideline document somehow that
we can include in the Zope Toolkit documentation?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hey,
Jim Fulton wrote:
[snip]
I do have some ideas for some specific minor cleanups in some of
these. (That had to do with zope.app.publication, not
zope.app.publisher.) That was blocked by the general instability we
have right now. I'd really like us to stop moving things around until
we
Hey,
Fabio Tranchitella wrote:
[snip]
In zope.component we use tests_require, in the very same way, for example.
Shall I remove it there, too? Is there a policy/document which explains how
we use extras and tests_require?
Probably not. I think it'd be very good to add something like this to
Hey Fabio,
Fabio Tranchitella wrote:
* 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
Hey,
Jim Fulton wrote:
[snip]
Then the question is whether the dependence of zope.app.zcmlfiles on
zope.app.interface is needed. I'll look to see what that's about.
For the record, I'd be happy to see zope.app.interface and
zope.app.module gone from our dependencies.
zope.app.zcmlfiles
Hey,
Jim Fulton wrote:
I think the KGS should define 3 categories of packages:
- ZTK packages
These are packages we maintain and expect people to build things on.
- Test packages
These are packages that build on the ZTK. These are used to test
the ZTK packages, but aren't
Fabio Tranchitella wrote:
Hello,
I just committed the removal of the dependency from zope.filerepresentation
to zope.container, breaking the dependency cycle.
A belated yay! Thanks!
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hey,
Fabio Tranchitella wrote:
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
Hey,
Stephan Richter wrote:
- Insufficient dependency lists.
I wish we were publishing z3c.recipe.depgraph results for all these
packages in a convenient place. I'm worried that fixing dependencies
introduced cycles again (that were of course really there).
That's not to complain about all
Shane Hathaway wrote:
Fabio Tranchitella wrote:
Is there a specific reason for having the version pinning? Automatic testing
of
zope.tales obviously fails using the KGS, because zope.traversing there is
3.7.1.
Is it possible to remove the versions stanza?
Sure. Pinned versions are OK
Hey Fabio,
Fabio Tranchitella wrote:
I'm sorry if I am flooding the list with all my requests/messages, but I
don't want to introduce changes without approval of more experienced zope
developers.
A belated +1 to discussing things, and +1 to doing work. :)
I was analyzing zope.app.publisher,
Hey,
Andreas Jung wrote:
[snip]
The diff between 3.5.1 and 3.5.2 is pretty long and substantial. I doubt
that such a major change us ok as a bugfix release. I should have become
a new major release.
From what you say, agreed.
Regards,
Martijn
Thomas Lotze wrote:
There are two functions in zope.traversing.api, getParent and getParents,
that are rather closely related. The former is implemented right in that
module while the latter adapts its argument to
zope.location.interfaces.ILocationInfo and calls getParents() on that.
Why is
Hey,
Jim Fulton wrote:
Well, um, we're in a position now where the various packages we've
released don't seem to work together, because we've been releasing
individual packages without running combined tests. I know this isn't
your fault, but I'm queezy about doing more of this.
Hey,
Fabio Tranchitella wrote:
it is evident that there is no consensus on the list of packages that are
part of the Zope Toolkit. As Gary suggested me, it looks like the concept
of ZTK is different for each developer and it is more or less the packages
I use and I care about.
In a way the
Hi there,
Fabio Tranchitella wrote:
While analyzing the dependency graph of one of our applications, I found
some missing dependencies. I'm not sure these are bugs, but I'd like to ask
your opinion about them:
- zope.app.publisher does not depend anymore on zope.app.pagetemplate, but
Jim Fulton wrote:
[snip[
I made it possible to override proxying by overriding the proxy
method. At this point, I think zope.app.publication provides a pretty
reasonable base class for custom publication implementations, although
the module arrangement could be made a bit simpler.
Chris McDonough wrote:
On 6/4/09 11:59 AM, Martijn Faassen wrote:
[snip]
I don't think it's complicated. It's nice to install an object somewhere
that stores data and has a UI and also be able to register it as a local
utility. If you were to have mutable global configuration, you'd need
some
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
* often it is nice to have application configuration to have a user
interface, so that end users can configure aspects of the application.
This may be filling in an email address or customizing a template or
adding a user, etc
Hi there,
Jim Fulton wrote:
[snip]
I think we're talking about 2 different things.
There is the registry that is local to the root object and that is
stored in the database. Having registration data in the database
makes sense for a number of reasons and I don't consider this
Christian Theune wrote:
[snip]
I find this pattern to be pretty neutral WRT the web or to locations (as
we know them from zope.location).
I think you're describing the pattern of (contextual) acquisition? :)
Unfortunately, I do have to point to a naming thing: the component
lookup methods
Hi there,
Roger Ineichen wrote:
[snip]
The only thing I could say about this concept is that we
didn't start to remove #BBB marked imports.
Just wait till we start remove the BBB imports and
the packages from install_requires ...
Since we were hardly in a hurry removing deprecation
Hey,
Stephan Richter wrote:
[snip]
I have been following this discussion and just want to mention that I fully
agree with Roger. If you release a final version of Zope or a package that
spews deprecation warnings or has not fixed the imports, then this should be
considered bad releasing.
Hi there,
We have a concept of Site in the Zope Toolkit, along with SiteManager
and the like. What this concept allows us to do is locally register
components. Most typically this is used for local utilities such as a
catalog.
During traversal, a thread-local is set with the current site, so
Hey,
Jens Vagelpohl wrote:
On May 28, 2009, at 13:08 , Martijn Faassen wrote:
What do people think about:
* the idea of renaming Site to Locus
I think that's a terrible name. While site at least means something
to people, locus doesn't carry any meaning in the specific knowledge
Matthew Wilkes wrote:
On 28 May 2009, at 12:39, Martijn Faassen wrote:
* Hm, I wonder whether it has something to do with local utilities.
I don't think I'd make this jump. I'd not be averse to a longer
package name if it made it more explicit.
I wasn't primarily talking about
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
I propose we use the word 'Locus' instead of 'Site'. This word doesn't
have a lot of connotations in the web programming world, and people can
guess by simply looking at the word it might have something to do with
*local* components
Hey,
Roger Ineichen wrote:
[snip]
My fear is that deprecated imports will pull in packages
and act as the single point of an egg declaration. If someone
removes a dependency during a deprecation import cleanup lets
say zope.formlib in z3c.form from version 1.9.0 to 2.0.0 then
it's possible
Hey,
Roger Ineichen wrote:
[snip]
What do people think about:
* the idea of renaming Site to Locus
Oh my god, many -1
Motivations beyond oh my god?
One reason Locus might be a bad word is because it's easily confused
with Location, a concept we already have.
What I like to see is that
Roger Ineichen wrote:
[snip]
The site offers a SiteManagementFolder, SiteManagerContainer
and a LocalSiteManager.
The SiteManagementFolder by default installed as ['default']
is absolutly useless and obsolate since the last refactoring.
It's just a container, earlier it was a kind of
Fabio Tranchitella wrote:
* 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.
Obviously there is no technical
Hey,
Jim Fulton wrote:
2. I think local configuration address use cases that most people
don't have but introduce complexity that I bet a lot of developers
trip over.
I think there are two cases where people typically deal with local
configuration:
* setting up local utilities (for
Hey,
Roger Ineichen wrote:
[snip]
Probably a rare use case or could become imporant if we use other
patterns then the container traversal pattern. Do you have some
ideas of using a contianer less traversal pattern?
Take a look at this graph:
Hi there,
Before we have this discussion yet again, I will record the official
stance in the zope toolkit decisions document, and I'll quote it here:
* When code moves to a new location to import it from (in the same or
another package), use a ``from foo import bar`` statement, with a
Stephan Richter wrote:
On Monday 25 May 2009, Shane Hathaway wrote:
+- Replaced the dependency on zope.deprecation with BBB imports
As a general question, how will people know that an import location changed?
CHANGES.txt.
Christian Theune wrote a test runner extension a few months ago that
Hi there,
Roger Ineichen wrote:
Sound interesting, what's an indirect imports checker script?
Code that Christian Theune should fold into zope.testing as soon as
possible. :)
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hi there,
(in particular Christian Theune)
What's the status of the 'import location' notification functionality in
zope.testrunner?
What's the status of the ZODB migration code?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Shane Hathaway wrote:
Martijn Faassen wrote:
I'm not sure about zope.rest; there's already a z3c.rest which likely
does something quite different, and I think a zope.rest package should
actually *talk* about REST. What about zope.httpview instead?
Well, no, I don't think it's generic
Shane Hathaway wrote:
Martijn Faassen wrote:
It's interesting to see zope.deprecation is a new dependency. We could
consider changing these deprecations to simple imports if this is
possible...
Certainly, but what is the right way to deprecate code, then?
We've just started to do imports
Hey,
Hermann Himmelbauer wrote:
[snip]
1) Simply write this directly into my page template
2) Hack zc.resourcelibrary, e.g. add a ZCML-directive media
3) Use some other package I'm unaware of
hurry.resource (an improved take on zc.resourcelibrary's idea) can't do
this right now either, but I
Tres Seaver wrote:
Resolution #1
=
+1
Resolution #2
=
Whereas:
[removing evaluateInlineCode]
zope.app.catalog: old-fashioned HTTP log test. Not very important.
zope.app.publication: the same
zope.app.exception: the same
zope.app.session: actually turns on
Hey,
Shane Hathaway wrote:
Done. I look forward to seeing the changes in the dependency graph.
Great, thanks!
The only cycle left in the zope.app.publisher graph is between
zope.container and zope.filerepresentation.
The graph now contains 42 notes, so we got rid of 3 more dependencies.
Hi there,
Shane Hathaway wrote:
[snip]
Summarizing:
zope.app.publisher - zope.view
zope.app.publication - zope.publicationregistry
zope.app.http - zope.rest
I'm not sure about zope.rest; there's already a z3c.rest which likely
does something quite different, and I think a zope.rest
Shane Hathaway wrote:
Martijn Faassen wrote:
So, the only dependency cycles left in zope.app.publisher are these:
zope.app.publisher -- zope.app.publication -- zope.app.http
I fixed those tonight. On the trunk, there are no longer any
dependencies between zope.app.publisher
Hey Shane,
Shane Hathaway wrote:
Shane Hathaway wrote:
Martijn Faassen wrote:
So, the only dependency cycles left in zope.app.publisher are these:
zope.app.publisher -- zope.app.publication -- zope.app.http
I fixed those tonight. On the trunk, there are no longer any
dependencies between
Alexander J Smith wrote:
I released a new version of zope.app.component to fix a bug introduced
in the recently deprecation of its metadirectives. Packages that were
broken by this should use this new version.
Oops: sorry for the breakage and thanks very much for the fix!
Regards,
Martijn
Hey,
Chris McDonough wrote:
[snip]
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
Hey,
Alexander J Smith wrote:
I just released a new version of zope.app.publisher. The changes in
this version are largely related to reducing dependencies on
zope.app.component and zope.app.container.
Thanks very much for doing this work!
I could actually remove the (direct)
Hi there,
This is a progress report on the package dependency refactoring work.
We've had a lot of people contribute to this process (thanks
everybody!), and bit by bit we are able to make a serious impact on
dependencies. Yay!
Let's take for example zope.app.publisher, which a few weeks ago
Uli Fouquet wrote:
Martijn Faassen wrote:
Alec Munro wrote:
I was just reading that, and am now hunting around on which files
exactly I have to modify to pin down the version to 3.8.1.
Add a [versions] section to your buildout.cfg:
[versions]
grokcore.view = 3.8.1
This will pull
Hi there,
I've factored more bits out of zope.app.component; the last bits could
go into zope.component. zope.app.component is now deprecated.
I've made new releases of zope.app.component and zope.app.interface,
along with zope.component.
If a package depends on zope.app.component, try to fix
Shane Hathaway wrote:
Martijn Faassen wrote:
It might actually be the best to move these ZCML directives *down* into
zope.component. That won't affect the dependencies of zope.component at
all in fact; the [zcml] dependencies of zope.component already need all
the dependencies
Hi there,
Alec Munro wrote:
Just trying to install Grok, and as seems to be the tradition, some
package updates have resulted in requiring a Visual Studio compiler to
be installed. In this case, it seems to be zope.container 3.8.2. Is
there a possibility of making a binary for this available?
Alec Munro wrote:
I was just reading that, and am now hunting around on which files
exactly I have to modify to pin down the version to 3.8.1.
Add a [versions] section to your buildout.cfg:
[versions]
grokcore.view = 3.8.1
This will pull in a fixed grokcore.view that won't pull in
Chris McDonough wrote:
On 5/18/09 6:42 AM, Martijn Faassen wrote:
Chris McDonough wrote:
I don't currently have access to publish zope.intid, but I think it's
probably
ready for a release too, BTW.
I just gave you access to this package. Stephan has a script by the way
that can give you
Chris McDonough wrote:
In SVN, as a result of changes to zope.container, zope.lifecycleevent,
zope.location, and zope.intid:
zope.intid/trunk/ OK (20 dependencies) (delta -14 dependencies)
zope.container/trunk/ OK (30 dependencies) (delta -2 dependencies)
zope.location/trunk/ OK (08
Michael Howitz wrote:
Am 15.05.2009 um 13:30 schrieb Martijn Faassen:
[...]
Cool. It would seem to make sense that the named template mechanism is
bundled along with the page template library anyway (instead of the
form
library). zope.formlib currently depends on zope.app.pagetemplate
Chris McDonough wrote:
[snip]
Er, it actually isn't a major release. None of *its* interfaces moved. I
thought we were defining major release as API change.
Hm, a dependency change isn't a bugfix either.
It's an edge case, and one where I think we should err on the side of
caution. It's a
Hi there,
I started working on zope.componentvocabulary. It exists now and
zope.app.interface and zope.app.component both depend on it, along with
zope.app.publisher. We're not entirely rid of zope.app.component yet though:
Martijn Faassen wrote:
[snip]
* the registration of the zope:view
Hey,
I need to do some analysis to see where the zope:view and
zope:resource directives are in use. I don't want to accidentally
introduce *more* dependencies as packages that use these directives
would now have to depend on zope.app.publisher instead of
zope.app.component, and
Chris McDonough wrote:
I don't currently have access to publish zope.intid, but I think it's
probably
ready for a release too, BTW.
I just gave you access to this package. Stephan has a script by the way
that can give you access to a wide range of packages, might be a good
idea if he ran
Chris McDonough wrote:
These branches were merged. I made a new release of zope.lifecycleevent
(3.5.2)
to PyPI.
Thanks very much for doing this work.
As a reminder for the future, please do release changes in the API (as
in zope.lifecycleevent) as major releases (i.e. 3.6).
I realize
Hey,
Hanno Schlichting wrote:
This is part of the whole named template adapter story. The rationale
for the whole story is to be able to replace the template of a view
without touching the view. So the template is looked up as an adapter
and not just accessed as self.index / self.template.
Hey,
Chris McDonough wrote:
[snip a lot of places where these interfaces are used]
I'm sure these interfaces are used all over the place as they're used to
help implement widgets; we can't just remove them from their original
location, but...
It's also apparently documented in Phillip's
Hey,
Chris McDonough wrote:
zope.container (32 transitive dependencies) has some possibly low-hanging
dependency tease-apart fruit. Does anyone have any ideas about to sort out
the
below, particularly with externalizing the mentioned interface dependencies?
- It depends on
Hey Chris,
Thanks very much for doing this analysis and work!
Chris McDonough wrote:
FWIW, this may not be useful to some, but here's a (not-very-detailed) report
on
all the zope.* packages in Zope's SVN and the number of transitive
dependencies
they have. They are sorted in the order
Hey,
Chris McDonough wrote:
On 5/14/09 11:05 PM, Chris McDonough wrote:
zope.container (32 transitive dependencies) has some possibly low-hanging
dependency tease-apart fruit. Does anyone have any ideas about to sort out
the
below, particularly with externalizing the mentioned interface
Michael Howitz wrote:
Am 14.05.2009 um 15:02 schrieb Martijn Faassen:
psnip]
Is this replacement compatible with zope.formlib's namedtemplate
mechanism? Will anything break?
No it is not compatible. So I think it's a bad idea.
Ah, all right, glad we agree.
Breaking the
dependency
Hanno Schlichting wrote:
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
Chris McDonough wrote:
On 5/15/09 2:46 AM, Michael Howitz wrote:
Am 15.05.2009 um 05:32 schrieb Chris McDonough:
Log message for revision 99961:
- Remove a dependency on ``zope.container.contained.Contained``
(this is a dumb base class that defines __parent__ and __name__
as None and
Fred Drake wrote:
On Fri, May 15, 2009 at 2:57 AM, Chris McDonough chr...@plope.com wrote:
It's a partial step towards getting rid of a dependency that zope.intid has
on
zope.container. I'm thinking that maybe that IContained interface belongs in
some other package (e.g. maybe
Stephan Richter wrote:
On Friday 15 May 2009, Fred Drake wrote:
Keeping the dependency graph clean is great, and there's plenty to do
there. But there's also something to be said about being able to keep
a substantial portion of it in your head. The cleanliness of the
graph isn't so
Stephan Richter wrote:
On Friday 15 May 2009, Martijn Faassen wrote:
It's tempting to start pushing more interfaces (and exceptions) down
into zope.browser to break dependencies further. It does run the risk of
turning zope.browser into a bit of a mash though. Perhaps that's worth
Hi there,
Michael Howitz wrote:
z3c.template is used there instead of zope.formlib.
I can merge this branch in the next days and cut a release.
I'm worried by the amount of *new* code that is pulled in just to reduce
a dependency. Making this change would pull in *more* dependencies, not
Michael Howitz wrote:
Am 14.05.2009 um 11:00 schrieb Roger Ineichen:
The last option I already implemented on the
icemac_no_formlib branch in zope.app.exception.
z3c.template is used there instead of zope.formlib.
I can merge this branch in the next days and cut a release.
As long as
Michael Howitz wrote:
Am 14.05.2009 um 12:05 schrieb Martijn Faassen:
[snip]
Could you talk a bit about what your branch is trying to accomplish?
zope.app.exception depends on zope.formlib's namedtemplate mechanism.
zope.formlib has many many dependencies but only this special function
Hi there,
Patrick Gerken wrote:
[snip]
I do not want to abuse you here as a support forum for pypi, but would
it be possible to publish a new release, but without providing the
distribution files?
The intention would be, not the break the installations with pinned
versions,
That would
Chris McDonough wrote:
Another thing is this: even if we're successful in teasing out dependency
info
so we do have a collection of truly independently useful things, after it's
all
over, we're going to get to a point one way or another where we make a big
package of stuff that just
Chris McDonough wrote:
[snip extending configuration patterns instead of replacing wholesale]
Often this code makes the subframework tremendously complex, and the
subframework grows inappropriate dependencies along the way. *Sometimes* the
situation gets so confusing for a new user, they
Hey Chris,
Chris McDonough wrote:
On 5/12/09 4:44 AM, Patrick Gerken wrote:
[snip]
I don't think there will ever be a point where it's finished; at least not
in
any time frame in which Zope is still relevant at the end. Sure, we can keep
the current setuptools distributions and keep
Hey,
Chris McDonough wrote:
[snip]
If your package depends on zope.app.publisher, you get *78* eggs.
63 eggs these days, by my measurement. Still far too many. I think with
some effort we can chop off quite a few more.
Look here at the main cycles in that graph (this is the cause of a lot
Hey,
Patrick Gerken wrote:
[snip]
Wouldn't it be possible to put them on a dedicated pypi?
pypi.support.zope.com http://pypi.support.zope.com?
Yes, but not without breaking backwards compatibility with a lot of
released buildout.cfg files, and having to arrange our own mirroring
services
Hey Chris,
What about the following alternative suggestion to alleviate some of the
underlying issues you point out.
I agree we are signaling badly which packages are interesting to
newcomers and outsiders and which packages aren't.
In part we've already done the damage with the packages in
Tom Hoffman wrote:
The implementation details are over my head, but what SchoolTool needs
is a middle ground between one big package and a giant pile of little
ones, because our primary deployment strategy is via Linux
distribution packaging, in Debian/Ubuntu in particular.
Currently, Fabio
Hey,
Chris McDonough wrote:
[snip]
I'd hope you'd agree that given a perfect world where packaging structure
backwards compatibility was not a concern:
- The original distribution structure was a mistake.
- Changing it would be a bugfix.
I think we should've gone for an approach where
Hi there,
In the ZTK futures thread Chris McDonough pointed out that right now
we don't signal which packages are easily reusable outside of the Zope
Toolkit and which packages aren't, and need a great knowledge of the way
the Zope Toolkit works and a large amount of installed packages.
In
Hi there,
zope.app.publisher is depended on by quite a bit of code that uses the
Zope Toolkit, as it defines brower:view and browser:resource and the like.
Unfortunately zope.app.publisher currently depends on more than 60
packages. This is rather excessive, and we'd like to cut down on this.
Hey there,
Tres Seaver wrote:
[snip]
I think we need to clarify terms / triage the sets of packages we are
talking about:
Sure, agreed, though I think we can already work with 'reusable' and
'not reusable' right now as hints to users. The 'not reusable' group
consists of 'wannabe reusable'
Hey,
Chris McDonough wrote:
Instead, I have argued for promoting packages that have some life of
their own (independent of the rest of the pile) into subprojects that
have their own release cycles.
Then outside projects such as Plone and Grok could depend on
independent versions of
Hey,
After reading this, I thought of one benefit that having a larger
package would have: it's somewhat easier to refactor for dependencies,
because all the code will be in a single checkout and all the tests can
be run together, and the fixed release can go out as a single release.
Having
Hi there,
There are various buildbots running for Zope-related stuff. The problem
is that they're only mentioned on mailing lists and such so nobody
remembers where they are, how to use them, and who to contact.
Could someone work with Sebastien Douche who is maintaining one buildbot
and
Hey,
Sebastien Douche wrote:
[snip]
* there's a buildbot
http://zope.buildbot.securactive.org/
http://grok.buildbot.securactive.org/
(missing repoze and zc.builout)
Thanks. Could you add a page to the zopetoolkit documentation about this
please? Otherwise again I will look through the
Hey,
Martin Aspeli wrote:
I'd be happy with that kind of policy.
Maybe you can help Sebastien Douche document the existing infrastructure
in the zopetoolkit website. It just has to be a page with a few
paragraphs so we won't keep *forgetting* that this exists and people can
find out about
Martin Aspeli wrote:
Martijn Faassen wrote:
Martijn Faassen wrote:
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for
new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse
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. The burden of evidence is on
301 - 400 of 1200 matches
Mail list logo
