Closes #158

This adds coverage for --extra-python which allows for adding additional pythons for running python interpreters, not specified in the noxfile.

How would this feature be useful? Frequently you just want to re-run a particular session in a reused virtual environment as quickly as possible (e.g for unit tests, docs or linting). This is possible with --reuse-existing-virtualenvs, but session.install() still takes a second or two, which is not a lot, but still slower than just running pytest directly. Therefore, it would be useful to have an option for skipping session.install(), especially when executing sessions locally in a development loop.

Describe the solution you'd like Add an inverse of the --install-only command.

Describe alternatives you've considered

• Use invoke within a manually created virtual environment (this is what I've been doing).
• Just use a corresponding Python interpreter directly, e.g. .nox/<session_name>/bin/python -m pytest.
• Accept the 1-2 second overhead, and take your time to sip on your favourite beverage :)

Describe the bug

The docs are broken, the "stable" release did not build after the recent release (missing from changelog), with:

AttributeError: 'HTMLParser' object has no attribute 'unescape'

See https://readthedocs.org/projects/nox/builds/

This should be fixable by setting a minimum version on some of the docs dependencies (why are those mixed with the test dependencies?) - readthedocs installs old versions of things by default, and then it's a no-op if you don't force an upgrade. Why they install a version of (something that uses HTML) that doesn't support Python 3.9+, I'm not sure, but forcing sphinx>=4 or something like that will likely fix the problem. Downgrading to Python 3.8 for the docs would fix it, too, but that's the wrong way to initially try to fix it.

I would highly recommend enabling PR readthedocs builds (in the readthedocs settings), they are very handy for catching bugs in the docs builds.

Also, it looks like "latest" hasn't built in a year or more, I'm guessing it was never changed to main from master, perhaps? It makes "latest" much older than "stable".

Been looking at nox and I believe it suites one of our projects needs which is currently using tox, though I would prefer to have more leeway, hence considering Nox.

I'd prefer not to have a noxfile.py file on the root of our repo.

Would you be willing to accept a PR which still defaults to noxfile.py but can look for alternative paths?

At first I though about .nox/noxfile.py but I guess nuking the .nox directory to delete the virtualenvs is something users do a lot, so, perhaps:

• .noxdir/conf.py for linux, ,_noxdir/conf.py for windows?
• .noxconf/conf.py? I guess I would even be ok with a .noxfile without the .py extension.

Of course, the purpose is not having to pass the alternate config on the nox CLI.

Look at setup.cfg and/or pyproject.toml for a nox section where we can then define the path to the noxfile.py?

Anyway, totally open for the alternative, but I wanted to ask before I set out to add support and it just gets rejected.

Describe the bug

Current logic to determine which python interperter to use will use whichever is on the current PATH, which can be a virtual environment's python (venv or virtualenv) or a system installation.

This can be problematic when creating new virtual environments, as pipx and probably others like pipenv must do.

How to reproduce

Run pipx's unit tests. Clone pipx, then run nox.

>> nox
nox > Running session unittests-3.6
nox > Creating virtualenv using python3.6 in .nox/unittests-3-6
nox > pip install .
nox > python -m unittest discover
E
======================================================================
ERROR: tests.test_pipx (unittest.loader._FailedTest)
----------------------------------------------------------------------
ImportError: Failed to import test module: tests.test_pipx
Traceback (most recent call last):
  File "/usr/lib/python3.6/unittest/loader.py", line 428, in _find_test_path
    module = self._get_module_from_name(name)
  File "/usr/lib/python3.6/unittest/loader.py", line 369, in _get_module_from_name
    __import__(name)
  File "/home/csmith/git/pipx/tests/test_pipx.py", line 17, in <module>
    assert not hasattr(sys, "real_prefix"), "Tests cannot run under virtualenv"
AssertionError: Tests cannot run under virtualenv


----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (errors=1)

Expected behavior

The base python interpreter should be resolved rather than the virtual environment's python interpreter.

Example implementations for interpreter resolution:

• https://github.com/sarugaku/pythonfinder (this could potentially be used by nox but has lots of dependencies, https://github.com/sarugaku/pythonfinder/issues/78)
• https://github.com/tox-dev/tox-venv/blob/master/src/tox_venv/hooks.py
• https://github.com/theacodes/nox/pull/231#issuecomment-518347470 (for Windows)

Note: https://github.com/theacodes/nox/issues/199 suggests using venv will fix this. I think this is necessary but not sufficient to create a new venv from within a virtual environment. (cc @pfmoore)

Closes #72. Add an {envdir}/.shared directory (like @dhermes suggested), and create an API for accesing to it. I'm a bit new to the concept, so tell me if this is what you want :)

CC @theacodes @cjolowicz

To fix #219

TL;DR: Trying to implement the suggestion in https://github.com/theacodes/nox/issues/219#issuecomment-512933886, this PR adds a final check at the end of the property nox.virtualenv._resolved_interpreter which looks for an interpreter called "python" in the PATH, checks whether its --version fits the required version, and returns it as the resolved interpreter if it matches.

Rationale

As described in #219, sessions specifying the interpreter version (e.g. @nox.session(python='3.7')) don't find the existing matching python 3.7 if it is called "python" or "python.exe" and no python launcher ("py.exe") is available.

The same sessions work when not specifying python='3.7', even if the used interpreter is actually python 3.7. If this happens, it makes it harder for collaborators on Unix/Windows to work on cross-platform libraries together (like nox or my current pet project) without temporarily adapting the noxfile to their own system (or their system to the noxfile).

While the mechanisms applied in nox.virtualenvs do follow the Python guidelines, in practice, Anaconda installations on Windows, which are quite popular in my scientific/data-wrangling field, provide neither versioned interpreters (like 'python2', 'python27', 'python3', 'python37') nor a python launcher.

For Anaconda-specific projects, the recent addition of conda environment support to nox is certainly very interesting. However, I am arguing from the perspective of cross-platform library development and would like to be able to provide a noxfile to my project which works on Unix and Windows, be it with Anaconda or with "proper" Python installations.

One could argue that this is not noxs problem and should be fixed in Anaconda (and one would be right), but it is a pretty small addition and would in one step increase the reach for nox to everyone using Anaconda on Windows (which are quite a few people). And it would make it easier for me (and nox ;)) to find Windows contributors also.

Implementation

Added the check (with an extra module-level function for cleanliness), and some parametrised tests. I also fixed two incorrect return value mocks of py.path.local.sysfind (which returns None on not found, not False like in the mock return value), which my code initially tripped over because it checked for None.

As the body of _resolved_interpreter is essentially a string of if-else conditionals, creating good tests was a bit of a challenge. I hope they're not too ugly. :)

I'm using the @parametrize decorator to create a build matrix, but i've got certain combinations I wish to exclude.

right now i'm using a little escape hatch

if valid_combination(*deps):
    run_tests(session, *deps)
else:
    session.skip("unsupported combination")

would be nice if Nox could provide an API for adding or removing 'cells' from the matrix (similarly to what you can do with github actions)

Summary

This PR adds support for a different backend, venv. It adds a keyword argument to the VirtualEnv class, which defaults to False and is only true when the nox session has venv_backend=True.

It also updates the resolution of the Python path, since using venv alone does not fix issues when creating a venv from within a virtual environment.

The path resolution is modified to determine if a virtual environment is being used. If so, it tries to find the desired Python interpreter version in the base_prefix rather than anywhere on the system's PATH. Note that Windows was not tested, and probably will require some more changes.

Test Plan

# Create and enter virtual environment, then
cd ~/git/nox
pip install -e .
cd ~/git/pipx
# modify pipx's noxfile.py to have `venv_backend='venv'` for the unittests session
nox -s unittests-3.6  # tests pass

Additional context

prefix: A string giving the site-specific directory prefix where the platform independent Python files are installed

https://docs.python.org/3/library/sys.html#sys.prefix

base_prefix: Set during Python startup, before site.py is run, to the same value as prefix. If not running in a virtual environment, the values will stay the same; if site.py finds that a virtual environment is in use, the values of prefix and exec_prefix will be changed to point to the virtual environment, whereas base_prefix and base_exec_prefix will remain pointing to the base Python installation (the one which the virtual environment was created from).

https://docs.python.org/3/library/sys.html#sys.base_prefix

Tox's implementation for venv support is included as a plugin in an additional package: https://github.com/tox-dev/tox-venv/blob/master/src/tox_venv/hooks.py

fixes https://github.com/theacodes/nox/issues/199 cc @pfmoore

closes #583

I picked up @henryiii's excellent work on #592, resolved the conflicts and the issue he described with shutil.which expecting a .exe.

This should hopefully be everything needed to drop py.path, @henryiii I'd be grateful if you could check this out to see if I've solved the issue adequately as you have more of the context than me 🙂

Is it possible to improve --error-on-missing-interpreters with "principle of least surprise" in mind? We don't want onerous failures during local dev, but the two changes are proposed:

• Mention the --error-on-missing-interpreters flag in the error / warning / success message if an interpreter was skipped
• Change --error-on-missing-interpreters to default ON (instead of OFF) if we've detected the code is in CI (CI=true) or in an automated environment (sys.stdout.isatty()==False)

Original Content (Original title: Test suite skipped with error "Python interpreter 3.8 not found.)

Describe the bug

The desired Python version was not available, the test suite is skipped entirely.

2020-08-21T17:46:46.1946078Z ##[group]Run nox
2020-08-21T17:46:46.1946291Z nox
2020-08-21T17:46:46.1990422Z shell: /bin/bash -e {0}
2020-08-21T17:46:46.1990565Z env:
2020-08-21T17:46:46.1990705Z   pythonLocation: /opt/hostedtoolcache/Python/3.7.8/x64
2020-08-21T17:46:46.1990822Z ##[endgroup]
2020-08-21T17:46:46.2954365Z Running session tests-3.8
2020-08-21T17:46:46.3002157Z Session tests-3.8 skipped: Python interpreter 3.8 not found.

How to reproduce

import nox

@nox.session(python=["3.7"])
def tests(session):
    """Run pytest suite"""
    session.create_tmp()
    session.install("-r", "requirements-test.txt")
    tests = session.posargs or ["tests/"]
    session.run("pytest", *tests)

# TODO: add lint, type checking, etc.

$ cat .github/workflows/data_prep_tools_test.yml 
# This workflow will install Python dependencies, run tests.
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-python-with-github-actions

name: test

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]
    
defaults:
  run:
    working-directory: tools

jobs:
  build:

    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: [3.7]

    steps:
    - uses: actions/[email protected]
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/[email protected]
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        pip install nox
    - name: Test with nox
      run: |
        nox

Expected behavior

non-zero exit code

How would this feature be useful?

I would like to be able to use micromamba along with mamba/conda/venv. It's a lot smaller/faster than mamba (that's why we use it in our Gitlab CI flows), and to my knowledge lacks no functionality that is required for nox backend purposes.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Anything else?

No response

Current Behavior

Tox 4 is now in release candidate 1 and it might make sense to take a look at how to support it here in tox_to_nox. Right now, tests results are:

FAILED tests/test_tox_to_nox.py::test_trivial - AttributeError: module 'tox.c...
FAILED tests/test_tox_to_nox.py::test_skipinstall - AttributeError: module 't...
FAILED tests/test_tox_to_nox.py::test_usedevelop - AttributeError: module 'to...
FAILED tests/test_tox_to_nox.py::test_commands - AttributeError: module 'tox....
FAILED tests/test_tox_to_nox.py::test_deps - AttributeError: module 'tox.conf...
FAILED tests/test_tox_to_nox.py::test_env - AttributeError: module 'tox.confi...
FAILED tests/test_tox_to_nox.py::test_chdir - AttributeError: module 'tox.con...
FAILED tests/test_tox_to_nox.py::test_dash_in_envname - AttributeError: modul...
FAILED tests/test_tox_to_nox.py::test_non_identifier_in_envname - AttributeEr...
FAILED tests/test_tox_to_nox.py::test_descriptions_into_docstrings - Attribut...

All failures caused by

def main() -> None:
        parser = argparse.ArgumentParser(description="Converts toxfiles to noxfiles.")
        parser.add_argument("--output", default="noxfile.py")
    
        args = parser.parse_args()
    
>       config = tox.config.parseconfig([])
E       AttributeError: module 'tox.config' has no attribute 'parseconfig'

Expected Behavior

It would be nice to have nox compatible with tox 4 when they release a final version.

Steps To Reproduce

Run nox tests with tox==4.0.0rc1

Environment

- OS:
- Python:
- Nox:

Anything else?

No response

How would this feature be useful?

It'd save a few keystrokes and would work as a default for --pythons.

Describe the solution you'd like

Check for NOXPYTHON environment variable:

NOXPYTHON=3.11 nox -s tests
NOXPYTHON=3.10,3.11 nox -s tests

While we're at it, it might make sense to also add env vars for --extra-pythons and --force-pythons.

Describe alternatives you've considered

Continue using --pythons, or include the Python version in NOXSESSION, i.e.

NOXPYTHON=tests-3.10

but this couples the default session with a Python version

Anything else?

No response

How would this feature be useful?

When providing a Nox configuration for a team that may not be familiar with Nox, it would be good to give a simple command to list tags rather than have them look in the nox configuration or document them seperately.

Describe the solution you'd like

A new cli option, list-tags, which will list sessions by tag

$ nox --list-tags

lint:
  * flake8 -> Run flake8
  * pylint -> Run pylint
format:
  * black -> Run black
  * isort -> Run isort
check:
  * black -> Run black
  * flake8 -> Run flake8
  * isort -> Run isort 
  * pylint -> Run pylint
  * test -> Run tests

Describe alternatives you've considered

Tags could be added to the current list output, but, for larger projects, it may be unclear which sessions fall under which tags. Perhaps this could be solved by coloring the tags, but I think a tag view for list would be more useful.

Instead of a separate command line option, it could be added to the bottom of the existing output.

Anything else?

No response

Current Behavior

When running a session with a lot of dependencies with --verbose, Nox will appear to hang after calling pip. Then will return all of the pip output at once. This breaks one of the fundamental rules of user interfaces, never make the user wonder what is happening.

Expected Behavior

Nox should provide realtime output from pip when --verbose is passed. There are several ways to do this. (Don't capture stdout/stderr, capture and print in loop until process is complete, call pip through Python). Probably this should be solved more generally than pip because there are other long-running commands people will want to run.

Steps To Reproduce

1. Create nox session with a lot of dependencies
2. Run nox --verbose -s <session>
3. Observer hang until pip completes

Environment

- OS: Ubuntu 20.04
- Python: 3.8
- Nox: 2022.8.7

Anything else?

No response