Can't have a Python 3

Issue #96 on hold
Barry Warsaw created an issue

Let's say your is only Python 3 compatible. tox set up fails when building the sdist:

% tox -e py33
GLOB sdist-make: .../
ERROR: invocation failed, logfile: .../.tox/log/tox-0.log
ERROR: actionid=tox
cmdargs=['/usr/bin/python', local('.../'), 'sdist', '--formats=zip', '--dist-dir', local('.../.tox/dist')]
Traceback (most recent call last):
  File "", line 18, in <module>
    with open('.../version.txt', encoding='utf-8') as fp:
TypeError: 'encoding' is an invalid keyword argument for this function

ERROR: FAIL could not package project

There doesn't seem to be a way to configure this in the tox.ini, though I could be missing it of course.

Comments (6)

  1. Holger Krekel repo owner

    tox uses the interpreter it executes with to do the packaging step. Did you try running tox on top of Python3?

  2. Barry Warsaw reporter

    I didn't because on Debian/Ubuntu, we install /usr/bin/tox with a #! of /usr/bin/python (i.e. Python 2). It would be really nice if we didn't have to also install a /usr/bin/tox3 because that way lies madness (we have a similar problem with nose where we're moving away from having /usr/bin/nosetests{,-3} since we'd also need debugging versions and that just means we have to install way too many scripts).

  3. Holger Krekel repo owner

    there is a (somewhat vague) plan to make the sdist-packaging configurable, particularly the interpreter choice. This would probably fix this issue.

  4. Chris Lasher

    This still seems to be an issue today. I have run into this because I use the ShiningPanda plugin for Jenkins. It installs and keeps tox up to date using the system Python, which is Python 2.7. Our package is a Python 3 package with a

    open('README.rst', encoding='utf-8').read()

    in the file.

    I didn't realize until we added the encoding that tox was creating the sdist file using Python 2.7. When the package targets Python 3, could using Python 2.7 to do the sdist have any detrimental effects? It seems like it would make more sense to have the same Python of the toxenv currently under test. I know this creates redundancy in that an sdist is created per toxenv, however, it would fix this issue.

  5. Log in to comment