win32: specify python.exe locations

Issue #114 on hold
Adam Groszer created an issue

Any chance to have a place to specify pyhon.exe locations? The problem is that not everyone can/will use the r"c:\python\d.\d\python.exe" location. E.g. on I need 32 and 64 bit pythons beside each other. I'd vote for a global tox.ini where one could define something.

Comments (21)

  1. Holger Krekel repo owner

    I just wrote a lengthy suggestion on this in a declined PR, trying to tackle this issue. I now found out i can't easily access my message from that decline request (DOH). Maybe @anthon_van_der_neut can post it here?

  2. Adam Groszer reporter

    Found the PR. I'm OK with an ENV variable too. Whatever makes it work. Guessing just won't work for everyone.

    re globs: be prepared for exotic locations ;-)

  3. Anthon van der Neut

    @agroszer : Below is what @hpk42 wrote this morning. I will probably be able to implement this based on his wishes, both commandline and environment var. Most time consuming will be writing the tests, although I am getting better at that... I will let you know when I have something that is testable.

    Original message:

    I don't want to get into the business of putting things in $HOME with tox right now. In fact, tox-1.6 now sets a pseudo-HOME during installing dependencies. In the long run, i'd like to move tox.ini to support specifying python versions instead of doing things based on names and "basepython" settings. I.e. set a python_version = >2.5,<2.6, and then tox will find a good match based on looking at all available interpreters. note that tox-1.6 already has new code in tox/ which queries all specified python versions at configuration time. Creating a map from version->executable should be straight forward. What remains is the question of how to discover interpreters. I think we could - in conjunction with the above idea - start with an option "--interpreter-globs" which which is a shlex.split()-able list of globs-patterns so in your case "/opt/python/*/bin/python?.?" to discover all pythons. We can also have a TOX_INTERPRETER_GLOBS env var which is read in as well, and can be set from $HOME/.bashrc.

  4. Adam Groszer reporter

    Some salt for your tests. Please be prepared on windows for such locations:

    • c:\python2.7
    • c:\python27_32
    • c:\python2.7_32
    • c:\python2.7.3_32
    • c:\a dir with spaces\python2.7

    and such variatons.

    The problem is that you can install python.exe practically anywhere. Where linux has a well established standard of python\d.\d, the same is a pain on windows.

  5. Anthon van der Neut

    @agroszer I just uploaded a PR for the changes to allow --interpreter-globs and/or TOX_INTERPRETER_GLOBS. I am not sure if you are willing to try this out before @hpk42 integrates this in release, but if you do, you can find the source here: and of course I can help assist if there are any problems.

    I tested this on my Virtual Machine based Windows where Python 2.7 is installed under C:\Program Files\Python27\ (so spaces work) if your 32 and 64 bit versions have some regularity in the naming then the globbing should be able to find you all the 64bit or all the 32bits at a time.

  6. Anthon van der Neut

    @tiran: Reading the registry is an interesting additional possibility, but those entries are not necessary to run Python. And they don't need to be there (they are in fact not always there, as I can see on one of my windows installations). Relying on them is IMHO in the same league as relying on python being in C:\pythonX.Y : useful for most cases but not for all.

  7. Adam Groszer reporter

    Yup, definitely the manually specified locations need to have the highest priority. I will just know better what I want.

  8. Marius Gedminas

    AFAICS all you need is the ability to use two config files instead of one: - one system-specific, to specify the basepython setting for all the [testenv:pyXY] sections, and - one project-specific to specify the dependencies and commands

    I was going to say that ConfigParser supports multiple config files seamlessly, but then did a quick grep and I see tox uses py.iniconfig instead, about which I know nothing.

  9. Holger Krekel repo owner

    nope, the PR is not conflict free and i need to find 1-2 consecutive days (at least) to properly work on this i thin.

  10. Ruamel/Anthon van der Neut

    Holger, I can get it back into mergable shape once more if you want, it would be nice if it then gets merged as I already did that once. I have used my fork for myself for the longest time but then wanted to use some new tox feature a month some three months ago, and now use an alias for tox (that gets the right micro version where I have multiple major.minor versions installed), on Linux, where this is easy. On windows it is a pain, via the registry only one micro (the last one installed) can be found. I really need to be able to test 2.7.3, 2.7.6 and 2.7.9 as I the older two micro versions are installed at some customers and I am not in the position to upgrade. I have given some thought about a wrapper for tox that handles this as I currently have multiple (memory gobbling) windows VMs, but I much rather spent the time whipping this PR in shape.

  11. Holger Krekel repo owner

    @anthon_van_der_neut thanks for your efforts. I'd appreciate if you bring the PR back into shape. One issue we need to solve on top is how to specify interpreter versions from the environments, for example basepython = python==2.7.6, basepython = pypy>=2.3.0,<2.4, reusing setuptools/pip requirements syntax.

  12. Holger Krekel repo owner

    Also, i would expect tox to find all python interpreters automatically that are reachable through $PATH (and ideally the windows registry). We might also need to cache version info if it turns out calling all of the interpreters at tox startup takes too long.

  13. Michael Rans

    I have found a strange case which seems to absolutely require the option to specify Python locations. I log into a server with an admin user X, but for running services I have to use another admin user Y that does not have log on rights. tox works fine for X, but for Y, it fails to find Python for reasons I cannot fathom, giving: ERROR: InterpreterNotFound: python3.4. If I could specify the path to Python, that would be a solution to this problem.

  14. Timm Wagener

    Just to revive this issue: Maybe it would already be of good help to extend the current automatic interpreter detection on windows to match the formula used by the web CI service appveyor. This seems like a default interpreter setup which might be acceptable for many teams.

    Current behaviour:

    • Testenv name: pyXY
    • Interpreter Resolution (Windows): C:\Python27\python.exe | (not C:\Python2.7\python.exe as the docs say)

    Proposed behaviour:

    • Testenv name: pyXY
    • Interpreter Resolution (Windows): C:\Python27\python.exe
    • Testenv name: pyXY-x64
    • Interpreter Resolution (Windows): C:\Python27-x64\python.exe
  15. Wil Cooley

    Based on the conversation, am I correct in saying that the scope of this issue has grown to cover a means of specifying the interpreter path on all platforms, not just win32? If so, could someone update the title and description to reflect that? (Note that it seems Bb's issues do not preserve history of the description, so take care.)

    Issue #217 is a duplicate, but from a Unixish perspective.

    Wouldn't #154 ("Allow user configuration outside of tox.ini") take care of this, in that an individual user would be able to manually override interpreter paths per-user/host? (#154 describes a superset of what's been discussed here, so it's not a duplicate.)

  16. Log in to comment