1. Holger Krekel
  2. tox
  3. Issues


Issue #54 on hold

chdir away from tox.ini directory during test

Daniel Holth
created an issue

tox seems to run code with the directory containing tox.ini in the PYTHONPATH, loading code from the checkout instead of the installed sdist inside the virtualenv. Instead, tox should chdir to catch 'forgot to include something in sdist' errors.

Comments (12)

  1. jenisys

    I just ran into the same issue. The project is using nose as test runner. Therefore, I cannot switch. As an experiment I replaced nosetests with py.test and I cannot confirm that py.test is using the installed package in the virtual environment. It is using the local package according to the stack traces of the failed tests (sorry: Ronny). I assume the behavior depends how the PATH environment variable is set.

    One changedir command can be applied by using the testenv:changdir option in the tox.ini configuration file:

    # FILE: tox.ini
    changedir = {toxworkdir}/{envname}
    commands =
         py.test {toxinidir}/tests

    The default value for changeddir is {toxinidir} which causes the problems described above. Maybe the default value should be changed ?!? or a documentation hint should be provided (or the people should learn to read the documentation, including myself).

  2. Holger Krekel repo owner

    @jenisis does you "tests" directory contain an init.py by chance? This would lead pytest to insert the parent dir of "tests" and if you packages lives at the same level this can lead to importing the non-installed package. Clearly, this is too unpredictable. I think tox should grow an "testlocations = ..." or similar option which allow to specify where the test directoryies/file live (with glob patterns etc.). If that option is specified, they would be copied to the environment and there could be an optional "2to3" step before running tests there.

  3. jenisys

    The "test" directory (not: "tests") contains an empty "init.py" file.

    A feature like "testlocations = ..." would be good idea. Testing is the primary use case. But I think the problem is more general; something like one or more copytree commands are needed (at least for me).

  4. Holger Krekel repo owner

    right, the idea of "testlocations" would be to do copying of them to some environment directory in order to perform 2to3 or other transforms.

    In general, i'd like tox to learn to generate setup.py/setup.cfg for a project (so everything could be based on tox.ini using PEP426 compliant metadata). If that happens we could think about also generating test packages and installing them, based on the same metadata.

  5. Brecht Machiels

    As I understand it, Python always first searches the working directory when importing a package or module. The working directory (where tox.ini lives) is typically a repository checkout. Often the package source code is stored in a directory that matches the package name. In that case, this directory will shadow the installed package, and tox is in fact not testing the installed package.

    This is a critical problem for packages that modify (2to3) source files on installation.

    Wouldn't it be best that the working directory is always a temporary, empty directory to make sure there's nothing strange going on?

  6. Log in to comment