What happened to the infrae.subversion and py eggs?
Hi, Sorry, I don't know where best to ask this question, but it is about buildout, so I guess it could be called on-topic on the zope dev list. Since about one day I have problems with buildouts using the infrae.subversion and py eggs. The problem can be seen with a standard buildout. Well, a plone 3 buildout anyway: paster create -t plone3_buildout In the created buildout.cfg I added this section and included it in the parts section: =========================================================== [productcheckouts] recipe = infrae.subversion urls = =========================================================== This does not do anything really, but it should be enough to demonstrate the problem that surfaces when running bin/buildout -v: =========================================================== ... Installing 'infrae.subversion'. We have no distributions for infrae.subversion that satisfies 'infrae.subversion'. Getting distribution for 'infrae.subversion'. Got infrae.subversion 1.0dev-r28201. Picked: infrae.subversion = 1.0dev-r28201 Getting required 'py==0.9.0' required by infrae.subversion 1.0dev-r28201. We have no distributions for py that satisfies 'py==0.9.0'. Getting distribution for 'py==0.9.0'. While: Installing. Getting section productcheckouts. Initializing section productcheckouts. Installing recipe infrae.subversion. Getting distribution for 'py==0.9.0'. Error: Couldn't find a distribution for 'py==0.9.0'. =========================================================== At least, that happens when I do not yet have py-0.9.0-py2.4.egg in my egg cache; no complaints when I already have that one. Has something changed in the py egg? Other explanations for this error? Meanwhile in a virtualenv I can do this without errors: bin/easy_install py==0.9.0 Under the theory that the problem might be caused by the latest version of the infrae.subversion recipe (released a few days ago I think) having a wrong dependency or so, I pin this recipe to a previous version that I know was on the cheeseshop last week as I got it from there: =========================================================== versions = versions [versions] infrae.subversion = 1.0dev-r27844 =========================================================== Then it can't find that version of the egg. Well, my buildout could not find it this afternoon, but of course now the reverse demonstration effect strikes back and it goes fine: =========================================================== Installing 'infrae.subversion'. We have no distributions for infrae.subversion that satisfies 'infrae.subversion==1.0dev-r27844'. Getting distribution for 'infrae.subversion==1.0dev-r27844'. Got infrae.subversion 1.0dev-r27844. Getting required 'py' required by infrae.subversion 1.0dev-r27844. Picked: py = 0.9.1 =========================================================== But this page does not exist: http://pypi.python.org/pypi/infrae.subversion/1.0dev-r27844 and it is not listed here: http://pypi.python.org/simple/infrae.subversion So where does buildout get that egg now? I emptied my egg cache. Luckily for demonstration purposes this at least fails in a virtualenv: =========================================================== $ bin/easy_install infrae.subversion==1.0dev_r27844 Searching for infrae.subversion==1.0dev-r27844 Reading http://pypi.python.org/simple/infrae.subversion/ Reading https://svn.infrae.com/buildout/infrae.buildout/trunk/ No local packages or download links found for infrae.subversion==1.0dev-r27844 error: Could not find suitable distribution for Requirement.parse('infrae.subversion==1.0dev-r27844') =========================================================== So has that version of the egg been removed from the cheeseshop? And can it be brought back? I have buildouts that are pinned to that version for stability and I would like those to work half a year from now (or in fact tomorrow) in case I have to rebuild those buildouts on a new server. You never know when that meteor will hit your data center. ;-) Has anyone else seen this? -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl]
Maurits van Rees wrote: [snip]
Error: Couldn't find a distribution for 'py==0.9.0'. ===========================================================
At least, that happens when I do not yet have py-0.9.0-py2.4.egg in my egg cache; no complaints when I already have that one. Has something changed in the py egg? Other explanations for this error? Meanwhile in a virtualenv I can do this without errors:
I know there was a py 0.9.1 release recently, but you'd think that wouldn't make the old py go away... Hm, there's still a py 0.9 download url available here: http://pypi.python.org/simple/py The one thing I notice is that py-0.9.1 is actually uploaded to the cheeseshop while the older versions were not (just download urls pointing back to the py website). Is it possible that this somehow confused things? If so, it might be worthwhile to contact the py list and ask them to upload py 0.9 as a tarball as well. Regards, Martijn
Maurits van Rees <m.van.rees@zestsoftware.nl> writes:
Luckily for demonstration purposes this at least fails in a virtualenv:
=========================================================== $ bin/easy_install infrae.subversion==1.0dev_r27844 Searching for infrae.subversion==1.0dev-r27844 Reading http://pypi.python.org/simple/infrae.subversion/ Reading https://svn.infrae.com/buildout/infrae.buildout/trunk/ No local packages or download links found for infrae.subversion==1.0dev-r27844 error: Could not find suitable distribution for Requirement.parse('infrae.subversion==1.0dev-r27844') ===========================================================
So has that version of the egg been removed from the cheeseshop? And can it be brought back? I have buildouts that are pinned to that version for stability and I would like those to work half a year from now (or in fact tomorrow) in case I have to rebuild those buildouts on a new server. You never know when that meteor will hit your data center. ;-)
1.0dev-r27844 seems to be gone from PyPI. I'm CCing Sylvain who I believe made the last release. Maybe we can even convince him to make a proper release, not an SVN snapshot. :-) Of course, we should also make sure that the latest version works properly with its pinned py dependency. Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Nouri wrote:
Maurits van Rees <m.van.rees@zestsoftware.nl> writes:
Luckily for demonstration purposes this at least fails in a virtualenv:
=========================================================== $ bin/easy_install infrae.subversion==1.0dev_r27844 Searching for infrae.subversion==1.0dev-r27844 Reading http://pypi.python.org/simple/infrae.subversion/ Reading https://svn.infrae.com/buildout/infrae.buildout/trunk/ No local packages or download links found for infrae.subversion==1.0dev-r27844 error: Could not find suitable distribution for Requirement.parse('infrae.subversion==1.0dev-r27844') ===========================================================
So has that version of the egg been removed from the cheeseshop? And can it be brought back? I have buildouts that are pinned to that version for stability and I would like those to work half a year from now (or in fact tomorrow) in case I have to rebuild those buildouts on a new server. You never know when that meteor will hit your data center. ;-)
1.0dev-r27844 seems to be gone from PyPI.
Such a version should *never* have been "released" to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world). Pushing such distributions out to PyPI, rather than sharing them in a more restricted / private location, induces pain on the wrong parties (those who innocently rely on PiPI, rather than those perpetrating the risky behavior).
I'm CCing Sylvain who I believe made the last release. Maybe we can even convince him to make a proper release, not an SVN snapshot. :-)
Of course, we should also make sure that the latest version works properly with its pinned py dependency.
Amen! 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 iD8DBQFH/B5C+gerLs4ltQ4RAtgwAJ464BsvjmvRqFuMLiuHdtpGIbGlAgCfZ/Pq j56rwm9hVGP3gqp9kdY0LPY= =+90j -----END PGP SIGNATURE-----
--On 8. April 2008 21:39:14 -0400 Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
1.0dev-r27844 seems to be gone from PyPI.
Such a version should *never* have been "released" to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world). Pushing such distributions out to PyPI, rather than sharing them in a more restricted / private location, induces pain on the wrong parties (those who innocently rely on PiPI, rather than those perpetrating the risky behavior).
Amen. Lots of people are misusing PyPI right now for uploading their broken packages: lots of dev-packages in some weird state, packages without metadata, packages without URL, packages with descriptions..that's a pretty big pain in the *** right now. I currently working on the buildout infrastructure for three of our major Zope projects (which lots of externals dependencies) and I am sometimes really annoyed that stuffs works some day and not the other day because packages appearently come and go.
I'm CCing Sylvain who I believe made the last release. Maybe we can even convince him to make a proper release, not an SVN snapshot. :-)
Of course, we should also make sure that the latest version works properly with its pinned py dependency.
Amen!
Also Amen on this. Andreas
Tres Seaver schreef:
Daniel Nouri wrote:
1.0dev-r27844 seems to be gone from PyPI.
Such a version should *never* have been "released" to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world).
I've made it a habit *not* to enable the option in setup.cfg that adds those svn revision numbers to the version. It is enabled by default in all/most of the ZopeSkel-generated packages that I use. That single change forces me to maintain a proper version number in the setup.py ("0.9 dev 3" for development versions). That is the spot where you make a change anyway when doing a release. It is waaaay too easy to forget to remove the subversion revision option from setup.cfg (and having to enable it again after the release). Somehow it helps :-) Reinout -- Reinout van Rees Blog: http://vanrees.org/weblog/ reinout@vanrees.org Work: http://zestsoftware.nl/ http://vanrees.org Video: http://reinout.blip.tv/
Previously Reinout van Rees wrote:
Tres Seaver schreef:
Daniel Nouri wrote:
1.0dev-r27844 seems to be gone from PyPI.
Such a version should *never* have been "released" to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world).
I've made it a habit *not* to enable the option in setup.cfg that adds those svn revision numbers to the version. It is enabled by default in all/most of the ZopeSkel-generated packages that I use.
I recently started adding that option again for some of my projects. For a few frequently updated sites I do a lot of updates & installs without making full releases and it is extremely convenient to be able to see which exact revision number I'm currently using. 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 schreef:
Previously Reinout van Rees wrote:
Tres Seaver schreef:
Daniel Nouri wrote:
1.0dev-r27844 seems to be gone from PyPI. Such a version should *never* have been "released" to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world). I've made it a habit *not* to enable the option in setup.cfg that adds those svn revision numbers to the version. It is enabled by default in all/most of the ZopeSkel-generated packages that I use.
I recently started adding that option again for some of my projects. For a few frequently updated sites I do a lot of updates & installs without making full releases and it is extremely convenient to be able to see which exact revision number I'm currently using.
Those are probably private and not on pypi, I guess? Or do you do that for a few pypi'ed packages, too? I basically don't trust myself enough to enable it for public packages :-) Reinout -- Reinout van Rees Blog: http://vanrees.org/weblog/ reinout@vanrees.org Work: http://zestsoftware.nl/ http://vanrees.org Video: http://reinout.blip.tv/
Previously Reinout van Rees wrote:
Wichert Akkerman schreef:
Previously Reinout van Rees wrote:
Tres Seaver schreef:
Daniel Nouri wrote:
1.0dev-r27844 seems to be gone from PyPI. Such a version should *never* have been "released" to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world). I've made it a habit *not* to enable the option in setup.cfg that adds those svn revision numbers to the version. It is enabled by default in all/most of the ZopeSkel-generated packages that I use.
I recently started adding that option again for some of my projects. For a few frequently updated sites I do a lot of updates & installs without making full releases and it is extremely convenient to be able to see which exact revision number I'm currently using.
Those are probably private and not on pypi, I guess? Or do you do that for a few pypi'ed packages, too? I basically don't trust myself enough to enable it for public packages :-)
I do that frequently for packages which are also on pypi. We do it for all plone.* and plone.app.* packages for example. I just don't upload those dev revisions to pypi. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Reinout van Rees <reinout@vanrees.org> writes:
Tres Seaver schreef:
Daniel Nouri wrote:
1.0dev-r27844 seems to be gone from PyPI.
Such a version should *never* have been "released" to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world).
I've made it a habit *not* to enable the option in setup.cfg that adds those svn revision numbers to the version. It is enabled by default in all/most of the ZopeSkel-generated packages that I use.
That single change forces me to maintain a proper version number in the setup.py ("0.9 dev 3" for development versions). That is the spot where you make a change anyway when doing a release. It is waaaay too easy to forget to remove the subversion revision option from setup.cfg (and having to enable it again after the release).
For making releases, I create a tag and remove the setup.cfg file from that tag. No need to remove it from trunk. Also see [1] and [2]. And I agree with Wichert that for non-public packages, these development snapshot releases can be useful. [1] http://peak.telecommunity.com/DevCenter/setuptools#managing-continuous-relea... [2] http://peak.telecommunity.com/DevCenter/setuptools#making-official-non-snaps... Daniel
participants (7)
-
Andreas Jung -
Daniel Nouri -
Martijn Faassen -
Maurits van Rees -
Reinout van Rees -
Tres Seaver -
Wichert Akkerman