# HG changeset patch
# User Matt Harbison <matt_harbison@yahoo.com>
# Date 1522957360 14400
# Node ID 5e81cf9651c1b4202c79a8aa15c552d2e7ee5332
# Parent  f3dc8239e3a9c36ab90069718529e763ef884008
hgweb: fallback to checking wsgireq.env for REPO_NAME for 3rd party hosting

Starting with d7fd203e36cc, SCM Manager began to 404 any repository access.
What's happening is that it is generating a python script that creates an hgweb
application (not hgwebdir), and launches hgweb via wsgicgi.  It must be setting
REPO_NAME in the process environment before launching this script, which gets
picked up and put into wsgireq.env when wsgicgi launches the hgweb application.
>From there, other variables (notably 'apppath' and 'dispatchpath') are
constructed differently.

  d7fd203e36cc^ (working):

    apppath: /hg/eng/devsetup
    dispatchpath:
    pathinfo: /eng/devsetup
    reponame: eng/devsetup

  d7fd203e36cc:

    apppath: /hg
    dispatchpath: eng/devsetup
    pathinfo: /eng/devsetup
    reponame: None
    REPO_NAME: eng/devsetup

Rather than having an existing installation break when Mercurial is upgraded,
just resume checking the environment.  I have no idea how many other hosting
solutions would break without restoring this.

diff -r f3dc8239e3a9 -r 5e81cf9651c1 mercurial/hgweb/request.py
--- a/mercurial/hgweb/request.py	Wed Apr 11 12:51:09 2018 -0700
+++ b/mercurial/hgweb/request.py	Thu Apr 05 15:42:40 2018 -0400
@@ -161,6 +161,12 @@
         env = {k: v.encode('latin-1') if isinstance(v, str) else v
                for k, v in env.iteritems()}
 
+    # Some hosting solutions are emulating hgwebdir, and dispatching directly
+    # to an hgweb instance using this environment variable.  This was always
+    # checked prior to d7fd203e36cc; keep doing so to avoid breaking them.
+    if not reponame:
+        reponame = env.get('REPO_NAME')
+
     if altbaseurl:
         altbaseurl = util.url(altbaseurl)