Running Kallithea on Windows
Mads Kiilerich
mads at kiilerich.com
Wed Feb 10 16:45:28 UTC 2016
On 02/10/2016 12:29 AM, Angel Ezquerra wrote:
> No, we never use hardcoded URLs AFAIK. We follow the recommended
> practice of only using simple, relative subrepository references (i.e.
> such as my/subrepo/path = my/subrepo/path). If someone is not doing
> that they would have to fix it.
I would suggest to do that mapping with URL rewrites / aliases /
redirects in the web server instead of in the file system.
It would be nice it Kallithea had a feature to remember "previous names"
of repositories. So that if a repository is moved, it is still available
on the old name. (Trying to replace it with a new repo should give a
warning.) If we had that feature, it could perhaps also be used to
create "aliases" you can use for this.
>>> So now the questions:
>>>
>>> 1. Is it possible to configure Kallithea as a "code review" only tool,
>>> disabling both push and, above all, pull access?
>> If you want to that as 'configuration' only, I would do it by configuring
>> filter in the web server.
> I don't understand what you mean. Could you please elaborate, please?
Configure your web server so it allows browser requests but block
everything that Kallithea will recognize as protocol requests. See
kallithea/lib/middleware/simplehg.py is_mercurial.
>> I would probably prefer to have a local code customization that disable
>> protocol access.
> I'm not sure what you mean here either. Do you mean that you'd like to
> have some way to configure Kallithea as a code review only told from
> the Kallithea UI, but that it is not currently possible to do so?
I guess that ultimately it would be nice to have a very fine grained
access control system where this could be controlled. Right now I don't
think it would fit in nicely as general feature.
As an easy solution for now, I suggest just hardcoding it - for example
by letting is_mercurial return False.
>>> 2. How well does Kallithea support subrepos? It seems that Kallithea
>>> does not find subrepos when it scans for repositories, but maybe I
>>> missed something...
>> There is a small snippet on
>> http://kallithea.readthedocs.org/en/latest/usage/vcs_support.html#working-with-mercurial-subrepositories
>> - but it doesn't say much.
> No, it does not say much. Is it true that Kallithea will not show
> subrepos on the repository list?
Yes. It doesn't know about it as subrepos (like hgweb).
It also ensures that you don't get repos under repos and that URLs thus
are (quite) unambiguous (not like hgweb).
However, if you map the subrepos into the URL namespace with web server
URL rewriting as mentioned above, you don't really need Kallithea to
know about the subrepos as subrepos.
(All this URL rewriting could of course also be done with some simple
WSGI middleware ... or be built into Kallithea as a general feature. But
as you know, subrepos can appear at different locations in different top
repo locations so it is hard to make a generic solution - it will have
to rely on some assumptions.)
>> I don't know 'mercurial server' (and I hate the name for being so
>> misleading).
> When I say "mercurial server" I mean our hgweb instance that is served
> by apache.
Heh - so this-product-that-shall-not-be-mentioned did harm the
discussion even though not directly involved ;-)
> The thing that worries me is what would happen if we manually modified
> some of the html templates and then used pip to update to a newer
> Kallithea version... That is why we used web.MOTD to add our banner,
> rather than modifying an existing hgweb template (we could have
> created a new one, but I was lazy at the time :-P).
This is Python and you are a Mercurial expert. I would suggest running
out of clone (with 'setup.py develop') where you can have your own
patches on top of upstream. That will give you full control. That is how
we do.
>> What do you mean with "raw Kallithea"? The development standalone web
>> server?
> I meant Kallithea when run directly, without using apache or IIS or similar.
There is no "kallithea directly". Kallithea is a wsgi application. It
needs a web server to run.
http://docs.kallithea-scm.org/en/latest/overview.html#web-server
/Mads
More information about the kallithea-general
mailing list