Zope-Dev January 2009

zope-dev@zope.dev

44 participants
77 discussions

snakebite
by Martijn Faassen 30 Mar '09

30 Mar '09

Hi there, Recently there was a project called snakebite revealed: http://www.snakebite.org/ http://mail.python.org/pipermail/python-committers/2009-January/000331.html It's basically a whole bunch of machines that open source projects, in particular Python related ones, can make use of for testing. It's essentially a buildbot farm as I understand it. The announcement says: "Every CPython, Jython, IronPython and PyPy committer will have access to every development server on the network. I’ve also extended the offer to prominent Python projects like Django and Twisted." I think the Zope project counts as a "prominent Python project" and we have a lot of interesting code to test, so perhaps they'll let us in. :) Would people be interested in working on making use of this platform? We could use it for testing of a wide range of packages. Perhaps the ZODB would be an interesting package to start with. If so we should approach snakebite to see whether we can get on board. Regards, Martijn

6 7

zope.security changes
by Martijn Faassen 09 Feb '09

09 Feb '09

Hi there, In the dependency cleanup effort we've got going on at the Grok cavesprint here at my house, we have moved code around some more. zope.security was already defining ZCML directives so we've moved the <class> directive from zope.app.component and and the <module> directive from zope.app.security into zope.security as well. These only need things that are in zope.security already (or its dependencies) and the directives are about security declarations, so they seem to fit quite well into their new place. This way we can (eventually) lift some dependencies of packages on zope.app.security and zope.app.component and point it to zope.security instead, which will help clean up the dependency structures. We've left backwards compatibility imports in place in the zope.app.* packages (hopefully enough of it) so that existing code will continue to work. Regards, Martijn

12 28

Plans for Zope 2.12
by Andreas Jung 06 Feb '09

06 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, based on an earlier Zope 2.12 thread http://mail.zope.org/pipermail/zope-dev/2008-October/033572.html I propose that we get out an alpha version of Zope 2.12 by end of February. http://mail.zope.org/pipermail/zope-dev/2008-October/033572.html Major changes: - - dropping Python 2.4 support officially (Python 2.4 is no longer officially supported by the Python developers so we can not safely support it) - - focus on Python 2.6 support for the final release (although there are still some tests failing - more than with Python 2.5). Possibly focus on Python 2.5 support for the alpha phase. Not sure if we want to support Python 2.5 and 2.6 officially at the same time. With the current classification of Python versions within the configure script I would suggest: TARGET=Python 2.6.X ACCEPTABLE=Python 2.5 Python 2.4.X would be basically not acceptable but could be used at your own risk using the --with-python option. - - complete eggification (apparently pretty much done) - - reducing Zope 3 dependencies (apparently pretty much done) - - removing ZClasses completely - - ship with ZODB 3.9 (currently in alpha stage) Rough edges/open points I encountered so far: - - RestrictedPython security audit: such an audit has been made by Stefan and Sidnei. I am not qualified to speak about the correctness of the audit. I assume they know what they were doing. Unless objections one might consider this issue as resolved - if not, please speak up. - - creation of some skripts e.g. "mkzeoinstance" when easy_install-ing the Zope 2 source distro does not seem to work or it is still missing - - how do to a "traditional" SVN checkout of the Zope 2 and the related Zope 3 modules? The Zope2.buildout maintains its dependencies through a KGS - the old-style SVN checkout uses svn:external. I think there is a need for having both and don't know of a save way for keeping the svn:externals and the KGS in sync (without additional manual effort). Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkl3KWoACgkQCJIWIbr9KYyKOwCfVI+gU1AZsIstWies9BVRGr4l +LcAn1MBC0jsed690vpeU2TJzYUz6xQ+ =YZQ/ -----END PGP SIGNATURE-----

12 27

dependency cleanup progress report
by Martijn Faassen 05 Feb '09

05 Feb '09

Hi there, After a lot of work we have progress to report on the dependency reduction front: http://faassen.n--tree.net/blog/view/weblog/2009/01/29/0 It's been a lot of work to get this far and there's a huge amount of work to be done still, but there is progress! The second dependency graph is against the trunks of all the packages, as we haven't done the releases yet to make this real. We will look into this tomorrow. We also need to document the various procedures we have been using to do this work so that others can jump in and help us. Regards, Martijn

3 4

Zope 3.4.0 Released!
by Stephan Richter 03 Feb '09

03 Feb '09

Hi everyone, It is finally here! Thanks goes to everyone who involved! January 29, 2009 - The Zope 3 development team announces the Zope 3.4.0 release. After 2 years of development, the Zope Foundation and the larger Zope community is proud to announce the release of Zope 3.4.0. The focus of the Zope 3.4 development effort has been the conversion from a monolithic source tree, to a set of many small packages (eggs), that can be used independently of each other. The core has been further stabilized through numerous bug fixes, and many new add-on packages have been developed to provide a richer development experience. With this release also comes a renewed commitment to a short and reliable release cycle of 6 months. Packages and Eggs ----------------- Zope 3 is now fully converted to an egg-based system. While some work still remains, it integrates very well with the rest of the Python community. The conversion to egg-based packaging also enables other Python developers to only have to use small bits and pieces of the complete Zope software system. The conversion means that Zope 3 developers do not use the classic Zope 3 tar-ball release anymore. However, for your convenience, Zope 3 developers will provide the classic Zope 3 tar ball releases for at least the 3.4 series and probably for 3.5 as well. So how are Zope 3 applications built using only eggs? The Known Good Set (KGS) ~~~~~~~~~~~~~~~~~~~~~~~~ The known good set -- or in short KGS -- is a configuration of packages and their versions that are known to work well together. The compatibility is frequently verified by running over twelve thousand tests on a daily basis [1]_. The KGS is tested against Python 2.4 and 2.5 on the 32- and 64-bit platforms. The list of controlled packages and their versions for Zope 3.4 can be found at the Zope 3 KGS site [2]_. The KGS can be used in several ways [3]_. The most common way is to "nail" the versions by downloading the version configuration file [4]_ and insert them as follows in your buildout configuration:: [buildout] versions = versions ... [versions] zope.interface = 3.4.0 ... ``zopeproject`` Project Builder ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To start building a project using a common setup, a package called `zopeproject` can be used to quickly setup the boilerplate for the project. Ample documentation is provided at the `zopeproject` home page [5]_. `zopeproject` uses Paste or ZDaemon to create a working server. The following commands get you started:: $ easy_install zopeproject $ zopeproject HelloWorld $ cd HelloWorld $ bin/helloworld-ctl foreground Demo Packages ~~~~~~~~~~~~~ At this point, there is no demo package demonstrating a simple Zope 3 application setup. However, the ``z3c.formdemo`` package can be used as a fairly minimal setup. To get started with it, enter the following:: $ svn co svn://svn.zope.org/repos/main/z3c.formdemo/tags/1.5.3 formdemo $ cd formdemo $ python bootstrap.py $ ./bin/buildout -v $ ./bin/demo fg .. [1] http://zope3.pov.lt/buildbot .. [2] http://download.zope.org/zope3.4/3.4.0/controlled-packages.cfg .. [3] http://download.zope.org/zope3.4/intro.html .. [4] http://download.zope.org/zope3.4/3.4.0/versions.cfg .. [5] http://pypi.python.org/pypi/zopeproject Downloads --------- - Zope 3.4 KGS: http://download.zope.org/zope3.4 - Zope 3.4 Controlled Packages: http://download.zope.org/zope3.4/3.4.0/controlled-packages.cfg - Zope 3.4 Versions: http://download.zope.org/zope3.4/3.4.0/versions.cfg - The classic Zope 3 source release can be downloaded from: http://download.zope.org/zope3.4/3.4.0/Zope-3.4.0.tgz Installation instructions for both Windows and Un*x/Linux are now available in the top level `README.txt` file of the distribution. The binary installer is recommended for Windows. Zope 3.4 requires Python 2.4 or 3.5 to run. You must also have zlib installed on your system. Resources --------- - Zope 3 Development Web Site: http://wiki.zope.org/zope3 - Zope 3 Developers Mailing List: http://mail.zope.org/mailman/listinfo/zope-dev Retired: http://mail.zope.org/mailman/listinfo/zope3-dev - Zope 3 Users Mailing List: http://mail.zope.org/mailman/listinfo/zope-users - Bug tracker at launchpad: https://launchpad.net/zope3 - IRC Channel: #zope3-dev at irc.freenode.net About Zope 3 ------------ Zope 3 is a web application server that continues to build on the heritage of Zope. It was rewritten from scratch based on the latest software design patterns and the experiences of Zope 2. The component architecture is the very core of Zope 3 that allows developers to create flexible and powerful web applications. Compatibility with Zope 2 ~~~~~~~~~~~~~~~~~~~~~~~~~ Zope 3 is not upwards compatible with Zope 2. This means you cannot run Zope 2 applications in Zope 3. We continue to work on the transition from Zope 2 to Zope 3 by making Zope 2 use more and more of the Zope 3 infrastructure. This means that new code written in Zope 2 can benefit from Zope 3 technology. Also, with care, code can be written that works in both Zope 3 and Zope 2. This allows a Zope 2 application to slowly evolve towards Zope 3. Unchanged Zope 2 applications are never expected to work in Zope 3, however. About the Zope Foundation ------------------------- The Zope Foundation, based in Fredricksburg, Virginia, is a not-for-profit organisation that provides support for the Zope community and the Zope platform and its associated software. Its community includes the open source community of contributers as well as the community of businesses and organizations that use Zope.

10 23

Fw: ** PROBLEM alert - Zope Project Services (SVN/Downloads/Mailman/...)/KGS age is WARNING **
by Christian Theune 01 Feb '09

01 Feb '09

Hi, the KGS turned from not-having-been-updated to missing. At least regarding to my monitoring. What's happened? Begin forwarded message: Date: Sat, 31 Jan 2009 07:09:44 +0100 (CET) From: nagios(a)mail.whq.gocept.com (nagios) To: ct(a)gocept.com Subject: ** PROBLEM alert - Zope Project Services (SVN/Downloads/Mailman/...)/KGS age is WARNING ** ***** Nagios ***** Notification Type: PROBLEM Service: KGS age Host: Zope Project Services (SVN/Downloads/Mailman/...) Address: download.zope.org State: WARNING Date/Time: Sat Jan 31 07:09:44 CET 2009 Additional Info: HTTP WARNING: HTTP/1.1 404 Not Found -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development

5 15

Progress on zope intid/keyreference.
by Dan Korostelev 01 Feb '09

01 Feb '09

I just finished working on zope's intid and keyreference packages. The whole key-reference stuff is now moved in zope.keyreference package and the new version of zope.app.keyreference is released that only contains compatibility imports, so it makes no sense to depend on zope.app.keyreference anymore - use zope.keyreference. All functionality of zope.app.intid, except ZMI stuff is moved to the zope.intid package. Old zope.app.intid package now only contains browser pages and add menu item as well as backward-compatiblity imports. So if you are not using ZMI - zope.intid is for you. Next, I'm going to split zope.app.catalog and check other packages for uses of zope.app.intid/zope.app.keyreference (I guess some sqlalchemy-related packages can depend on keyreference stuff). -- WBR, Dan Korostelev

2 3

Grok cave sprint summary, and future todos
by Martijn Faassen 01 Feb '09

01 Feb '09

Hi there, I've just made a lot of releases as the result of our dependency cleanup sprint. There are more releases to be made, but I think I've released the most important affected packages now. Christian Theune is going to follow up and release some more packages that we touched, probably tomorrow. I'm going to write up a document that describes how we analyzed dependencies and what approaches we took so that people who want to help have some idea of what to do. the most important affected packages are (as far as I can remember): zope.app.component ('class' ZCML directive moved into zope.security, site stuff extracted into zope.site) zope.app.security ('module' directive moved into zope.security, along with some helper functions) zope.app.container (most functionality moved into zope.container) zope.app.folder (base class moved into zope.container, Folder itself moved into zope.site as its main function was to mix in site management facilities) zope.traversing (depends on zope.location now instead of the other way around) zope.location (doesn't depend on zope.traversing anymore) zope.site (a new package extracted from zope.app.component and zope.app.folder) zope.container (a new package extracted from zope.app.container and zope.app.folder) Another thing we want to do is reduce the test dependencies of packages to almost nothing (or nothing at all). We think it'd be good if package only used what they depend on directly for testing purposes; testing dependencies in general should follow implementation dependencies. This might allow us to get rid of zope.app.testing at some point. Instead we'd like to see more (and more consistent!) 'testing' modules in packages that help with test setup. We have created a bunch of tools in the process of reducing dependencies: an extension to the test runner to track imports that could be modified to be from a better location (though 'grep' is very useful there too), z3c.recipe.compattest, and Christian Theune is working on a way to 'touch' the ZODB so that it will update any moved class to the new location. Note that we haven't finished going through the codebase changing imports from zope.app.folder to zope.site where possible - volunteers are welcome. This should further reduce dependencies in the entire graph as zope.site pulls in far less than zope.app.folder. If a bunch of us keep this up we'll that'll allow us to start retiring a lot of packages that are mostly unused, and have a smaller, easier set of Zope 3 packages to maintain and understand. Users of the Zope 3 libraries (plain Zope 3, Grok, Zope 2, Repoze, and others) should all benefit from this. Regards, Martijn

2 6

zope.app.keyreference, zope.app.intid and zope.app.catalog
by Dan Korostelev 31 Jan '09

31 Jan '09

While you guys are moving zope.app.container to zope.container and those cleaning many dependencies, I'd also like to clean intid/catalog related stuff. The whole thing consists of three main packages that can be cleaned: * zope.app.keyreference - it doesn't depend on any ZMI or container stuff, it's just a simple package defining the IKeyReference interface and implementing it for persistent objects. I'd like to rename the package to just zope.keyreference (and making z.a.keyreference depend on it). * zope.app.intid - this one depends on container stuff, because of events and also defines some ZMI views. The events are not a problem anymore, because we have zope.container now, but the ZMI stuff requires zope.app.publisher (though it's not in direct requirements for some reason). I'd like to move all stuff except browser pages to the zope.intid package. * zope.app.catalog - pretty the same story as zope.app.intid, but it also uses zope.app.form's auto-form-directives. I'd like to move the non-ZMI code to plain zope.catalog. However, it's still not clear to me what should we do with old imports and pickled objects (there are "over 9000" of them in case of key-references). I'd like to make non-deprecated backward-compatibilty imports in the old places until we have a generic and easy-to-use tool for "touching" ZODB objects. Suggestions/objections? -- WBR, Dan Korostelev

3 7

OSCON 2009 Call For Participation ends Feb 3rd - No Zope proposals yet
by Michael R. Bernstein 31 Jan '09

31 Jan '09

Hi folks, The deadline for the O'Reilly Open Source Convention Call For Participation is Tuesday Feb 3rd. OSCON will be held July 20-24 in San Jose, California. As of today, there are no Zope-related proposals, so yours could have a pretty good chance of acceptance. ;-) There have been a lot of exciting developments in the Zope world in the past year, and I for one would really like Zope to get more public exposure. So please, write up your proposals and submit them before the deadline! For more information, see http://conferences.oreilly.com/oscon http://en.oreilly.com/oscon2009/public/cfp/57 Cheers, - Michael Bernstein

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev January 2009