VCS not found on Windows virtualenv

[jaraco]

Originally reported by: Barry Laffoy (BitBucket: laffoyb, GitHub: laffoyb)

---

Running setuptools with a hgtools dependency in a Windows virtualenv will fail if no global hg executable is available on the path.

(dev) PS C:\env\dev\build> python setup.py bdist_wheel
Traceback (most recent call last):
  File "setup.py", line 69, in <module>
    test_suite="nose.collector"
  File "c:\Python27\Lib\distutils\core.py", line 112, in setup
    _setup_distribution = dist = klass(attrs)
  File "C:\env\dev\build\dev\lib\site-packages\setuptools\dist.py", line 269, in __init__
    _Distribution.__init__(self,attrs)
  File "c:\Python27\Lib\distutils\dist.py", line 287, in __init__
    self.finalize_options()
  File "C:\env\dev\build\dev\lib\site-packages\setuptools\dist.py", line 324, in finalize_options
    ep.load()(self, ep.name, value)
  File "C:\env\dev\build\dev\lib\site-packages\hgtools\plugins.py", line 113, in version_calc
    dist.metadata.version = calculate_version(options)
  File "C:\env\dev\build\dev\lib\site-packages\hgtools\plugins.py", line 94, in calculate_version
    mgr = managers.RepoManager.get_first_valid_manager()
  File "C:\env\dev\build\dev\lib\site-packages\hgtools\managers\base.py", line 42, in get_first_valid_manager
    return next(RepoManager.get_valid_managers(location))
StopIteration: No source repo or suitable VCS version found

To demonstrate the setup, there is no hg on the path:

PS C:\> Get-Command hg | select path
Get-Command : The term 'hg' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ Get-Command hg | select path
+ ~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (hg:String) [Get-Command], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand

But with the virtualenv activated, hg.bat is available:

(dev) PS C:\> Get-Command hg | select path

Path
----
C:\env\build\dev/Scripts\hg.bat

In hgtools.managers.cmd.Mercurial, the exe is defined as "hg". This lead to _invoke creating commands of the form subprocess.Popen(["hg", "status"],...)

But by opening a Python shell I can see that this won't work, whereas calls to hg.bat will work.

>>> import subprocess
>>> subprocess.Popen(["hg", "status"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Python27\Lib\subprocess.py", line 711, in __init__
    errread, errwrite)
  File "c:\Python27\Lib\subprocess.py", line 948, in _execute_child
    startupinfo)
WindowsError: [Error 2] The system cannot find the file specified
>>> subprocess.Popen(["hg.bat", "status"])
<subprocess.Popen object at 0x027A5F30>
>>> M .hgignore
? .hgignore.swp
? .hgignore~
? hgtools-6.3.zip

I'm not sure if this is a bug in hgtools, or in the underlying subprocess.Popen.

It seems like there should be a way to work around this by fiddling with the environment variable PATHEXT, but I can't seem to figure it out.

A workaround that definitely works is to install a global Mercurial executable, by some method other that pip install. This will provide a hg exe on the path. This isn't always ideal though.

(edit to fix code formatting)

---

• Bitbucket: https://bitbucket.org/jaraco/hgtools/issue/30

[jaraco]

Thanks for the report. Yes, it's true that Popen doesn't work as expected with PATHEXT. A search of PATHEXT on bugs.python.org yields quite a few related issues.

As I understand it (though I have no reference), Microsoft has commented on this issue and has indicated that a fix to generally support PATHEXT in the CreateProcess API (which Popen uses) is unlikely to happen, and that wrapper executables should be used for maximum compatibility.

I believe there is room for the Python code to work around this limitation, and have Popen resolve the PATHEXT to the hosting executable and run the program that way, but that would be outside the scope of hgtools.

Another option might be to invoke Popen with shell=True, which will use a shell process such as cmd.exe to resolve the PATHEXT script. I'm reluctant to simply make this change as I'm unaware what other implications that might have.

As this project is largely defunct in deference to setuptools_scm, I suggest the issue be taken up there. If the issue is fixed there, then I'd be happy to accept the same behavior for this library.

In the meantime, I'm marking this as wontfix, as I won't have time to invest in troubleshooting or testing, but I welcome pull requests.