-----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-----
On Wednesday 21 January 2009, Andreas Jung wrote:
- 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.
Note that Jim never explained to me how he does these audits, but I gathered some methods he used in conversations. I think I did a pretty thorough job during the review.
- 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).
You can write the svn:externals via a script. I did that for the big Zope 3 tree in zope.release. http://svn.zope.org/zope.release/branches/3.4/src/zope/release/tree.py?rev=8... The documentation is here: http://svn.zope.org/zope.release/branches/3.4/src/zope/release/README.txt?re... Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Wednesday 21 January 2009, Andreas Jung wrote:
- 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.
Note that Jim never explained to me how he does these audits, but I gathered some methods he used in conversations. I think I did a pretty thorough job during the review.
Yeah, this disturbs me a lot still though :-S It's a shame Jim has so little time to spend on this... It's also a shame that no one seems to be able to get any sense out of the PyPy guys in this area... One thing that myself and Shane talked briefly about on this list was re-implementing the AST manipulation as dissallow-by-default filter rather than a straight manipulation. That way, unexpected stuff should be allowed by default. That feels like it might be a lot safer when it comes to python version changes, but I must admit, I haven't looked closely enough to give a definitive answer... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22.01.2009 10:38 Uhr, Chris Withers wrote:
Stephan Richter wrote:
On Wednesday 21 January 2009, Andreas Jung wrote:
- 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.
Note that Jim never explained to me how he does these audits, but I gathered some methods he used in conversations. I think I did a pretty thorough job during the review.
Yeah, this disturbs me a lot still though :-S
It's a shame Jim has so little time to spend on this...
Take your hat and collect some money for hiring Jim :-)
It's also a shame that no one seems to be able to get any sense out of the PyPy guys in this area...
One thing that myself and Shane talked briefly about on this list was re-implementing the AST manipulation as dissallow-by-default filter rather than a straight manipulation. That way, unexpected stuff should be allowed by default. That feels like it might be a lot safer when it comes to python version changes, but I must admit, I haven't looked closely enough to give a definitive answer...
You know the difference between fiction and the reality. We have RP now and have to deal with it within a reasonable amount of time. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkl4Wp4ACgkQCJIWIbr9KYxNnwCeOcvTqwCPsoXvPFh6lJ03+un2 NaEAn2kU7climKJQXvnnmOhJPJ3ZVkhJ =fUMO -----END PGP SIGNATURE-----
Andreas Jung wrote:
It's a shame Jim has so little time to spend on this...
Take your hat and collect some money for hiring Jim :-)
Zope Corp chose to assume the Zope brand for themselves, given the prevelence of Zope 2 and RestrictedPython, it'd be nice if they could devote some of Jim's time to this...
One thing that myself and Shane talked briefly about on this list was re-implementing the AST manipulation as dissallow-by-default filter rather than a straight manipulation. That way, unexpected stuff should be allowed by default. That feels like it might be a lot safer when it comes to python version changes, but I must admit, I haven't looked closely enough to give a definitive answer...
You know the difference between fiction and the reality. We have RP now and have to deal with it within a reasonable amount of time.
I don't think this is such a huge change, it's a change in the style of what RP does already, not a complete re-implementation... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
I don't think this is such a huge change, it's a change in the style of what RP does already, not a complete re-implementation...
OTOH, with Python 3 now released, it seems unlikely that we'll see any new syntax added to Python 2.x. So RP doesn't really need any sort of overhaul until we start switching to Python 3. Shane
Shane Hathaway wrote:
Chris Withers wrote:
I don't think this is such a huge change, it's a change in the style of what RP does already, not a complete re-implementation...
OTOH, with Python 3 now released, it seems unlikely that we'll see any new syntax added to Python 2.x. So RP doesn't really need any sort of overhaul until we start switching to Python 3.
I'm still curious as to how hard a job this will be, part of me hopes this will be a lot easier than expected ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2009-1-22 09:38 +0000:
... One thing that myself and Shane talked briefly about on this list was re-implementing the AST manipulation as dissallow-by-default filter rather than a straight manipulation. That way, unexpected stuff should be allowed by default.
The terms do not seem to match: "disallow-by-default" would mean that unexpected stuff would be disallowed by default. -- Dieter
Dieter Maurer wrote:
Chris Withers wrote at 2009-1-22 09:38 +0000:
... One thing that myself and Shane talked briefly about on this list was re-implementing the AST manipulation as dissallow-by-default filter rather than a straight manipulation. That way, unexpected stuff should be allowed by default.
The terms do not seem to match: "disallow-by-default" would mean that unexpected stuff would be disallowed by default.
Sorry, you're correct, I meant "unexpected stuff should be disallowed by default"... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Thu, Jan 22, 2009 at 10:38, Chris Withers <chris@simplistix.co.uk> wrote:
Note that Jim never explained to me how he does these audits, but I gathered some methods he used in conversations. I think I did a pretty thorough job during the review.
Yeah, this disturbs me a lot still though :-S
I know the feeling. :) I completely trust that Stephan did a good job if he thinks he did, but I would be happy if we could gather a bunch of smart people to spread the knowledge. Maybe a security review sprint at PyCon, or somesuch? I'd like to hang in a corner and suck up the smartness. :) Or, I'd love to help in a sprint to move to security proxies. It's a major job of course, and the minimal job is to make proxies that replicate the current very complex and idiosyncratic Zope2 security. At least such a sprint should be able to locate any big problems and "impossibilities" so we can think of a path to fix that. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:
On Thu, Jan 22, 2009 at 10:38, Chris Withers <chris@simplistix.co.uk> wrote:
Note that Jim never explained to me how he does these audits, but I gathered some methods he used in conversations. I think I did a pretty thorough job during the review. Yeah, this disturbs me a lot still though :-S
I know the feeling. :) I completely trust that Stephan did a good job if he thinks he did, but I would be happy if we could gather a bunch of smart people to spread the knowledge. Maybe a security review sprint at PyCon, or somesuch? I'd like to hang in a corner and suck up the smartness. :)
Or, I'd love to help in a sprint to move to security proxies. It's a major job of course, and the minimal job is to make proxies that replicate the current very complex and idiosyncratic Zope2 security. At least such a sprint should be able to locate any big problems and "impossibilities" so we can think of a path to fix that.
Ugh. -1 to any attempt to use "space suits" in Z2. I would rather move to a model which made it easy to mark some / all TTW objects as "trusted", disabling security checks altogether: the "untrusted users can edit TTW code" use case is pretty much irrelevant for any site I have worked on, with the exception of "old Zope.org", in ten years of working with Zope. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJhhrS+gerLs4ltQ4RAmeKAKDZTlDw2MYeMeb3m44MH0DSdnLP+ACfddS/ 9HkJcd4AVUQ0wE/WlFiwmd0= =PH69 -----END PGP SIGNATURE-----
Tres Seaver wrote:
Ugh. -1 to any attempt to use "space suits" in Z2. I would rather move to a model which made it easy to mark some / all TTW objects as "trusted", disabling security checks altogether: the "untrusted users can edit TTW code" use case is pretty much irrelevant for any site I have worked on, with the exception of "old Zope.org", in ten years of working with Zope.
Well yeah, but there's two cases which I bump into a lot: - semi-trusted and clued users editting ttw - paranoia over damage to anything other than the ZODB in the case of a TTW site having its auth compromised. (eg: someone writing their password on a post-it note) For both of these, RestrictedPython working as advertising would be a "good thing"... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Lennart Regebro wrote:
On Thu, Jan 22, 2009 at 10:38, Chris Withers <chris@simplistix.co.uk> wrote:
Note that Jim never explained to me how he does these audits, but I gathered some methods he used in conversations. I think I did a pretty thorough job during the review. Yeah, this disturbs me a lot still though :-S
I know the feeling. :) I completely trust that Stephan did a good job if he thinks he did, but I would be happy if we could gather a bunch of smart people to spread the knowledge. Maybe a security review sprint at PyCon, or somesuch? I'd like to hang in a corner and suck up the smartness. :)
The problem is that all the PyPy people smart enough to help just go "that's a bad idea, go away", and it seems only Jim is really confident enough to say how things should be with RestrictedPython in its current form... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Andreas Jung wrote:
- - removing ZClasses completely
...into a seperate egg/product, right?
- - 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).
Why do we need the old-style svn:external? If they really need to be kept in sync, then I'd suggest a tag creation script that created the svn tag from the kgs in question... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
While we are at it... The biggest offender is the zodbcode package, which does not appear to pass its tests at all under Python 2.6. Not having investigated this further I can imagine three courses of action: 1) Fix zodbcode (me shrugs) 2) Exclude zodbcode tests from the test suite 3) Remove zodbcode from Zope 2 (who's using it anyway?) Stefan On 21.01.2009, at 14:55, Andreas Jung wrote:
- 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
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)
Kudos to Hanno and others for the work, here.
- removing ZClasses completely
- -0. I don't want to invest effort in maintaining them, but if they are still working for people in 2.11, I don't think we need to rip them out.
- ship with ZODB 3.9 (currently in alpha stage)
I would add: - - Rip out remaining support for raising / hooking string exceptions, mostly becuase it makes things messier, and will need to go for 2.6 compatibility anyway. - - Fix any other deprecation warnings emitted by either the testrunner or by startup (there is one in zope.configuration right now which shows in in an ftest layer).
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.
I believe we can reasonably trust the effort Stephan and Sidnei made, here.
- 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).
I'm actually willing to abandon the "big tree" altogether, unless somebody comes up with a clever way to automate it from some Z2-specific KGS index. I think the canonical "source install" would be something like a tarball of a buildout tree, with the 'download-cache' directory already populated (maybe). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJeSzB+gerLs4ltQ4RArG6AJ94PDULNCka4+hN3kV6iUZdH2DUuQCfdyz+ dJVpFknWxqmIrZ/gZYeuVZM= =M4xx -----END PGP SIGNATURE-----
Previously Tres Seaver wrote:
Andreas Jung wrote:
- removing ZClasses completely
- -0. I don't want to invest effort in maintaining them, but if they are still working for people in 2.11, I don't think we need to rip them out.
+1 There is a whole lot of legacy code surrounding Zope startup and the persistent control panel that is only there to support ZClasses. Removing them would allow for a lot of further cleanups in a particularly crufty part of the Zope2 codebase.
- 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).
I'm actually willing to abandon the "big tree" altogether, unless somebody comes up with a clever way to automate it from some Z2-specific KGS index. I think the canonical "source install" would be something like a tarball of a buildout tree, with the 'download-cache' directory already populated (maybe).
Judging by the awesome lack of interest in a Zope 3 big tree release, and observing that Zope 2 is going down a similar eggification path I see no reason to keep a big tree for Zope 2 long term. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Friday 23 January 2009, Wichert Akkerman wrote:
I'm actually willing to abandon the "big tree" altogether, unless somebody comes up with a clever way to automate it from some Z2-specific KGS index. I think the canonical "source install" would be something like a tarball of a buildout tree, with the 'download-cache' directory already populated (maybe).
Judging by the awesome lack of interest in a Zope 3 big tree release, and observing that Zope 2 is going down a similar eggification path I see no reason to keep a big tree for Zope 2 long term.
Note that I have a script in zope.release that can update a big tree. The Zope 3.4 release will feature an update of that tree. Now that I have this script, I can use it for future releases, but we'll probably fade it out soon. (I just feel really bad not providing a migration path; note that people working with Zope 3.3 have probably never seen an egg-based release.) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Wichert Akkerman wrote:
Previously Tres Seaver wrote:
Andreas Jung wrote:
- removing ZClasses completely
This is done now.
There is a whole lot of legacy code surrounding Zope startup and the persistent control panel that is only there to support ZClasses. Removing them would allow for a lot of further cleanups in a particularly crufty part of the Zope2 codebase.
I removed the code that was obviously only used to support ZClasses. I expect there to be more that could be deprecated or removed after further inspection. Anyone is welcome to contribute to that ;) Hanno
Hanno Schlichting wrote at 2009-1-23 19:36 +0100:
Wichert Akkerman wrote:
Previously Tres Seaver wrote:
Andreas Jung wrote:
- removing ZClasses completely
This is done now.
Wow. This was quick! Much quicker than fixing bugs reported in the collector :-( -- Dieter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25.01.2009 12:44 Uhr, Dieter Maurer wrote:
Hanno Schlichting wrote at 2009-1-23 19:36 +0100:
Wichert Akkerman wrote:
Previously Tres Seaver wrote:
Andreas Jung wrote:
- removing ZClasses completely This is done now.
Wow. This was quick! Much quicker than fixing bugs reported in the collector :-(
Please stop bitching and fix your favorite bugs in the collector. You have svn commit right *wink* Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkl8UsQACgkQCJIWIbr9KYxwrgCgvG3EtVLNxwxQ38ViGMAPgmrT MVUAoOMQgULfvw2PbPaTwyQYCM+fkpb/ =uuOZ -----END PGP SIGNATURE-----
Andreas Jung wrote at 2009-1-25 12:53 +0100:
...
- removing ZClasses completely This is done now.
Wow. This was quick! Much quicker than fixing bugs reported in the collector :-(
Please stop bitching and fix your favorite bugs in the collector. You have svn commit right *wink*
I will instead try to preserse useful functionality dropped without need from the Zope core *wink*. -- Dieter
On Jan 22, 2009, at 9:34 PM, Tres Seaver wrote:
I'm actually willing to abandon the "big tree" altogether, unless somebody comes up with a clever way to automate it from some Z2- specific KGS index. I think the canonical "source install" would be something like a tarball of a buildout tree, with the 'download-cache' directory already populated (maybe).
Yup (sort a). See zc.sourcerelease. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21.01.2009 14:55 Uhr, Andreas Jung wrote:
- complete eggification (apparently pretty much done)
We have to define what "eggification" means exactly. By now the Zope2.buildout seems to work fine with Python 2.4-2.6. I think we want to see Zope2 being easy_install-able. This means basically: - a source code release of Zope 2 can be done using (python2.X setup.py sdist (upload) - a user can easy_install Zope 2 from PyPI Hurdle: - setup.py defines all dependencies without version information (which is kept in the versions-zope2|3.cfg files. In order to make the version information available information I added the "setup2.py" file to the Zope2.buildout/trunk codebase (for experimenting). However this approach does not work with the dev packages like zope.app.locales. Also working with zc.sourcerelease won't solve this issue. Any idea how to deal with that? Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkl8DwgACgkQCJIWIbr9KYwCsQCg6Q08PLPptM6jCRQQ9HIqBxGc aKcAniHpd5h4cVInJmmOS33XZh9yGZJ2 =mpyi -----END PGP SIGNATURE-----
Andreas Jung wrote:
On 21.01.2009 14:55 Uhr, Andreas Jung wrote:
- complete eggification (apparently pretty much done)
I tried to make an old-style full-tarball release yesterday and ran into a problem. The setup.py in the created tarball references the 'src' folder in some steps, which isn't available in the full-tarball release (it's all in old lib/python). As setup.py is also used for the cmmi dance, you couldn't build or install from the generated tarball. At least the idea so far has been to replace the Zope2 SVN trunk in its current form with the Zope2-egg structure at which point the above needs to work.
We have to define what "eggification" means exactly. By now the Zope2.buildout seems to work fine with Python 2.4-2.6. I think we want to see Zope2 being easy_install-able. This means basically:
- a source code release of Zope 2 can be done using (python2.X setup.py sdist (upload) - a user can easy_install Zope 2 from PyPI
Hurdle:
- setup.py defines all dependencies without version information (which is kept in the versions-zope2|3.cfg files. In order to make the version information available information I added the "setup2.py" file to the Zope2.buildout/trunk codebase (for experimenting). However this approach does not work with the dev packages like zope.app.locales. Also working with zc.sourcerelease won't solve this issue. Any idea how to deal with that?
We just need new releases for all those packages. I'm willing to do those, but need PyPi access to all of them [1]. I asked Stephan Richter in a private mail for that already. If someone else can provide me with access, that would be awesome :) As a second step I think we should at least provide the versions.cfg file in a public well defined location. Zope3 has this as http://download.zope.org/zope3.4/versions.cfg and Plone has http://dist.plone.org/release/3.2/versions.cfg If we can make it part of the release process to make the versions.cfg file available at maybe: http://download.zope.org/zope2/2.12.0a1/versions.cfg that would be a good first step. I see value in a simple minimal index like Zope3 has in http://download.zope.org/zope3.4/minimal-3.4.0c7/ but that needs someone to figure out the exact process to maintain it. Hanno [1] zope.copypastemove, zope.dublincore, zope.formlib, zope.sendmail, zope.viewlet, zope.app.http, zope.app.locales
Andreas Jung wrote:
- complete eggification (apparently pretty much done)
We have to define what "eggification" means exactly. By now the Zope2.buildout seems to work fine with Python 2.4-2.6. I think we want to see Zope2 being easy_install-able. This means basically:
- a source code release of Zope 2 can be done using (python2.X setup.py sdist (upload) - a user can easy_install Zope 2 from PyPI
Hurdle:
- setup.py defines all dependencies without version information (which is kept in the versions-zope2|3.cfg files. In order to make the version information available information I added the "setup2.py" file to the Zope2.buildout/trunk codebase (for experimenting). However this approach does not work with the dev packages like zope.app.locales. Also working with zc.sourcerelease won't solve this issue. Any idea how to deal with that?
It's possible to have egg dependencies on development versions of other eggs so long as there is an svn egg link on the pypi page. For example in zope.sqlalchemy's pypi page I include a link like to: svn://svn.zope.org/repos/main/zope.sqlalchemy/trunk#egg=zope.sqlalchemy-dev And in the past I have had the trunk setup.py instal_requires include: 'SQLAlchemy>=0.5.0beta3dev-r4954', or 'SQLAlchemy>=0.4.7dev', Laurence
Previously Laurence Rowe wrote:
It's possible to have egg dependencies on development versions of other eggs so long as there is an svn egg link on the pypi page.
For example in zope.sqlalchemy's pypi page I include a link like to:
svn://svn.zope.org/repos/main/zope.sqlalchemy/trunk#egg=zope.sqlalchemy-dev
And in the past I have had the trunk setup.py instal_requires include:
'SQLAlchemy>=0.5.0beta3dev-r4954', or 'SQLAlchemy>=0.4.7dev',
Which also shows that using a setup.cfg to put revision numbers in dev versions is extremely useful :) Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Andreas Jung wrote at 2009-1-21 14:55 +0100:
... 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. ... - - removing ZClasses completely
But hopefully provided by a separate package, instead. -- Dieter
participants (12)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Hanno Schlichting -
Jim Fulton -
Laurence Rowe -
Lennart Regebro -
Shane Hathaway -
Stefan H. Holek -
Stephan Richter -
Tres Seaver -
Wichert Akkerman