Hi All, Why does the egg in the subject line exist and why does buildout pick it over a stable release? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Okay, So I bumped into the ZODB3 3.9.0-dev-r77011 problem while trying to get going with zopeproject. zopeproject created a buildout.cfg in my test project, so I thought I'd lock ZODB to 3.8.0 to prevent problems: [buildout] develop = . parts = app test find-links = http://download.zope.org/distribution/ newest = false eggs-directory = C:\Zope\buildout-eggs [app] recipe = zc.recipe.egg eggs = HelloWorld zope.app.apidoc zope.app.securitypolicy z3c.evalexception>=2.0 Paste PasteScript PasteDeploy interpreter = python [versions] ZODB3 = 3.8.0 [test] recipe = zc.recipe.testrunner eggs = HelloWorld defaults = ['--tests-pattern', '^f?tests$', '-v'] This didn't work, buildout still tries to install 3.9.0-dev-r77011. Why?! I also noticed that buildout from this .cfg doesn't seem to use the latest versions of things. It's only using version 1.0.7 of zc.buildout, not the 1.1.0 I'd expect. Now, my understanding is that find-links adds to the index rather than replaces it, so what's going on here? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Previously Chris Withers wrote:
Okay,
So I bumped into the ZODB3 3.9.0-dev-r77011 problem while trying to get going with zopeproject.
zopeproject created a buildout.cfg in my test project, so I thought I'd lock ZODB to 3.8.0 to prevent problems:
[buildout] develop = . parts = app test find-links = http://download.zope.org/distribution/ newest = false eggs-directory = C:\Zope\buildout-eggs
You are missing a line here: versions = versions Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
You are missing a line here:
versions = versions
Good catch! Seems to be working now... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Okay,
So I bumped into the ZODB3 3.9.0-dev-r77011 problem while trying to get going with zopeproject.
zopeproject created a buildout.cfg in my test project, so I thought I'd lock ZODB to 3.8.0 to prevent problems:
[buildout] develop = . parts = app test find-links = http://download.zope.org/distribution/ newest = false eggs-directory = C:\Zope\buildout-eggs
[app] recipe = zc.recipe.egg eggs = HelloWorld zope.app.apidoc zope.app.securitypolicy z3c.evalexception>=2.0 Paste PasteScript PasteDeploy interpreter = python
[versions] ZODB3 = 3.8.0
[test] recipe = zc.recipe.testrunner eggs = HelloWorld defaults = ['--tests-pattern', '^f?tests$', '-v']
This didn't work, buildout still tries to install 3.9.0-dev-r77011. Why?!
Because you're not doing it right. You invented a [versions] section but you still need to tell buildout to actually use that section as a versions declarations: [buildout] ... versions = versions http://pypi.python.org/pypi/zc.buildout#repeatable-buildouts-controlling-egg...
I also noticed that buildout from this .cfg doesn't seem to use the latest versions of things. It's only using version 1.0.7 of zc.buildout, not the 1.1.0 I'd expect.
Because it's running in non-newest mode (newest = false in [buildout]). bin/buildout -n will override that setting from the command line and run it in newest mode. http://pypi.python.org/pypi/zc.buildout#newest-and-offline-modes
Now, my understanding is that find-links adds to the index rather than replaces it, so what's going on here?
This has nothing to do with it.
Philipp von Weitershausen <philipp@weitershausen.de> writes:
[versions] ZODB3 = 3.8.0 ... This didn't work, buildout still tries to install 3.9.0-dev-r77011. Why?!
Because you're not doing it right. You invented a [versions] section but you still need to tell buildout to actually use that section as a versions declarations:
[buildout] ... versions = versions
Should we write something like Grok for buildout, so that it just uses sections without having to have them doubly declared up at the top? :-) -- Brandon Craig Rhodes brandon@rhodesmill.org http://rhodesmill.org/brandon
Brandon Craig Rhodes wrote:
Should we write something like Grok for buildout, so that it just uses sections without having to have them doubly declared up at the top? :-)
I think it's kind of funny that the Zope project chose XML (a hierarchical format) for ZCML (which is fairly flat), then chose INI format (which is mostly flat) for build configuration (which usually ends up hierarchical). :-) Shane
Brandon Craig Rhodes wrote:
[buildout] ... versions = versions
Should we write something like Grok for buildout, so that it just uses sections without having to have them doubly declared up at the top? :-)
Heh, nah, this was a fair cop. I *did* actually know about this, was just a silly bug in my buildout... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Why does the egg in the subject line exist
Because somebody made it and uploaded it to download.zope.org. It probably happened during the initial eggification period when we didn't have a solid release process [1].
and why does buildout pick it over a stable release?
Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer-stable option so that you can tell it to prefer stable over alpha/beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list. [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-softwar... [2] http://download.zope.org/zope3.4/versions.cfg
Philipp von Weitershausen wrote:
and why does buildout pick it over a stable release?
Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer-stable option so that you can tell it to prefer stable over alpha/beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list.
Okay, so how come zopeproject doesn't do any of these? I don't even know how to use the KGS - where would I find docs on that? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
El 19 Aug 2008, a las 12:05 , Chris Withers escribió:
Philipp von Weitershausen wrote:
and why does buildout pick it over a stable release? Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer- stable option so that you can tell it to prefer stable over alpha/ beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list.
Okay, so how come zopeproject doesn't do any of these?
Because I haven't bothered to update it yet.
I don't even know how to use the KGS - where would I find docs on that?
It's just the standard buildout-extension feature that you can use to pull in a versions list from the web, e.g. the one I just pasted you in my previous email: [buildout] ... extends = http://download.zope.org/zope3.4/versions.cfg versions = versions See http://pypi.python.org/pypi/zc.buildout#multiple-configuration- files. Of course you could also just download the file and add it to your buildout.cfg verbatimly.
Chris Withers a écrit :
Philipp von Weitershausen wrote:
and why does buildout pick it over a stable release? Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer-stable option so that you can tell it to prefer stable over alpha/beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list.
Okay, so how come zopeproject doesn't do any of these?
I don't even know how to use the KGS - where would I find docs on that?
Here is a page explaining it: http://download.zope.org/zope3.4/intro.html
cheers,
Chris
Christophe Combelles wrote:
I don't even know how to use the KGS - where would I find docs on that?
Here is a page explaining it: http://download.zope.org/zope3.4/intro.html
Thanks, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Philipp von Weitershausen wrote:
and why does buildout pick it over a stable release? Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer-stable option so that you can tell it to prefer stable over alpha/beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list.
Okay, so how come zopeproject doesn't do any of these?
I don't even know how to use the KGS - where would I find docs on that?
The Grok project actually make this stuff (pinning down versions, etc) easy. If you want this to work out of the box, Zope 3 isn't the best way to go. You install grokproject and it ought to just work. If not, let us know. Regards, Martijn
Martijn Faassen wrote:
The Grok project actually make this stuff (pinning down versions, etc) easy.
How does it do this?
If you want this to work out of the box, Zope 3 isn't the best way to go. You install grokproject and it ought to just work. If not, let us know.
Yes, but grok is another framework. I just wanted to get the minimum "Zope 3" stuff up and running so I could test a view. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi there, On Fri, Aug 22, 2008 at 4:03 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Martijn Faassen wrote:
The Grok project actually make this stuff (pinning down versions, etc) easy.
How does it do this?
It has a tool similar to zopeproject called 'grokproject' to help set up the buildout, which is described on grok.zope.org in multiple places. We make sure we nail down a versions list that we have per release of Grok and is automatically downloaded for you. We take a lot of care that grokproject works. That doesn't mean it's perfect, but it's likely to actually make a sensible install for people without them having to worry too much about various details.
If you want this to work out of the box, Zope 3 isn't the best way to go. You install grokproject and it ought to just work. If not, let us know.
Yes, but grok is another framework. I just wanted to get the minimum "Zope 3" stuff up and running so I could test a view.
Grok includes Zope 3 (and is just a few extra packages). You can do all your ZCML-related testing of Zope 3 stuff with Grok just fine. Grok is probably the easiest way to get Zope 3 installed. In fact you don't have to write any grok-related code whatsoever in your Grok project - throw away the one .py and .pt that Grok project generates and just keep your configure.zcml. The only thing that is different is that Grok's publication turns off some Zope 3 security proxies, so you don't have to declare security for your classes. (eventually we will probably gain something like this back in some fashion). This actually probably makes more testing easier, not harder. :) Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
Chris Withers wrote:
Why does the egg in the subject line exist
Because somebody made it and uploaded it to download.zope.org. It probably happened during the initial eggification period when we didn't have a solid release process [1].
$ ls -latr /distribution/ZODB3-3.9* - -rw-r--r-- 1 gary gary 785678 Jun 24 2007 \ /distribution/ZODB3-3.9.0-dev-r77011.tar.gz
and why does buildout pick it over a stable release?
Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer-stable option so that you can tell it to prefer stable over alpha/beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list.
Uploading non-releases like this to public index locations has *got* to stop. Frankly, they should all be removed: anybody who is depending on them needs to run their own index. 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 iD8DBQFIqvtL+gerLs4ltQ4RAsPuAJ4i+n/6Shupj0YTiZxlr36iUda1sACeP3g4 cuoyPGjrL2LmJ4CzdxqbQ/k= =a+SJ -----END PGP SIGNATURE-----
--On 19. August 2008 12:56:43 -0400 Tres Seaver <tseaver@palladion.com> wrote:
and why does buildout pick it over a stable release?
Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer-stable option so that you can tell it to prefer stable over alpha/beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list.
Uploading non-releases like this to public index locations has *got* to stop. Frankly, they should all be removed: anybody who is depending on them needs to run their own index.
+oo Package sanity and package hygiene is the most important issue of PyPI right now. PyPI requires a strong policy in order to keep PypI possible: no uploading of development releases, no uploading for packages without a minimum set of metadata. PyPI has become a data toilet - unfortunately it is often hard to convinced people that their package uploads without metadata are crap. Andreas
On Aug 19, 2008, at 1:05 PM, Andreas Jung wrote:
--On 19. August 2008 12:56:43 -0400 Tres Seaver <tseaver@palladion.com> wrote:
and why does buildout pick it over a stable release?
Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer- stable option so that you can tell it to prefer stable over alpha/beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list.
Uploading non-releases like this to public index locations has *got* to stop. Frankly, they should all be removed: anybody who is depending on them needs to run their own index.
+oo
Package sanity and package hygiene is the most important issue of PyPI right now. PyPI requires a strong policy in order to keep PypI possible: no uploading of development releases, no uploading for packages without a minimum set of metadata. PyPI has become a data toilet - unfortunately it is often hard to convinced people that their package uploads without metadata are crap.
This wasn't PyPI, this was download.zope.org/distribution. I think it's time to phase that location out. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
Package sanity and package hygiene is the most important issue of PyPI right now. PyPI requires a strong policy in order to keep PypI possible: no uploading of development releases, no uploading for packages without a minimum set of metadata. PyPI has become a data toilet - unfortunately it is often hard to convinced people that their package uploads without metadata are crap.
This wasn't PyPI, this was download.zope.org/distribution.
Yeah, but PyPI is just as bad...
I think it's time to phase that location out.
Indeed. How do we go about doing this? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Andreas Jung wrote:
a minimum set of metadata. PyPI has become a data toilet - unfortunately it is often hard to convinced people that their package uploads without metadata are crap.
It would be really handy if PyPI allowed people to rate and comment on packages. Sadly, they're too busy implementing feature they want rather than those that would help real problems like these :-( Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Tres Seaver wrote:
Uploading non-releases like this to public index locations has *got* to stop. Frankly, they should all be removed: anybody who is depending on them needs to run their own index.
+ sys.maxint... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Aug 19, 2008, at 5:30 AM, Chris Withers wrote:
Hi All,
Why does the egg in the subject line exist
Because someone saw fit to release it. It's on download.zope.org/ distribution. It''s not in PyPI.
and why does buildout pick it over a stable release?
Because, like setuptools, it wants the newest release by default. You can use the prefer-final buildout option: [buildout] prefer-final = true ... to have buildout prefer final releases. Jim -- Jim Fulton Zope Corporation
participants (10)
-
Andreas Jung -
Brandon Craig Rhodes -
Chris Withers -
Christophe Combelles -
Jim Fulton -
Martijn Faassen -
Philipp von Weitershausen -
Shane Hathaway -
Tres Seaver -
Wichert Akkerman