On Sat, Nov 7, 2009 at 4:56 PM, Andreas Jung <lists@zopyx.com> wrote: [..]
Do we need/want development on PyPI? At least not me.
MAJOR.MINOR.MICRO.PICO + |a-c]1..N
should be good enough.
PEP 386 is about providing the version scheme so we can compare versions in Distutils when we want to know if a dependency is met (like what setuptools does). So its wider than PyPI : people need to be able to compare development versions as well. So for example, zc.buildout can rely on it for your daily work. [...]
"community" does not imply that we can not agree on certain rules and standards for PyPI - otherwise PyPI remains as it sometimes appears - an unflashed package toilet. Python as a quality programming language needs a package repository with some minimum standards - I completely disagree with "community" as a synonym for "we must make everyone happy".
But the philosophy of Python is to provide a multi-paradigm language I think, without forcing any strong rule like this. (unlike Java I guess) My mother (sorry that's the example I have in my mind) is using Python in her university math /statistics lab, and they don't really care about QA. But she might push her software at PyPI one day. She won't if its rejected because she doesn't follow a version scheme, or push a binary release rather than a source one. Its good too have industrial-strength conventions, so we can build industrial-level applications, but I think we need to be careful about the ticket entry for PyPI. Wouldn't be better to set these enforcements in subcommunity like plone.org where it would make a lot of sense to enforce QA for plone packages ? (plone.org has PyPI support) Tarek