8000 Allow to set envdir based on envname factors · Issue #659 · tox-dev/tox · GitHub
[go: up one dir, main page]

Skip to content
Allow to set envdir based on envname factors #659
@volans-

Description

@volans-

Problem statement

Let's say there are multiple environments for different tests, like flake8, unit, sphinx and so on, but one would like to share the same virtual environment between them. This because their additional dependencies compared to the install_requires of the main application are small and this allows to reduce the space used and the time required to run the tests.
At the same time the application must be tested across multiple Python versions, so let's say this is the list of environments:

[tox]
envlist = py{34,35,36}-{flake8,unit,unit-min,bandit,prospector,sphinx}

And one would like to have six virtualenvs:

py34-tests
py35-tests
py36-tests
py34-tests-min  # To test with the minimum version of dependencies
py35-tests-min
py36-tests-min 

At the best of my understanding, right now the only way to achieve this is to manually expand the envlist matrix and for each one create a [testenv:envname] block in the tox.ini file with the envdir assignement.

Proposed change

Like it works already for deps and commands, the proposal is to add support also for the envdir property to be set with factor-based values like:

[testenv]
envdir =
    py34: py34-tests
    py35: py35-tests
    py36: py36-tests
    py34-min: py34-tests-min  # matches only environments that have both 'py34' and 'min' factors
    py35-min: py35-tests-min
    py36-min: py36-tests-min

Clearly there is a decision to make in case more than one factor matches an environment, given that the envdir can be only one, there are basically three possible behaviours:

  • the one with more factors matching wins, in case of tie, first or last win. [preferred]
  • first win
  • last win
  • raise an error

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:configurationfeature:changesomething exists already but should behave differentlyhelp:wantedIssues that have been acknowledged, a solution determined and a PR might likely be accepted.needs:discussionIt's not quite clear if and how this should be done

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0