[Zope-dev] Re: why external version indexes don't fulfill all use cases for development
Tres Seaver wrote: If I specify index as above, how do I get other packages which may not appear in that index? You install them in a separate transaction: the 'index_url' setting in a pacakge setup.py only governs where setuptools goes to find packages which are dependencies of that package. Is this a buildout thing? I've never known of transactions in anything to do with setuptools... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 4 OK, 1 Failed
Summary of messages to the zope-tests list. Period Mon Nov 12 13:00:00 2007 UTC to Tue Nov 13 13:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Test failures - Subject: FAILED (errors=1) : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:53:48 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008637.html Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:52:18 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008636.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:55:19 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008638.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:56:49 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008639.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:58:19 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008640.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: why external version indexes don't fulfill all use cases for development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Tres Seaver wrote: If I specify index as above, how do I get other packages which may not appear in that index? You install them in a separate transaction: the 'index_url' setting in a pacakge setup.py only governs where setuptools goes to find packages which are dependencies of that package. Is this a buildout thing? I've never known of transactions in anything to do with setuptools... I wasn't literally referring to a transaction, in the ZODB sense -- I meant, install using a separate run of easy_install'. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHObek+gerLs4ltQ4RAqshAJ0S2NM1w7ypM/r67fGRV6bD77p4NQCgr/5V ZzD/tfg+OcW3We3w+rYSzHw= =IhLV -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.publisher returns 200 Ok instead of 200 OK
Hi there, In zope.publisher.http, the status string for 200 is defined to be 'Ok', instead of 'OK', which is in the HTTP spec. Now status messages may, according to the spec, be replaced by 'local equivalents' without affecting the protocol, and the status messages in the spec are just examples. Still, it's a difference without a good reason. Changing this to 'OK' has some impact: particularly tests which verify the status string (which I'm currently writing) will break. Then again, thats' an easy fix. What do people think? Should this be fixed? Regarsd, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher returns 200 Ok instead of 200 OK
On Nov 13, 2007 9:33 PM, Martijn Faassen [EMAIL PROTECTED] wrote: In zope.publisher.http, the status string for 200 is defined to be 'Ok', instead of 'OK', which is in the HTTP spec. Now status messages may, according to the spec, be replaced by 'local equivalents' without affecting the protocol, and the status messages in the spec are just examples. Still, it's a difference without a good reason. Changing this to 'OK' has some impact: particularly tests which verify the status string (which I'm currently writing) will break. Then again, thats' an easy fix. What do people think? Should this be fixed? This came up before in a bug report on Launchpad, and it was decided that to change this would break too much code relying on the spelling of the response. Such code would be wrong, but there was not enough reason to break things. See https://bugs.launchpad.net/zope3/+bug/112109 -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Egg install bot results
I've created a bot process (see http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/checker.py) that: - checks out the trunk subdir of each top-level directory in svn.zope.org - if the resulting directory does not have a setup.py, we skip the directory - if the resulting directory does have a setup.py, we create a temporary virtualenv with setuptools installed and run the virtualenv's bin/python passing it setup.py install. - We capture the results of the install, and print a summary. The summary results are at http://www.plope.com/static/misc/checker_results.txt . The details pickle generated by the script is at http://www.plope.com/static/misc/results.pickle . My analysis of the results are these: - A version conflict exists in a low-level dependency between a requirement for zope.traversing 3.4.0 and a requirement for zope.traversing=3.5.0a1.dev-r78730 when installing many zope.* eggs using setup.py install (and easy_install), making it impractical for non-Zope people to actually install most of the interesting and released zope.* modules. This conflict needs to get fixed. Additionally, some modules (like zope.pagetemplate) should not fail with this dependency error in the first place; instead their dependencies need to become less conservative. - The only 10 packages (out of 80) in the zope.app namespace can be easy_installed. All the others fail with the above dependency error. Suggestions: - Find and fix the zope.traversing easy_install conflict. I'll try to debug this. - Institute a policy that all distributions that are released to the cheeseshop should be installable via easy_install. IMO, if they are not installable this way, they should not be released to the cheeseshop, given the larger Python community's expectations. - Figure out why buildout can (apparently) qsuccesfully install dependencies of currently failing zope.* eggs while easy_install can't. I probably won't be able to do this. - An automated test should ensure that easy_install does something reasonable with the latest release of each distribution. If the test fails, a new release should be made, or the dependency bug tracked down and fixed. My checker script could be made to do this, and I'd provide the work if someone told me which distributions to test, and how to maintain the list of distributions to test over time. - Ditch the idea of releasing separate distributions for each package in zope.app. The individual eggs typically can't be used outside of a zope appserver installation (and if they can, they probably shouldn't be in zope.app, they should be in zope or they should be their own top-level package), and the namespaciness of zope.app is suspect when it's unlikely that anyone who is not a Zope committer will release a distribution which makes use of that namespace package. Their current overgranularity makes distributing them as separate eggs and releasing them to the cheeseshop a form of cheeseshop pollution, especially given that so few of them can actually currently be installed using easy_install or setup.py install. If cheeseshop is going to continue to be used as the index, I'd suggest creating a zope.app top-level svn module with a single setup.py in containing all the packages that are meant to go into zope.app. Version the resulting zope.app distribution as necessary instead of versioning many more granular zope.app.* distros. It's OK if some people don't use some of the functionality in the resulting egg, just toss everything in. There is precedent here in the Paste distribution. It has many submodules and does many things, but it comes in the form of a single egg. Yes, you lose the ability to make a bugfix in one subpackage and release it, but IIRC the intent is to trim zope.app down anyway, pushing libraryish things out to top-level or zope.* packages. Issues: - Who's in charge? Whomever you might be, to what extent do you agree/disagree with the above suggestions? If you agree with any, how can I help fix things? - I'm unsure how anybody is able to install Zope 3 right now using eggs, unless there's some fundamental difference in the way easy_install resolves dependencies vs. buildout. I have not looked at how Stephan's KGS works yet, though, so I'm sure I'm just missing some magic. - We should consider fixing setuptools install to detect conflicts before attempting to install anything. The current regime of find conflicts halfway through an install is IMO untenable in the long term for using eggs as a distribution mechanism. This may mean a very invasive change to both the package index and the client software, though. ___ Zope-Dev maillist - Zope-Dev@zope.org
Re: [Zope-dev] zope.publisher returns 200 Ok instead of 200 OK
Hi there, On Nov 13, 2007 9:45 PM, Martijn Pieters [EMAIL PROTECTED] wrote: On Nov 13, 2007 9:33 PM, Martijn Faassen [EMAIL PROTECTED] wrote: [snip] What do people think? Should this be fixed? This came up before in a bug report on Launchpad, and it was decided that to change this would break too much code relying on the spelling of the response. Such code would be wrong, but there was not enough reason to break things. See https://bugs.launchpad.net/zope3/+bug/112109 Ah, I should've checked launchpad before reporting it. The discussion there is quite clear. Thanks! Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Egg install bot results
I've created a variant of the script I used to generate the results referenced in my original message within this thread. http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/releasechecker.py The new variant attempts to easy_install each cheeseshop project that has 'zope' in its author metadata (found via the cheeseshop's search XML-RPC interface) into a pristine virtualenv.This mimics what end-users would see if they attempted to install Zope-related packages from the cheeseshop without using zc.buildout. I'll set this up to run every few days. I'll attempt to send its output to zope-coders. - C On Nov 13, 2007, at 4:29 PM, Chris McDonough wrote: I've created a bot process (see http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/ checker.py) that: - checks out the trunk subdir of each top-level directory in svn.zope.org - if the resulting directory does not have a setup.py, we skip the directory - if the resulting directory does have a setup.py, we create a temporary virtualenv with setuptools installed and run the virtualenv's bin/python passing it setup.py install. - We capture the results of the install, and print a summary. The summary results are at http://www.plope.com/static/misc/checker_results.txt . The details pickle generated by the script is at http://www.plope.com/static/misc/results.pickle . My analysis of the results are these: - A version conflict exists in a low-level dependency between a requirement for zope.traversing 3.4.0 and a requirement for zope.traversing=3.5.0a1.dev-r78730 when installing many zope.* eggs using setup.py install (and easy_install), making it impractical for non-Zope people to actually install most of the interesting and released zope.* modules. This conflict needs to get fixed. Additionally, some modules (like zope.pagetemplate) should not fail with this dependency error in the first place; instead their dependencies need to become less conservative. - The only 10 packages (out of 80) in the zope.app namespace can be easy_installed. All the others fail with the above dependency error. Suggestions: - Find and fix the zope.traversing easy_install conflict. I'll try to debug this. - Institute a policy that all distributions that are released to the cheeseshop should be installable via easy_install. IMO, if they are not installable this way, they should not be released to the cheeseshop, given the larger Python community's expectations. - Figure out why buildout can (apparently) qsuccesfully install dependencies of currently failing zope.* eggs while easy_install can't. I probably won't be able to do this. - An automated test should ensure that easy_install does something reasonable with the latest release of each distribution. If the test fails, a new release should be made, or the dependency bug tracked down and fixed. My checker script could be made to do this, and I'd provide the work if someone told me which distributions to test, and how to maintain the list of distributions to test over time. - Ditch the idea of releasing separate distributions for each package in zope.app. The individual eggs typically can't be used outside of a zope appserver installation (and if they can, they probably shouldn't be in zope.app, they should be in zope or they should be their own top-level package), and the namespaciness of zope.app is suspect when it's unlikely that anyone who is not a Zope committer will release a distribution which makes use of that namespace package. Their current overgranularity makes distributing them as separate eggs and releasing them to the cheeseshop a form of cheeseshop pollution, especially given that so few of them can actually currently be installed using easy_install or setup.py install. If cheeseshop is going to continue to be used as the index, I'd suggest creating a zope.app top-level svn module with a single setup.py in containing all the packages that are meant to go into zope.app. Version the resulting zope.app distribution as necessary instead of versioning many more granular zope.app.* distros. It's OK if some people don't use some of the functionality in the resulting egg, just toss everything in. There is precedent here in the Paste distribution. It has many submodules and does many things, but it comes in the form of a single egg. Yes, you lose the ability to make a bugfix in one subpackage and release it, but IIRC the intent is to trim zope.app down anyway, pushing libraryish things out to top-level or zope.* packages. Issues: - Who's in charge? Whomever you might be, to what extent do you agree/disagree with the above suggestions? If you agree with any, how can I help fix things? - I'm unsure how anybody is able to install Zope 3 right now using eggs, unless there's some fundamental difference in
