Mercurial repository browser/management with build in push/pull server and full text search
@Rafael: Can you take it? (You are the mercurial expert.)
(In reply to comment #1)
> @Rafael: Can you take it? (You are the mercurial expert.)
I'm not exactly the mercurial expert, but I can take it, yes. :)
@Fabio: if you have an ebuild, attach it here, please. If not, I'll prepare one soon.
Sorry... no ebuild... :p
I have written an ebuild but you may prefer to install to a virtual environment as described in the RhodeCode documentation instead. RhodeCode requires a lot of older dependencies with hard version numbers coded into the app. Usually, easy_install or pip would take care of installing "slotted" dependencies outside portage but if you are using ebuilds you often get only one version at a time which is likely to conflict with other tools/webapps written in Python. If it were to be included into the official portage tree, I would expect all dependencies to become slotted first.
If you want to install via portage nevertheless (to keep /usr/lib/python2.7/site-packages managed by portage), add our repository overlay manually via layman:
There, you can also find a short description of all ebuilds that are required as dependencies and not currently in portage. I don't think my ebuilds match the quality needed for inclusion into official portage tree (especially not those for the dependencies), but of course you are free to correct and use them.
At the moment, my RhodeCode ebuild has only been tested with two installations and only Mercurial hosting but I'm open for any feedback under the email address provided at the overlay website.
The overlay repository resides and can be browsed at: http://rhodecode.megacoffee.net/gentoo-overlay/main (yes, that RhodeCode instance is one of the tested installations mentioned ;) )
Since those ebuilds are written and maintained off-site, please don't use this bug report for comments unless they are considered for inclusion or the Gentoo Devs say different. Please contact me directly instead.
looks like we should not package it.
Latest version is now 1.5.1 but I didn't write another ebuild after 1.3.6 yet. Dependencies hadn't improved in 1.4, so for a more recent installation I switched from my own ebuild to the virtualenv setup described in the documentation. Not having all those dependencies available as slotted ebuilds really makes collisions very likely to occur, whereas installation via virtualenv stores them (duplicated) at another location that's not being used by the default Python environment.
I thought about rewriting my ebuild to automate setup and maintenance of such a virtualenv installation instead. If there is a need to use ebuild dependencies (which I don't see much reason for) then those dependencies and the installation method could be triggered by unsetting a "virtualenv" use flag on that ebuild.
However, building/maintaining such a long dependency list on the ebuilds takes some time, so I wouldn't recommend doing it unless there is a good reason to do so - at least I couldn't get the automated ways to generate such ebuilds to work, so I generated that list using grep and trial & error until I covered all dependencies that were reported missing on a system that didn't have any special Python packages installed before.
TL;DR: virtualenv really is the preferred way to install RhodeCode and I wouldn't use my own ebuild any more as it is too hard to maintain (and causes collision issues).
are we so lucky that there's a way to drive a virtualenv installation through an ebuild?
rhodecode isn't anymore, use kallithea (https://kallithea-scm.org/) instead.