Put this in your local_settings file (click the little ‘View Source’ icon in the upper right to easily cut & paste):

import re
def show_toolbar(request):
    uri = request.get_full_path()
    if re.match(r'/admin/', uri):
        return False
    return True

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': show_toolbar
}

In general, I find both environments to be mostly the same, as far as Python development is concerned. Mostly the same that is, except that virtualenvwrapper isn’t available on windows.

If you’re not familiar with virtualenvwrapper, it is a brilliant shell script that makes virtualenv super easy to work with. I highly recommend it (except of course if you’re on Windows)

One of the best things about virtualenvwrapper is it lets you quickly and easily activate any available virtualenv with the `workon` command.

$ workon virtualenv_name

(virtualenv_name)/path/to/project/dir/$

Not only does it activate the environment, but it will also automatically ‘cd’ you to the project’s working directory. You have to set the up manually but it is super simple, just add the ‘cd’ command to the ‘postactivate’ hook that virtualenvwrapper sets up in the virtualenv’s directory.

So, no virtualenvwrapper for Windows, but there are other ways to get a command shell which is already good to go for a given project.

In fact, it only takes a simple shortcut to cmd.exe with a few arguments. Create a new shortcut using the right-click context menu, then set

• Target: %windir%\system32\cmd.exe /k “c:\path\to\env\Scripts\activate”
• Start In: c:\path\to\project\dir

The /k switch runs the activate script in the same shell, instead of starting a new shell.

Activate and cd to your project

Another approach is to simply create a batch script on your path, which first cd’s to the project directory, then runs the activate script. I personally prefer the shortcut approach, but both are effective.

If you’re using Console2, you have two options. You can use the same approach as above, just replace the path to cmd.exe in your shortcut or batch script with the path to your Console2.exe.

Console2 also lets you define tabs for quickly opening a desired environment. In Edit > Settings > Tabs, click Add:

Console 2 Edit > Settings > Tabs

There is a slight twist – you need to specify an executable in the shell argument, you can’t just put the path to the activate script or you’ll get an error.

Our goal here is to host as many repositories as we’d like, but only allow client access on a per-repository basis. If I set up repository A for client A, I don’t want client A to be able to pull from repository B.

Let’s start by describing our starting point. . All of the tutorials I’ve found get you set up with something like this. We’ve installed mercurial somewhere, and copied the hgwebdir.cgi file to our webroot, and configured it with a hgweb.config file.

Also, there is an .htaccess file at the web root that both limits POST and PUT access to users specified in a password file .htpasswd, which is made with the htpasswd command.

# .htaccess file at webroot
Options +ExecCGI
RewriteEngine On
# / for root directory; specify a complete path from / for others
RewriteBase /
RewriteRule ^$ hgwebdir.cgi  [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) hgwebdir.cgi/$1  [QSA,L]

AuthType Basic
AuthName My Hg Repositories
AuthUserFile /path/to/webroot/.htpasswd
<Limit POST PUT>
Require valid-user
</Limit>

The first portion routes all requests through the hgwebdir.cgi script, unless the request is for an existing file.

What we’re interested in is the second part. The tutorials go into the details, but in summary what is happening is that any POST or PUT requests will be authenticated using Basic authentication against the password file .htpasswd. This covers access to ALL the repositories.

There are a couple of problems here. First, with the .htaccess file above, our security related files are openly accessible to everyone. We can add a FilesMatch directive to hide our security files:

<FilesMatch "\.(htaccess|htpasswd|config|bak|ini)$">
Order allow,deny
Deny from all
</FilesMatch>

The second problem is that everyone can still see all of the repositories. Since these are client repos, I don’t want the random browser to stumble across them. That’s fixed easily enough, just change

<Limit POST PUT>

to

<Limit POST PUT GET>

Now ALL requests are met with a request for authentication. It’s not the prettiest thing in the world, but it works for now. Only clients in the .htpasswd file can view the web portal.

Now to configure access to the repositories themselves. Our security settings will go in each repository’s hgrcfile. The two settings we are interested are allow_push and allow_read. Each take a comma-separated list of authorized users. These go in the [web] section of the configuration file.

[web]
allow_read = me,client1,client2
allow_push = me,client1

It’s worth noting that the default for allow_read is to allow all, but the default for allow_push is to deny all.

The major remaining limitation is that once I add a client to the .htpasswd file, they have access to the whole web interface, which lets them view other repositories. The solution is to add hidden = true to the hgrc. This hides the repository from the web directory listing at the root, which lists all of the available repos, but will still serve the repos' web page if accessed directly.

[web]
contact = Chris Lawlor
description = Empty Mercurial Repository. Copy this to create client repos.

# Repository name to use in the web interface. Default is current working directory
#name =

## ACCESS CONTROL ##
allow_push = clawlor
allow_read = clawlor, fakeclient, fakeclient3

# hide repo from the directory
hidden = true