On Fri, Jul 13, 2018 at 10:16 AM Bernát Gábor <jokerjokerer@gmail.com> 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-reference-interpreter. tox follows this logic for interpreter discovery, especially for 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.)

On Fri, Jul 13, 2018 at 10:38 AM Bernát Gábor <jokerjokerer@gmail.com> wrote:
> That being said it would be possible to add a smarter check against 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