Yes, the later is the intent and indeed what you're suggesting is what would be more robust solution. Please create an issue on GitHub for it and we'll release a patch fix. On Fri, Jul 13, 2018, 16:22 Fred Drake <fred@fdrake.net> wrote:
This is working at intended. tox is about reproducible build, hard coding to full path seems from this point wrong as it's almost bound to fail on other peoples system. Discovery on Linux systems should be via having the pythonx.y format as specifiad in http://www.python.org/dev/peps/pep-0394/#application-to-the-cpython-referenc.... tox follows this logic for interpreter discovery, especially for
On Fri, Jul 13, 2018 at 10:16 AM Bernát Gábor <jokerjokerer@gmail.com> wrote: pre-defined build environments.
That PEP deals with how symlinks should be managed for interpreters accessed via PATH; it really doesn't say anything about selecting the Python to use for a particular application. In the end, it always boils down to "run the Python you want"; there's no reason to expect all interpreters to be installed along the PATH.
That being said I know this worked until now. So in that sense it's a regression. I would say though that your use case is the edge case, if you want to use it like that define custom tox environments, e.g. py27k instead of py27. In general, for people who follow the python discovery system enlisted in that pep, this change should help them avoid invalid configuration and bad suprises.
Issuing a warning when the Python version doesn't match a pyXY factor, if used, makes sense; I agree that's a valuable thing and can let people know when they're shooting themselves in the foot. But the warning is the right reaction to that; I don't think ignoring the configuration is ever the right thing to do.
In the package this example is taken from (open source), I'm sharing the tox.ini except for the basepython settings:
https://github.com/keepertech/kt.testing/blob/master/tox.ini
I'd love to have a way to create a second configuration (kt-tox.ini) that includes the tox.ini and adds the basepython settings. That would allow me to avoid needing to repeat the rest of the configuration in a second file. (Buildout supports this with a [buildout] extends = ... setting; a [tox] extends = ... would be really nice to have for this.)
That being said it would be possible to add a smarter check against
On Fri, Jul 13, 2018 at 10:38 AM Bernát Gábor <jokerjokerer@gmail.com> wrote: python version missmatch that would still allow this kind of path hardcoding.
If the intent is to verify & warn the user that an environment including a pyXY factor is using some Python version other than X.Y, the check should be simple; just check the return code from:
{envdir}/bin/python -c 'import sys; sys.exit(sys.version_info[:2] != (X, Y))'
I think this would be a better check.
-Fred
-- Fred L. Drake, Jr. <fred at fdrake.net> "A storm broke loose in my mind." --Albert Einstein