incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hartmann <mailbox....@gmail.com>
Subject Re: (merged) Make SCM tools optional
Date Tue, 13 Nov 2012 20:01:21 GMT
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


Mime
View raw message