You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Cory Johns <jo...@geek.net> on 2012/10/30 15:58:55 UTC
(merged) Make SCM tools optional
Much thanks to Peter Hartmann for his work on
#3883<https://sourceforge.net/p/allura/tickets/3883/>,
his changes <https://sourceforge.net/p/allura/git/merge-requests/9/> have
been merged.
This gets us well on our way to being ready for an Incubator release, as
the SCM tools are now decoupled and can be moved into separate projects to
deal with the licensing issues they raised.
Thanks again, and great work.
- Cory
--
====
This e- mail message is intended only for the named recipient(s) above. It
may contain confidential and privileged information. If you are not the
intended recipient you are hereby notified that any dissemination,
distribution or copying of this e-mail and any attachment(s) is strictly
prohibited. If you have received this e-mail in error, please immediately
notify the sender by replying to this e-mail and delete the message and any
attachment(s) from your system. Thank you.
Re: (merged) Make SCM tools optional
Posted by Dave Brondsema <da...@brondsema.net>.
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 : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: (merged) Make SCM tools optional
Posted by Peter Hartmann <ma...@gmail.com>.
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
Re: (merged) Make SCM tools optional
Posted by Dave Brondsema <da...@brondsema.net>.
On 11/8/12 1:21 PM, Peter Hartmann wrote:
> I did a push today and here's a rationale for some changes I've made to former
> default.
>
> There's now a lil function in version.py that returns version string. Setuptools
> allows for two kind of additional version data: so-called "pre-release tag" and
> "post-release tag". Pre-release tags are default and can work with automatic
> "dev" suffix addition. However, setuptools then assumes a package counts as a
> pre-release of future version. This may work for projects with established
> release schedule, where it is known beforehand what major version number will
> the next version get. Allura seem to rely on continuous release, differentiated
> only by git tags, so the scheme used by version() uses data from git describe as
> a setuptools post-release tag. I've also kept it compatible with maj,min
> versioning scheme, in case it'll be used in the future.
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
>
> 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.
> Finally, I've retained the history of changes from Allura repository - it may be
> useful, even if for future reference only. One side-effect of using git
> filter-branch with --subdirectory-filter was that the output is ForgeHg/*, not
> ForgeHg/ itself. I find it better option in a separate repository, so I've left
> it as is. Should work well within former source tree structure anyways.
Nice. Keeping the history is great.
So what else needs to be done?
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: (merged) Make SCM tools optional
Posted by Peter Hartmann <ma...@gmail.com>.
I did a push today and here's a rationale for some changes I've made to
former default.
There's now a lil function in version.py that returns version string.
Setuptools allows for two kind of additional version data: so-called
"pre-release tag" and "post-release tag". Pre-release tags are default
and can work with automatic "dev" suffix addition. However, setuptools
then assumes a package counts as a pre-release of future version. This
may work for projects with established release schedule, where it is
known beforehand what major version number will the next version get.
Allura seem to rely on continuous release, differentiated only by git
tags, so the scheme used by version() uses data from git describe as a
setuptools post-release tag. I've also kept it compatible with maj,min
versioning scheme, in case it'll be used in the future.
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.
Finally, I've retained the history of changes from Allura repository -
it may be useful, even if for future reference only. One side-effect of
using git filter-branch with --subdirectory-filter was that the output
is ForgeHg/*, not ForgeHg/ itself. I find it better option in a separate
repository, so I've left it as is. Should work well within former source
tree structure anyways.
- Peter
Re: (merged) Make SCM tools optional
Posted by Nicholas Bollweg <ni...@gmail.com>.
Great news, and much applause! Has anyone approached the mercurial guys?
Not sure what relationship apache allura might end up having to
scm-manager, but some kind of joint work seems desirable.
Re: (merged) Make SCM tools optional
Posted by Dave Brondsema <da...@brondsema.net>.
On 10/31/12 2:02 PM, Peter Hartmann wrote:
>> Much thanks to Peter Hartmann for his work on
>> #3883<https://sourceforge.net/p/allura/tickets/3883/>,
>> his changes <https://sourceforge.net/p/allura/git/merge-requests/9/> have
>> been merged.
>>
>> This gets us well on our way to being ready for an Incubator release, as
>> the SCM tools are now decoupled and can be moved into separate projects to
>> deal with the licensing issues they raised.
>>
>> Thanks again, and great work.
>>
>>
>> - Cory
>>
> I'm flattered to see my humble doings being lauded in public like that. An
> undeserved praise compared to all the work you guys are commiting every day, but
> nontheless nice. Thanks for offering me all the help I needed on my first
> contribution and patiently answering my questions on irc.
>
> I will take this opportunity to write a bit on how I think we should handle
> moving the SCM tool in question, ForgeHg, outside the scope of Allura incubation
> project. As https://sourceforge.net/p/allura/tickets/4655/ states, this will
> technically go down the way of creating new project as a sort of distribution
> channel - repository, possibly some tarball release etc. Registering a project
> on SourceForge is something anyone can do, but I think this should be done by
> someone from the core dev team, so that ForgeHg can be kept in line with any
> future changes to Allura's core. As I understand that, ForgeHg won't be
> distributed along Allura anymore and will not be distributed through Apache
> Incubator, but it still remains somewhat of an "official" module, being used on
> SourceForge and all.
>
> The ticket specifically mentions optional installation, so in addition to above,
> I propose to make a pypi release of ForgeHg. Preparing such a release is a task
> when I can actually be useful. It's no rocket science, but it would involve code
> separation, preparing installation routine - with test data, possibly some
> configuration - and testing how it would behave. This looks like nonexciting
> task that I can handle ;) Once finished, I'll push a branch with this tool
> alone, prepared for distribution, and then someone competent would register a
> project and use this branch as repo's basis.
>
That sounds like a good plan, matches how I had been envisioning it. I've
created https://sourceforge.net/p/forgehg/ with you and some of the other active
developers as admins. Feel free to use it whenever. You or any dev here can
set up the pypi package too and add the other devs.
The code separation might be the trickiest part here. Since we are regularly
updating ForgeHg code, we'll want to avoid having a period of time where the
code lives in two places and is confusing. One idea might be that after the
process and any changes are all figured out, then redo the code copy. That way
we'll have a quick painless cutover.
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: (merged) Make SCM tools optional
Posted by Peter Hartmann <ma...@gmail.com>.
> Much thanks to Peter Hartmann for his work on
> #3883<https://sourceforge.net/p/allura/tickets/3883/>,
> his changes <https://sourceforge.net/p/allura/git/merge-requests/9/> have
> been merged.
>
> This gets us well on our way to being ready for an Incubator release, as
> the SCM tools are now decoupled and can be moved into separate projects to
> deal with the licensing issues they raised.
>
> Thanks again, and great work.
>
>
> - Cory
>
I'm flattered to see my humble doings being lauded in public like that.
An undeserved praise compared to all the work you guys are commiting
every day, but nontheless nice. Thanks for offering me all the help I
needed on my first contribution and patiently answering my questions on irc.
I will take this opportunity to write a bit on how I think we should
handle moving the SCM tool in question, ForgeHg, outside the scope of
Allura incubation project. As
https://sourceforge.net/p/allura/tickets/4655/ states, this will
technically go down the way of creating new project as a sort of
distribution channel - repository, possibly some tarball release etc.
Registering a project on SourceForge is something anyone can do, but I
think this should be done by someone from the core dev team, so that
ForgeHg can be kept in line with any future changes to Allura's core. As
I understand that, ForgeHg won't be distributed along Allura anymore and
will not be distributed through Apache Incubator, but it still remains
somewhat of an "official" module, being used on SourceForge and all.
The ticket specifically mentions optional installation, so in addition
to above, I propose to make a pypi release of ForgeHg. Preparing such a
release is a task when I can actually be useful. It's no rocket science,
but it would involve code separation, preparing installation routine -
with test data, possibly some configuration - and testing how it would
behave. This looks like nonexciting task that I can handle ;) Once
finished, I'll push a branch with this tool alone, prepared for
distribution, and then someone competent would register a project and
use this branch as repo's basis.
- Peter