On 11/13/12 3:01 PM, Peter Hartmann wrote: > 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.
Ah, that would be nice. If we can put/pull the info from PKG-INFO also, that sounds great. I agree using git as the source of data is better than a timestamp version, as long as we can make installation work. >> 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. > And delete ForgeHg from the Allura repo :) We have some current ForgeHg changes for https://sourceforge.net/p/allura/tickets/5037/ in a branch 42cc_5037 which will be landing soon. We might want to wait for that, and then ask you to re-run git filter-branch to create the ForgeHg repo again. -- Dave Brondsema : [email protected] http://www.brondsema.net : personal http://www.splike.com : programming <><
