On 13.11.2012 19:07, Dave Brondsema wrote:
I'm looking at
https://sourceforge.net/p/forgehg/code/ci/214820d7f555c8ac2e99a469778928664306d3a2/tree/forgehg/version.py
and it seems that this would require the package to be installed from git. What
if ForgeHg were installed without using git? E.g. I think 'python setup.py
install' would copy the files and not the git info. In SourceForge's deployment
scheme, we always deploy packages via specific tarballs (created by 'python
setup.py sdist' if needed) not live from git.
While Allura currently doesn't get any version info, almost all the packages it
depends on do. I think it would be useful to have ForgeHg and any other
libraries have version numbers and not rely & depend on a git working dir.
There are several libraries, like Ming, that we could use as a reference. There
are rarely major version number changes to Ming, but we make many releases and
just bump the date on. You can see them here:http://pypi.python.org/pypi/Ming
I think something like that would be good for ForgeHg. Ming's setup.cfg which
controls that is at
https://sourceforge.net/p/merciless/code/ci/2c204153d7a6c4db43354c59b50977d8be674c59/tree/setup.cfg
You're right about installing - I thought package metadata (PKG-INFO
file) would take care of this, but seems like it's not getting used at
all when installing a package. Well, this can be fixed of course and I
think using git data has it's merits: it actually recognizes different
versions - as in, different commits in HEAD - and points to a specific
commit, while using day makes version a bit more vague - if someone will
build a package himself it won't be seen as different by Python
packaging tools, either from packages made since last version bump or on
same day if we automate it, even though it would possibly contain
newer/older commits.
Ming's versioning is an example of "pre-release tag". With this kind of
naming scheme, setuptools determines that i.e. Ming 0.3.2dev-20121101 is
older version than Ming 0.3.2, if it encounters such. Just want to make
implications clear: going with pre-release tags would mean that we
either a) won't ever release a package with "stable" version number when
earlier "dev" versions used it already, or b) establish very carefully
future versioning roadmap, so that we will know version numbers in
advance and make dev-tagged versions count towards it. The latter seems
unlikely, the former seems unnecessarily limiting and troublesome, but
it's my personal opinion. If you deem it fine, then so be it :)
Tests seem to work out of former source tree. The only thing needed is some
adjustment of paths in test.ini. I came to a thought that this should be
explained, and ended up writing a full README adding this and a bunch of other
info. It may require some grammar fixes, as I'm not a native english writer. I
used reStructuredText, even though Allura uses Markdown, because PyPI expects
reST readmes. I may add reST support to Allura later, or if it's already there -
some kind of heuristics.
Cool. Docs is something we are short on :) Allura should be able to render
reST docs. It uses the "pypeline" to handle several types of plain text
formatting. But it requires a file extension, no heuristics currently.
Yes, and in turn - Python distutils wants file named README or
README.txt. It only outputs a warning, but you know... Trying to follow
convention here ;) Anyways, Allura would benefit from this sort of
heuristics too.
So what else needs to be done?
PyPI release :) I just wanted to consult here on the relevant changes. I
admit they're minor in terms of code, but i.e. versioning scheme would
be somewhat established as a practice when used for release.
- Peter
