Do we really want to specify the basepython?

[altendky]

desert/tox.ini

Lines 12 to 18 in 8f03d9c

	basepython =
	pypy3: {env:TOXPYTHON:pypy3}
	{doc,spell}: {env:TOXPYTHON:python3.8}
	py36: {env:TOXPYTHON:python3.6}
	py37: {env:TOXPYTHON:python3.7}
	py38: {env:TOXPYTHON:python3.8}
	{bootstrap,clean,check,report,codecov}: {env:TOXPYTHON:python3}

The report and codecov envs are called for each Travis job. In the pypy3 job I added it ends up failing while trying to use python3 to create an env. So I removed them and now it fails because basepython is nothing.

What I see this assume is the ability to override with TOXPYTHON. The cost is that you must explicitly set basepython for all cases. I think...

If we want to keep TOXPYTHON around then maybe we swap the report env for {py36,py37,py38,pypy3}-report? Then I think the py.* reference would trigger the existing lines to pick the basepython.

Opinions? Facts?

[altendky]

So here they made it configurable with TOXPYTHON but it existed before that too.
adamboche/cookiecutter-pylibrary@d2b1a2f#diff-7741b318e0b8208d5820b33f076b6769

And the basepython specification was introduced here with no explanation I found immediately.
adamboche/cookiecutter-pylibrary@b8be0e4#diff-7741b318e0b8208d5820b33f076b6769

To be clear, I'm still trying to get this all in my head and pick what I even think would be good...

[altendky]

Ok, one mystery solved. In the exploratory #41 I just went for it and dumped the basepython specification and it just works... https://travis-ci.com/python-desert/desert/jobs/280276364 tox decides to use pypy3 for the report env.

https://github.com/python-desert/desert/blob/9b3b6af7420c6011826c88de4e43ff0c7d83ed1f/.travis.yml
https://github.com/python-desert/desert/blob/9b3b6af7420c6011826c88de4e43ff0c7d83ed1f/tox.ini

But that isn't what happens locally so I think it's just falling through all its options and pypy3 is the first acceptable one so it uses it. It works, but I don't think it's explicitly doing what I want.

[altendky]

It could certainly be argued, and I might be convincing myself now, that the real issue is Travis not providing multiple Pythons... Just as we have chosen to use python3.8 for the doc env I would sort of like to use that same single Python implementation/version for all the non-test tooling including the report and codecov envs. It's just one less factor to deal with and it only affects developers who ought to be respecting the need for multiple Pythons if they are doing these things locally anyways. So maybe the real solution is to add a Travis check and install Python 3.8 if it isn't the selected version?

Sounds like a nice simplifier.