-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Poster wrote:
On Dec 9, 2008, at 8:43 AM, Benji York wrote:
On Mon, Dec 8, 2008 at 12:23 PM, Tres Seaver <tseaver@palladion.com> wrote:
Stripping all versions from the dependencies in setup.py only works if users are willing to run their own package indexes, and figure out edge cases such as the ones you describe by themselves: The above claim appears false. Every project (both the open and closed) I work on has virtually no versions in setup.py and we don't use a private package index. We use a version section in the buildout.
buildout is a "ghetto", then. not all the potential users of your package know or care about buildout: they want to be able to use the package in some other setup, e.g., via easy_install. Providing properly documented dependencies makes that possible.
The "virtually" is the catch here. They do have some.
They are typically introduced when an older version of a dependency *does not work with the software*. To me, "does not work" == "breaks tests". Because our community, and others, try for backwards compatibility, this kind of assertion happens relatively rarely.
These setup.py assertions are always, or almost always, not "pinning" but saying "I work with X or better." I'm advocating these sorts of "X or better" assertions.
Christian's zope.testbrowser change fits these characteristics. Do you, or Stephan, or anyone else with your opinions, have some other additional line that must be crossed, or do you assert that setup.py should never have any version numbers?
For instance, if you have a project that requires a newer API in, say, zope.component, do you assert that it is inappropriate to specify a zope.component of "X or better" in your setup.py for that project?
Exactly: I'm not arguing for "pinned" versions for anything other than a "this release exaclty" meta egg (not on the table here). 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 iD8DBQFJPoc0+gerLs4ltQ4RAntDAKCsqNyI3rh/WimR2rmEquch/SCqXQCfS14Q h3z4EhSugpRVXGuWRl1d42g= =Ynyv -----END PGP SIGNATURE-----