Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 394375 - dev-vcs/rhodecode - Mercurial repository browser/management with build in push/pull server and full text search
Summary: dev-vcs/rhodecode - Mercurial repository browser/management with build in pus...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Default Assignee for New Packages
Depends on:
Reported: 2011-12-11 20:50 UTC by Fabio Bonfante
Modified: 2015-03-08 00:11 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Fabio Bonfante 2011-12-11 20:50:56 UTC
Mercurial repository browser/management with build in push/pull server and full text search
Comment 1 Christoph Junghans (RETIRED) gentoo-dev 2012-02-05 02:46:01 UTC
@Rafael: Can you take it? (You are the mercurial expert.)
Comment 2 Rafael Martins (RETIRED) gentoo-dev 2012-02-09 21:44:41 UTC
(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.

Comment 3 Fabio Bonfante 2012-02-11 10:49:46 UTC
Sorry... no ebuild... :p
Comment 4 Daniel Neugebauer 2012-08-05 19:35:31 UTC
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: (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.
Comment 5 Christoph Junghans (RETIRED) gentoo-dev 2012-12-31 19:01:46 UTC

looks like we should not package it.
Comment 6 Daniel Neugebauer 2013-01-01 12:50:33 UTC
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).
Comment 7 Fabio Bonfante 2013-01-29 16:31:11 UTC
are we so lucky that there's a way to drive a virtualenv installation through an ebuild?
Comment 8 Christoph Junghans (RETIRED) gentoo-dev 2015-03-08 00:11:22 UTC
rhodecode isn't anymore, use kallithea ( instead.