Re: [Zope-dev] Re: bad "zope.size" to remove from PyPI
Aaron Lehmann wrote: If the buildout is nailed to that version or above, and there is none, it breaks. Well, "breaks" is good, but hopefully that means "gives an error message along the lines of '''you specified version 'x.y.z' which could not be found'''". Is that what happens or do you just get some obscure random exception? Worse, if someone now adds another egg of the same version, but consumers have cached a version, their buildout won't download it, because it will already have that version in cache. That's only in case of re-use of an exact version number, right? Of course, PyPI should store MD5s for packages and buildout should use them :-( Yes, mistakes happen. What Benji is saying is that deletion is not the right way to remedy them, as unintuitive as that may seem. ...and I'm saying I don't agree... cheers, 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 )
Re: [Zope-dev] Re: bad "zope.size" to remove from PyPI
On Aug 4, 2008, at 12:37 AM, Aaron Lehmann wrote: On Aug 2, 2008, at 11:45 AM, Chris Withers wrote: Benji York wrote: In case anybody's wondering how this complies with our "no removal of any release whatsoever" policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). Still, it's likely that someone was using it and their buildouts are now broken. We should have instead generated a proper release with a higher version number and left the dev release alone. This is silly. Mistakes happen. Buildout and/or setuptools should be tolerant of accidental releases that are then removed from PyPI. What currently happens in cases like this? If the buildout is nailed to that version or above, and there is none, it breaks. Worse, if someone now adds another egg of the same version, but consumers have cached a version, their buildout won't download it, because it will already have that version in cache. I realize that this particular compound error is unlikely to happen in this instance, but the principle holds. Yes, mistakes happen. What Benji is saying is that deletion is not the right way to remedy them, as unintuitive as that may seem. I do agree that easy_install behavior is pretty insane wrt preferring dev releases over stable "old" releases. But I think it's pretty reasonable to delete accidental releases, whatever the behavior of setuptools/easy_install/buildout. In the first case you mention where "buildout is nailed to that version or above", that would have to be in error, as the release shouldn't have been made in the first place. That also seems true of the second case, but I suppose the difference is the offended person is more innocent there: they should likely contact the person who released it and ask them to not do that again. - C ___ 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] Re: bad "zope.size" to remove from PyPI
On Aug 2, 2008, at 11:45 AM, Chris Withers wrote: Benji York wrote: In case anybody's wondering how this complies with our "no removal of any release whatsoever" policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). Still, it's likely that someone was using it and their buildouts are now broken. We should have instead generated a proper release with a higher version number and left the dev release alone. This is silly. Mistakes happen. Buildout and/or setuptools should be tolerant of accidental releases that are then removed from PyPI. What currently happens in cases like this? If the buildout is nailed to that version or above, and there is none, it breaks. Worse, if someone now adds another egg of the same version, but consumers have cached a version, their buildout won't download it, because it will already have that version in cache. I realize that this particular compound error is unlikely to happen in this instance, but the principle holds. Yes, mistakes happen. What Benji is saying is that deletion is not the right way to remedy them, as unintuitive as that may seem. Aaron Lehmann ___ 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] Re: bad "zope.size" to remove from PyPI
On Sat, Aug 02, 2008 at 05:23:14PM -0400, Fred Drake wrote:
> On Sat, Aug 2, 2008 at 9:27 AM, Benji York <[EMAIL PROTECTED]> wrote:
> > Still, it's likely that someone was using it and their buildouts are now
> > broken. We should have instead generated a proper release with a higher
> > version number and left the dev release alone.
>
> Yes.
>
> It would be even better if PyPI refused registrations of dev versions.
That would be good.
What I don't understand about this thread is why 3.4dev was "newer"
than 3.4.0. Doesn't PyPi use the same versioning rules as setuptools?
$ python
Python 2.5.2 (r252:60911, Jul 20 2008, 01:20:16)
[GCC 4.1.2 (Gentoo 4.1.2 p1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
f>>> from pkg_resources import parse_version
>>> parse_version('3.4dev-r73090') < parse_version('3.4.0')
True
So what exactly was the problem?
--
Paul Winkler
http://www.slinkp.com
___
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] Re: bad "zope.size" to remove from PyPI
On Sat, Aug 2, 2008 at 9:27 AM, Benji York <[EMAIL PROTECTED]> wrote: > Still, it's likely that someone was using it and their buildouts are now > broken. We should have instead generated a proper release with a higher > version number and left the dev release alone. Yes. It would be even better if PyPI refused registrations of dev versions. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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: bad "zope.size" to remove from PyPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > El 2 Aug 2008, a las 17:45 , Chris Withers escribió: >> Benji York wrote: In case anybody's wondering how this complies with our "no removal of any release whatsoever" policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). >>> Still, it's likely that someone was using it and their buildouts >>> are now >>> broken. We should have instead generated a proper release with a >>> higher >>> version number and left the dev release alone. >> This is silly. >> >> Mistakes happen. Buildout and/or setuptools should be tolerant of >> accidental releases that are then removed from PyPI. >> >> What currently happens in cases like this? > > Nothing. It's only a problem if somebody pinned zope.size version to > 3.4dev-r73090 in their buildout.cfg. But that's their own fault IMHO > because it's clearly not a release. We ought to look at yanking PyPI privileges for anybody who is pushing such eggs out. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] 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 iD8DBQFIlLRY+gerLs4ltQ4RAieGAKDaDX6HX+xZZMA4sVGX6YbpoCVFLQCfW5gY 4AZZlvIHyyTx2uGZvJrYp8E= =WSJT -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 )
Re: [Zope-dev] Re: bad "zope.size" to remove from PyPI
El 2 Aug 2008, a las 17:45 , Chris Withers escribió: Benji York wrote: In case anybody's wondering how this complies with our "no removal of any release whatsoever" policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). Still, it's likely that someone was using it and their buildouts are now broken. We should have instead generated a proper release with a higher version number and left the dev release alone. This is silly. Mistakes happen. Buildout and/or setuptools should be tolerant of accidental releases that are then removed from PyPI. What currently happens in cases like this? Nothing. It's only a problem if somebody pinned zope.size version to 3.4dev-r73090 in their buildout.cfg. But that's their own fault IMHO because it's clearly not a release.___ 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] Re: bad "zope.size" to remove from PyPI
Benji York wrote: In case anybody's wondering how this complies with our "no removal of any release whatsoever" policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). Still, it's likely that someone was using it and their buildouts are now broken. We should have instead generated a proper release with a higher version number and left the dev release alone. This is silly. Mistakes happen. Buildout and/or setuptools should be tolerant of accidental releases that are then removed from PyPI. What currently happens in cases like this? cheers, 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 )
Re: [Zope-dev] Re: bad "zope.size" to remove from PyPI
On Fri, Aug 1, 2008 at 7:03 PM, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > Christophe Combelles wrote: >> >> could someone remove this package from the PyPI : >> http://pypi.python.org/pypi/zope.size/3.4dev-r73090 >> >> This is an empty development version, considered more recent by PyPI than >> the latest released version 3.4.0. (which is r78211) > > Done. > > In case anybody's wondering how this complies with our "no removal of any > release whatsoever" policy [1], be assured that a 3.4dev-r73090 thing isn't > a release by our standards. This version number not only contains the 'dev' > marker, meaning it must have come from a development branch (possibly the > trunk), it also contains the -rXXX suffix meaning it was made right from a > subversion checkout without having created a tags first (why else would you > want to include the revision number). Still, it's likely that someone was using it and their buildouts are now broken. We should have instead generated a proper release with a higher version number and left the dev release alone. -- Benji York Senior Software Engineer Zope Corporation ___ 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: bad "zope.size" to remove from PyPI
Christophe Combelles wrote: could someone remove this package from the PyPI : http://pypi.python.org/pypi/zope.size/3.4dev-r73090 This is an empty development version, considered more recent by PyPI than the latest released version 3.4.0. (which is r78211) Done. In case anybody's wondering how this complies with our "no removal of any release whatsoever" policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt ___ 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 )
