From matthias.seitz at switch.ch  Mon May  5 10:49:28 2014
From: matthias.seitz at switch.ch (Matthias Seitz)
Date: Mon, 05 May 2014 16:49:28 +0200
Subject: [Moin-user] No templates with moinmoin 1.9.4
Message-ID: <5367A4F8.9020204@switch.ch>

moinmoin is installed from the Debian Packages on a debian wheezy
system, the current release there is 1.9.4-8

The wiki works great so far, the only thing which doesen't work are the
templates. regex in the wikiconfig.py:

page_category_regex = ur'(?P<all>Category(?P<key>(?!Template)\S+))'
page_dict_regex = ur'(?P<all>(?P<key>\S+)Dict)'
page_group_regex = ur'(?P<all>(?P<key>\S+)Group)'
page_template_regex = ur'(?P<all>(?P<key>\S+)Template)'

I've created a test_Template site (and also several others like
testTemplate) but the expected template subsite from where the templates
can be selected doesn't appear at all.
There's just a URL "Create New Page".

Can anybody give me a hint? I've tested several configurations, also
with CGI/WSGI but nothing worked so far. As mentioned, everything else
worked, also the group regex does a good job.

Thanks in advance
Matthias



From waqas805 at hotmail.com  Fri May  9 08:06:52 2014
From: waqas805 at hotmail.com (Waqas Ahmad)
Date: Fri, 9 May 2014 14:06:52 +0200
Subject: [Moin-user] Virtual Board in wiki
Message-ID: <DUB113-W1035544619A51ADF84FEF4487480@phx.gbl>

Hello everybody, 
is anybody know that how can i implement the virtual board in wiki? is it possible in wiki or not?

e.g. Virtual Board like this: http://scrumy.com/
or maybe like this: https://trello.com/#b/nC8QJJoZ/trello-development
 
I don't want to use the virtual board on external server because of the data securtiy. We are using wiki since 2008 and now we want to create the virtual board functionality in our wiki. 
 
any ideas or tipps are very welcome. 
 
---Best Regards, Waqas 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140509/f1366ba1/attachment.html>

From tw at waldmann-edv.de  Thu May 15 09:07:36 2014
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Thu, 15 May 2014 15:07:36 +0200
Subject: [Moin-user] No templates with moinmoin 1.9.4
In-Reply-To: <5367A4F8.9020204@switch.ch>
References: <5367A4F8.9020204@switch.ch>
Message-ID: <5374BC18.9080204@waldmann-edv.de>

On 05/05/2014 04:49 PM, Matthias Seitz wrote:
> moinmoin is installed from the Debian Packages on a debian wheezy
> system, the current release there is 1.9.4-8

A bit old, as usual, but should work (and they apply critical security
fixes).

> The wiki works great so far, the only thing which doesen't work are the
> templates. regex in the wikiconfig.py:
> 
> page_category_regex = ur'(?P<all>Category(?P<key>(?!Template)\S+))'
> page_dict_regex = ur'(?P<all>(?P<key>\S+)Dict)'
> page_group_regex = ur'(?P<all>(?P<key>\S+)Group)'
> page_template_regex = ur'(?P<all>(?P<key>\S+)Template)'

Looks like the defaults, right?

> I've created a test_Template site

You mean a page with that name?

> There's just a URL "Create New Page".

The template pages should show in the list of templates, as well as
similarly named pages on the same page as "create new page?".

Did you restart the wiki after (maybe?) modifying your wiki config?




From matthias.seitz at switch.ch  Thu May 15 10:04:22 2014
From: matthias.seitz at switch.ch (Matthias Seitz)
Date: Thu, 15 May 2014 16:04:22 +0200
Subject: [Moin-user] No templates with moinmoin 1.9.4
In-Reply-To: <5374BC18.9080204@waldmann-edv.de>
References: <5367A4F8.9020204@switch.ch> <5374BC18.9080204@waldmann-edv.de>
Message-ID: <5374C966.6020208@switch.ch>


>> The wiki works great so far, the only thing which doesen't work are the
>> templates. regex in the wikiconfig.py:
>>
>> page_category_regex = ur'(?P<all>Category(?P<key>(?!Template)\S+))'
>> page_dict_regex = ur'(?P<all>(?P<key>\S+)Dict)'
>> page_group_regex = ur'(?P<all>(?P<key>\S+)Group)'
>> page_template_regex = ur'(?P<all>(?P<key>\S+)Template)'
> 
> Looks like the defaults, right?
Yes, all default values. As written, the page_group_regex works as
expected, and also everything else except the problem with the
none-exisiting frame.

> 
>> There's just a URL "Create New Page".
> 
> The template pages should show in the list of templates, as well as
> similarly named pages on the same page as "create new page?".
> 
> Did you restart the wiki after (maybe?) modifying your wiki config?

I've tested several things, within different wiki instances on the same
server, also restarting.

There's just a "Create New Page" URL, nothing else(except the header and
footer of the wiki), the whole frame with the templates and the
"similiar page" are missing.

Matthias







From tw at waldmann-edv.de  Thu May 15 17:52:42 2014
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Thu, 15 May 2014 23:52:42 +0200
Subject: [Moin-user] No templates with moinmoin 1.9.4
In-Reply-To: <5374C966.6020208@switch.ch>
References: <5367A4F8.9020204@switch.ch> <5374BC18.9080204@waldmann-edv.de>
	<5374C966.6020208@switch.ch>
Message-ID: <5375372A.3050702@waldmann-edv.de>

BTW, I just tested the "template issue":

With the current repo code as well as with the code tagged as "1.9.4" it
immediately worked.

I just uncompressed the underlay.tar (this is needed when running the
wiki from the repo, not required when using a release archive or package).

Then I started wikiserver.py and visited a non-existing page.

Got the "create new page" link plus the list with a few templates on the
left.

So I guess the issue must be some local configuration or installation issue.

Maybe check in the log output the precise path of the config file(s) it
loads. Maybe it is not the file you are editing.



From coolnodje at gmail.com  Thu May 22 05:46:53 2014
From: coolnodje at gmail.com (coolnodje)
Date: Thu, 22 May 2014 17:46:53 +0800
Subject: [Moin-user] Bibliography macro install
Message-ID: <537DC78D.3040607@gmail.com>

I've been trying to install the
http://moinmo.in/MacroMarket/Bibliography macro, and I admit I've
failed. It's quite a hell to decipher what to do to be honest.

Very difficult to know what to install: there's 2 version of Macro
Bibliography.py, and apparently v1.6 is the one to use even though the
default is still v1.5.
Then 2 versions of the BibTex parser exist as well:
http://moinmo.in/ParserMarket/Bibtex and
http://moinmo.in/ParserMarket/Bibtex2 . The first is the one referenced
from the main page, but it seems outdated compare to the second.
In both case, in order to get this to work, external binaries are
required, and this where the install becomes very tricky.
bibtex and bib2xhtml are required in the first case
bibtex and bibtex2html are required in the second.

In the second case, bibtex2html's home page is found under
http://www.lri.fr/~filliatr/bibtex2html/
A package exist for Debian: apt-get install bibtex2html

Convenient, but:
I skip here the dozens of  extra packages necessary, but the result is:

After this operation, 357 MB of additional disk space will be used.
Do you want to continue [Y/n]? n

As for bibtex binaries, I'm still not sure what to get. I've found
apt-get install biblatex

but

After this operation, 1,127 MB of additional disk space will be used.
Do you want to continue [Y/n]? n

This would be more than twice the size of my dedicated debian install of
moinmoin...

In the case of the first BibTex parser, bib2xhtml can be found in
http://www.spinellis.gr/sw/textproc/bib2xhtml/
This is much lighter as it's a perl script, but install is unclear.
And there's still the dependency on bibtex executable.

Help on installing would be really welcome as I'm unsure on which
direction to take now.

At least, where can I get the bibtex executables? Is the biblatex debian
package going to provide it? I'm reluctant to install more than a
gigabyte of dependencies just to check if it does...

cheers
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140522/5d4dca66/attachment.html>

From coolnodje at gmail.com  Fri May 23 06:59:06 2014
From: coolnodje at gmail.com (coolnodje)
Date: Fri, 23 May 2014 18:59:06 +0800
Subject: [Moin-user] Bibliography macro install on 1.94
In-Reply-To: <537DC78D.3040607@gmail.com>
References: <537DC78D.3040607@gmail.com>
Message-ID: <537F29FA.1050504@gmail.com>

I've been able to install both version of the parser with all needed
dependencies now.

http://moinmo.in/ParserMarket/Bibtex2 doesn't produce any error but a
warning:
WARNING MoinMoin.parser._ParserBase:123 Using ParserBase is deprecated -
please use/extend pygments syntax highlighting library.

and doesn't render anything in the page. The bibtex code block is just
ignored.
Could the deprecated dependency be enough to get the rendering wrong?


The combination of http://moinmo.in/ParserMarket/Bibtex and
http://moinmo.in/MacroMarket/Bibliography (version 1.6) produces error
in both case.

Macro Bibliography usage is looking for ../parser/bibtex.py but doens't
find it.

File "/var/lib/ccmmp/data/plugin/macro/Bibliography.py", line 67, in
<module>
from MoinMoin.parser.bibtex import Parser as BibtexParser
ImportError: No module named bibtex

I'm a Python beginner and probably miss something obvious but it seems
to me that everything is where it should be: Bibliography.py is in
../data/plugin/macro and bibtex.py is in ../data/plugin/parser

When trying to use the parser independantly I get the following error:

File "/var/lib/ccmmp/data/plugin/parser/bibtex.py", line 273, in format
{"bib2html_cmd": self.bib2html_cmd}))
AttributeError: Parser instance has no attribute 'bib2html_cmd'

bib2html_cmd is set in the file, I've hardcode the path to the expected
command.

This line comes form a error catch block and I'm wondering if it
couldn't be a syntax problem.

All this code is pretty old but I really would like to get it working.
Help would be welcome. Or shall I talk to the macro author directly?

Also, even though I've set
from MoinMoin import log
log.load_config('/usr/share/moin/logging')
in moin.gwsgi, I always get [formatters] section not found or something
like that, even though the section exists in the log file config.
how do you get a config to be taken into account?

cheers
> coolnodje <mailto:coolnodje at gmail.com>
> 22 May 2014 17:46
> I've been trying to install the
> http://moinmo.in/MacroMarket/Bibliography macro, and I admit I've
> failed. It's quite a hell to decipher what to do to be honest.
>
> Very difficult to know what to install: there's 2 version of Macro
> Bibliography.py, and apparently v1.6 is the one to use even though the
> default is still v1.5.
> Then 2 versions of the BibTex parser exist as well:
> http://moinmo.in/ParserMarket/Bibtex and
> http://moinmo.in/ParserMarket/Bibtex2 . The first is the one
> referenced from the main page, but it seems outdated compare to the
> second.
> In both case, in order to get this to work, external binaries are
> required, and this where the install becomes very tricky.
> bibtex and bib2xhtml are required in the first case
> bibtex and bibtex2html are required in the second.
>
> In the second case, bibtex2html's home page is found under
> http://www.lri.fr/~filliatr/bibtex2html/
> A package exist for Debian: apt-get install bibtex2html
>
> Convenient, but:
> I skip here the dozens of  extra packages necessary, but the result is:
>
> After this operation, 357 MB of additional disk space will be used.
> Do you want to continue [Y/n]? n
>
> As for bibtex binaries, I'm still not sure what to get. I've found
> apt-get install biblatex
>
> but
>
> After this operation, 1,127 MB of additional disk space will be used.
> Do you want to continue [Y/n]? n
>
> This would be more than twice the size of my dedicated debian install
> of moinmoin...
>
> In the case of the first BibTex parser, bib2xhtml can be found in
> http://www.spinellis.gr/sw/textproc/bib2xhtml/
> This is much lighter as it's a perl script, but install is unclear.
> And there's still the dependency on bibtex executable.
>
> Help on installing would be really welcome as I'm unsure on which
> direction to take now.
>
> At least, where can I get the bibtex executables? Is the biblatex
> debian package going to provide it? I'm reluctant to install more than
> a gigabyte of dependencies just to check if it does...
>
> cheers
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140523/4501adfb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140523/4501adfb/attachment.jpg>

From suhrspamalot at gmail.com  Mon May 26 04:07:49 2014
From: suhrspamalot at gmail.com (Suhr Spamalot)
Date: Mon, 26 May 2014 01:07:49 -0700
Subject: [Moin-user] logging and macros
Message-ID: <CABb-tUWgDQx2XhoufutmBGcavOfHGOpsJoEUWdAr_VgLk2BB7w@mail.gmail.com>

Hi,

I'm running moinmoin 1.9.7 on CentOS 6.5 with Apache 2.2.15 and mod_wsgi
configured as a daemon.

I'm trying to understand why some macros compile and run properly, while
others do not. An example of the former is the Columns macro, located at
/opt/moinmoin/data/wikiname/data/plugin/macro/. In that same directory,
with the same permissions, is another macro (ChildPages) that will neither
compile nor run properly.

In attempt to debug the situation, I've configured debug-level logging for
both Apache and moinmoin. However, nothing regarding a macro of any type is
showing up in the logs.

Is there a macro-specific logging key that I have to enable in the logging
config file?moin_auth, moin_session and root are not getting me the info I
need..

Thanks,
Cooper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140526/66c312f1/attachment.html>

From phatbuckett at gmail.com  Tue May 27 03:27:29 2014
From: phatbuckett at gmail.com (Darren Spruell)
Date: Tue, 27 May 2014 00:27:29 -0700
Subject: [Moin-user] Configuring URL prefix for Moin served via Nginx +
	Gunicorn
Message-ID: <CAKVSOJXUUiJv95VpSfJnkQ6fqWcoXMv=vRY98VOeby-z-nV1bg@mail.gmail.com>

Greetings,

MoinMoin 1.9.7
Gunicorn 18.0
Nginx 1.4.1

I have a single wiki instance that works correctly when served from
the root of my site (/). I want to migrate it on the site now to be
served from /wiki/home/ (e.g.
http://www.example.org/wiki/home/HelpContents). When I configure this
on Nginx and then set 'url_prefix_static' in the MoinMoin config, wiki
pages are not served correctly. i.e. attempting to access
http://www.example.org/wiki/home/ attempts to load a page named
'wiki/home' and MoinMoin returns 404 with "This page does not exist
yet. You can create a new empty page, or use one of the page
templates."

I cannot find a config option to instruct MoinMoin that it is being
served from a subdirectory of the site and to therefore operate under
a URL prefix. I understand that 'url_prefix_static' is only for static
media. I notice that
http://moinmo.in/HelpOnConfiguration#Configuration_of_multiple_wikis
documents a config option 'url_prefix' however various references make
it look as if that setting is no longer used/suggested.

Gunicorn is a WSGI server but as opposed to uwsgi it uses standard
HTTP as a service protocol; I think this prevents one from passing
environment settings (such as SCRIPT_NAME) as one would for e.g. FCGI
or UWSGI, etc. However I notice that placing the following in my
moin.wsgi seems to fix he path finding:

os.environ['SCRIPT_NAME'] = '/wiki/home'

To me, this seems like more of a hack than a solution.

Current config details:

# Nginx config section
location /wiki/home {
    try_files           $uri @wiki_home_rewrite;
}
location @wiki_home_rewrite {
    proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header    Host $http_host;
    proxy_redirect      off;
    proxy_pass          http://127.0.0.1:8001;
}

# wikiconfig.py
class Config(multiconfig.DefaultConfig):
    ...
    url_prefix_static = '/wiki/home' + url_prefix_static
    ...

Is there a way to configure MoinMoin to understand that it is being
served from a URL with a prefix path and operate as desired without
modifying the environment in the WSGI driver script?

-- 
Darren Spruell
phatbuckett at gmail.com



From paul at boddie.org.uk  Tue May 27 14:17:12 2014
From: paul at boddie.org.uk (Paul Boddie)
Date: Tue, 27 May 2014 20:17:12 +0200
Subject: [Moin-user] Configuring URL prefix for Moin served via Nginx +
	Gunicorn
In-Reply-To: <CAKVSOJXUUiJv95VpSfJnkQ6fqWcoXMv=vRY98VOeby-z-nV1bg@mail.gmail.com>
References: <CAKVSOJXUUiJv95VpSfJnkQ6fqWcoXMv=vRY98VOeby-z-nV1bg@mail.gmail.com>
Message-ID: <201405272017.13553.paul@boddie.org.uk>

On Tuesday 27. May 2014 09.27.29 Darren Spruell wrote:
> Greetings,
> 
> MoinMoin 1.9.7
> Gunicorn 18.0
> Nginx 1.4.1
> 
> I have a single wiki instance that works correctly when served from
> the root of my site (/). I want to migrate it on the site now to be
> served from /wiki/home/ (e.g.
> http://www.example.org/wiki/home/HelpContents). When I configure this
> on Nginx and then set 'url_prefix_static' in the MoinMoin config, wiki
> pages are not served correctly. i.e. attempting to access
> http://www.example.org/wiki/home/ attempts to load a page named
> 'wiki/home' and MoinMoin returns 404 with "This page does not exist
> yet. You can create a new empty page, or use one of the page
> templates."

So you first need to make sure that Moin is served for that resource and not 
the root resource, and you then need to let Moin know that it is rooted at 
this new resource itself.

> I cannot find a config option to instruct MoinMoin that it is being
> served from a subdirectory of the site and to therefore operate under
> a URL prefix. I understand that 'url_prefix_static' is only for static
> media. I notice that
> http://moinmo.in/HelpOnConfiguration#Configuration_of_multiple_wikis
> documents a config option 'url_prefix' however various references make
> it look as if that setting is no longer used/suggested.

Yes, there's a mention of it in wikiconfig.py files that I've seen, but it 
appears to be obsolete.

> Gunicorn is a WSGI server but as opposed to uwsgi it uses standard
> HTTP as a service protocol; I think this prevents one from passing
> environment settings (such as SCRIPT_NAME) as one would for e.g. FCGI
> or UWSGI, etc. However I notice that placing the following in my
> moin.wsgi seems to fix he path finding:
> 
> os.environ['SCRIPT_NAME'] = '/wiki/home'

Well, this should be presented to Moin by the Web server: that's what it is 
for! However, in moin.wsgi, you might be able to set the fix_script_name 
setting instead.

> To me, this seems like more of a hack than a solution.
> 
> Current config details:
> 
> # Nginx config section
> location /wiki/home {
>     try_files           $uri @wiki_home_rewrite;
> }
> location @wiki_home_rewrite {
>     proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
>     proxy_set_header    Host $http_host;
>     proxy_redirect      off;
>     proxy_pass          http://127.0.0.1:8001;
> }
> 
> # wikiconfig.py
> class Config(multiconfig.DefaultConfig):
>     ...
>     url_prefix_static = '/wiki/home' + url_prefix_static
>     ...
> 
> Is there a way to configure MoinMoin to understand that it is being
> served from a URL with a prefix path and operate as desired without
> modifying the environment in the WSGI driver script?

If you can get away with fix_script_name, then yes. Otherwise, perhaps not. 
Again, without things like SCRIPT_NAME, scripts know nothing about their 
environment or the way they are deployed.

Paul



From coolnodje at gmail.com  Wed May 28 00:49:57 2014
From: coolnodje at gmail.com (coolnodje)
Date: Wed, 28 May 2014 12:49:57 +0800
Subject: [Moin-user] "Please use the interactive user interface to use
	action edit!" problem
Message-ID: <53856AF5.1010207@gmail.com>

Hi,

I'm having this problem intermitently.
It's hard to derive a rule of it.
It's listed as a bug on the moinmoin wiki but the page doens't provide
any solution:

http://moinmo.in/MoinMoinBugs/PleaseUseTheInteractiveUserInterfaceToUseActionEdit

It was not happening at first.
It's happening since I've started to changethe Theme, apparently.

The problems seem to occur randomly when editing a page and saving it
very quickly, and when playing with file: adding, deleting, etc...
When trying several time in a row, it seems we can generaly get through,
but it's a really annoying bug.

Could it be related to spam protection?

Cheers



From phatbuckett at gmail.com  Wed May 28 03:06:56 2014
From: phatbuckett at gmail.com (Darren Spruell)
Date: Wed, 28 May 2014 00:06:56 -0700
Subject: [Moin-user] Configuring URL prefix for Moin served via Nginx +
	Gunicorn
In-Reply-To: <201405272017.13553.paul@boddie.org.uk>
References: <CAKVSOJXUUiJv95VpSfJnkQ6fqWcoXMv=vRY98VOeby-z-nV1bg@mail.gmail.com>
	<201405272017.13553.paul@boddie.org.uk>
Message-ID: <CAKVSOJUAaiyb70bgOju+yGEkizm7NVcmhm2ggN2EaKqh1shGsA@mail.gmail.com>

On Tue, May 27, 2014 at 11:17 AM, Paul Boddie <paul at boddie.org.uk> wrote:
> On Tuesday 27. May 2014 09.27.29 Darren Spruell wrote:
>> Greetings,
>>
>> MoinMoin 1.9.7
>> Gunicorn 18.0
>> Nginx 1.4.1
>>
>> I have a single wiki instance that works correctly when served from
>> the root of my site (/). I want to migrate it on the site now to be
>> served from /wiki/home/ (e.g.
>> http://www.example.org/wiki/home/HelpContents). When I configure this
>> on Nginx and then set 'url_prefix_static' in the MoinMoin config, wiki
>> pages are not served correctly. i.e. attempting to access
>> http://www.example.org/wiki/home/ attempts to load a page named
>> 'wiki/home' and MoinMoin returns 404 with "This page does not exist
>> yet. You can create a new empty page, or use one of the page
>> templates."
>
> So you first need to make sure that Moin is served for that resource and not
> the root resource, and you then need to let Moin know that it is rooted at
> this new resource itself.

Sounds so simple! :)

>> I cannot find a config option to instruct MoinMoin that it is being
>> served from a subdirectory of the site and to therefore operate under
>> a URL prefix. I understand that 'url_prefix_static' is only for static
>> media. I notice that
>> http://moinmo.in/HelpOnConfiguration#Configuration_of_multiple_wikis
>> documents a config option 'url_prefix' however various references make
>> it look as if that setting is no longer used/suggested.
>
> Yes, there's a mention of it in wikiconfig.py files that I've seen, but it
> appears to be obsolete.

As it turns out, my attempting to find an option like this (configure
the wiki software to know what path it is served from) is a habit
formed from using various other software including at least one wiki
engine which uses a setting like this:

$wgScriptPath       = "/wiki/work";

I guess what I missed is that it's not necessarily MoinMoin that needs
to be told this, but the WSGI server hosting MoinMoin?

>> Gunicorn is a WSGI server but as opposed to uwsgi it uses standard
>> HTTP as a service protocol; I think this prevents one from passing
>> environment settings (such as SCRIPT_NAME) as one would for e.g. FCGI
>> or UWSGI, etc. However I notice that placing the following in my
>> moin.wsgi seems to fix he path finding:
>>
>> os.environ['SCRIPT_NAME'] = '/wiki/home'
>
> Well, this should be presented to Moin by the Web server: that's what it is
> for! However, in moin.wsgi, you might be able to set the fix_script_name
> setting instead.

Was curious about this, did not see this setting in the installed
moin.wsgi but did find it in the FCGI driver script.

>> To me, this seems like more of a hack than a solution.
>>
>> Current config details:
>>
>> # Nginx config section
>> location /wiki/home {
>>     try_files           $uri @wiki_home_rewrite;
>> }
>> location @wiki_home_rewrite {
>>     proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
>>     proxy_set_header    Host $http_host;
>>     proxy_redirect      off;
>>     proxy_pass          http://127.0.0.1:8001;
>> }
>>
>> # wikiconfig.py
>> class Config(multiconfig.DefaultConfig):
>>     ...
>>     url_prefix_static = '/wiki/home' + url_prefix_static
>>     ...
>>
>> Is there a way to configure MoinMoin to understand that it is being
>> served from a URL with a prefix path and operate as desired without
>> modifying the environment in the WSGI driver script?
>
> If you can get away with fix_script_name, then yes. Otherwise, perhaps not.
> Again, without things like SCRIPT_NAME, scripts know nothing about their
> environment or the way they are deployed.

And I guess this was the key. Stumbled into this FAQ entry:

http://gunicorn-docs.readthedocs.org/en/latest/faq.html#how-do-i-set-script-name

The resulting configuration in Nginx's configuration that works for me:

location /wiki/home {
    try_files           $uri @wiki_home_rewrite;
}
location @wiki_home_rewrite {
    proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header    Host $http_host;
    proxy_set_header    SCRIPT_NAME /wiki/home;
    proxy_redirect      off;
    proxy_pass          http://127.0.0.1:8001;
}

Having SCRIPT_NAME sent literally as a request header is
...interesting, but seems to be what Gunicorn is expecting (if not set
as an env var).

Will add a blurb at http://moinmo.in/HowTo - anything else of note about this?

-- 
Darren Spruell
phatbuckett at gmail.com