wntrblm / nox

Flexible test automation for Python

Nox

Flexible test automation with Python

• Documentation: https://nox.readthedocs.io

• Source Code: https://github.com/wntrblm/nox

Overview

nox is a command-line tool that automates testing in multiple Python environments, similar to tox. Unlike tox, Nox uses a standard Python file for configuration:

import nox


@nox.session
def tests(session: nox.Session) -> None:
    session.install("pytest")
    session.run("pytest")

@nox.session
def lint(session: nox.Session) -> None:
    session.install("flake8")
    session.run("flake8", "--import-order-style", "google")

Installation

Nox is designed to be installed globally (not in a project virtual environment), the recommended way of doing this is via pipx, a tool designed to install python CLI programs whilst keeping them separate from your global or system python.

To install Nox with pipx:

pipx install nox

You can also use pip in your global python:

python3 -m pip install nox

You may want to user the user-site to avoid messing with your Global python install:

python3 -m pip install --user nox

Usage

List all sessions

nox -l/--list

Run all sessions

nox

Run a particular session

nox -s/--session test

Checkout the docs for more! 🎉

Contributing

Nox is an open source project and welcomes contributions of all kinds, checkout the contributing guide for help on how to help us out!

All contributors must follow the code of conduct and be nice to one another! 😃

nox's Issues

[Future] Consider the possibility of different types of sessions/workflows/tasks

Right now, Nox is pretty specialized as a Python automation tool - For example, it by default creates virtualenvs, session.install installs Python packages, etc.

However, there could be usefulness in making nox a bit more generic. I'd like to use this issue as a discussion around what a more generic Nox would look like. This touches on topics like plugins as well.

Context: As Google Cloud works on automating parts of client library maintenance, a useful automation tool that works across languages might be useful. Whether Nox ends up being used for that purpose, it's still a useful conversation to have long term about this tool.

Some thoughts

Session classes

What if we make it possible to have different "classes" of sessions? For example, today's sessions could be used like this:

@nox.session(nox.PythonSession)
def run_py_tests(session):
    session.install('py.test')  # installs Python packages using pip
    session.run('py.test', 'tests')

We could of course make PythonSession the default so that noxfiles aren't needlessly noisy, and/or have a nox.default_session_class = nox.PythonSession.

Even for just Python automation this is useful, imagine:

# uses pipenv instead of virtualenv, and automatically installs everything in pipfile.
@nox.session(nox.PipenvSession)
def run_py_tests(session):
    session.run('py.test', 'tests')

But this becomes super interesting with other workflows. Imagine replacing this with this:

@nox.session(googleapis_nox.SplicerSession)
def regenerate_gapic(session):
    # Clones googleapis, installs artman, runs it to generate logging gapic.
    session.artman('google/logging/artman_logging.yaml', language='python')

    # Splices the generated client into the repository.
    import_pkg = 'logging_v2'
    session.copy('/docs')
    session.copy(f'/google/cloud/{import_pkg}')
    session.copy('/tests/unit/gapic')
    session.copy('/tests/system/gapic')

libnox

Nox has a lot of useful low-level features that aren't easy to access outside of nox. Independent of other topics, we should consider splitting these lower-level features into a stable libnox that can be used to create the nox tool. We can then use libnox to create any number of specialized automation tools.

Allow nox sessions to run in parallel

In repos like python-docs-samples, there are a ton of samples in directories that don't depend on each other. It would be nice if there was a parallel_parametrize option or something to spin up some threads to run these sessions in parallel.

Add AppVeyor badge to README

If you feel like you are getting too many badges, you can make a table like pytest-cov does.

Return non-zero exit code if any session fails.

When using `-r`, the hashed env name is never printed

nox > Running session unit_tests(python_version='3.6')
nox > The virtualenv name was hashed to avoid being too long.
nox > Re-using existing virtualenv.

vs.

nox > Running session unit_tests(python_version='3.6')
nox > The virtualenv name was hashed to avoid being too long.
nox > virtualenv /path/to/.nox/775478c5 -p python3.6

Support a "presession"/"postsession" session

This is a somewhat half-baked idea. For the google-cloud-python config, we have a parametrized 'tests' session, that collects coverage information over several different parametrized runs, and a non-parametrized 'cover' session that collects everything and creates a single coverage report. It would be nice if we could make some function or session that runs once after every 'tests' session is done, so that 'nox -s tests' produces the coverage report by itself.

This could be done really grossly by a variety of means: Giving the 'cover' session a mangled name like 'tests_post', adding a new kind of 'parametrize' that just appends a single new session instead of doing an MxN product of all previous parameters, or passing in a 'is_last_parameter' to the tests session.

This can be done right now by something like:

@nox.session
@nox.parametrize('version', ['2.7', '3.4', '3.5', '3.6'])
@nox.parametrize('subdir', ['runtime_builders','otherdir'])
@nox.parametrize('coverage_report', [False, True])
def tests(session, version, subdir, coverage_report):
  if not coverage_report:
    .. do normal tests
  elif version == '2.7' and subdir == 'runtime_builders': # FRAGILE
    .. produce coverage report

Passing env= to session.run seems to be broken

With

@nox.session
def file_issue(session):
    session.interpreter = 'python3.6'
    session.run(
        'bash', '-c', 'echo $SOME_ENV',
        env={'SOME_ENV': 'Hello'})

produces

$ nox -s file_issue
nox > Running session file_issue
nox > Re-using existing virtualenv at .../.nox/file_issue.
nox > chdir ...
nox > bash -c echo $SOME_ENV

nox > Session file_issue successful. :)

but if I manually set the variable it "works"

$ SOME_ENV=now-i-am nox -s file_issue
nox > Running session file_issue
nox > Re-using existing virtualenv at .../.nox/file_issue.
nox > chdir ...
nox > bash -c echo $SOME_ENV
now-i-am
nox > Session file_issue successful. :)

Add `.nox` to GitHub's .gitignore

Thank you for nox. I made a PR to add .nox to GitHub's .gitignore file. But, I couldn't find a place in the documentation where it talks about it. Is that correct? if so, would a PR be welcome?

`tox-to-nox` is missing dependencies (tox, jinja2) for v0.18.2

Just installed nox and learned, that extra tox-to-nox is not provided any more.

It was nice to find out, it is already included, but running it fails with complains about missing jinja2 and then tox dependencies.

After installing these dependencies, the tox-to-nox command worked well.

Consider adding the jinja2 and tox to packages being required (and installed) by the package.

Allow configuration of virtualenv names

Hashing the virtualenv names makes it inconvenient to spelunk into them later, I would find it more useful to allow for customizing names for too-long session virtualenvs.

Support/Bug: nox not creating virtualenv

import nox


@nox.session
def hello(session):
    session.interpreter = "python2.7"

    session.run("python3", "-m", "flit", "build")
    files = glob.glob("./dist/*.whl")
    if not files:
        session.error("Could not find any built wheels.")
    session.install(*files)
    session.install("-r", "tools/reqs/test.txt")

    session.run("pytest", *session.posargs)

Somehow, the above script results in nox not even building a virtualenv.

$ nox -s hello
nox > Running session hello
nox > Could not find any built wheels.
nox > Session hello aborted.

If nox is composing the list of commands before actually executing them, it would result in an empty call to install. Here, however, it isn't even creating the virtual environment.

---

Honestly, I'm not sure what's happening here. If I comment out the second install line, somehow nox executes the session, but with -r tools/reqs/test.txt, which is exactly what was commented out. :/

Add ability to specify which Python versions to run with from the command line.

Context: https://github.com/theacodes/nox/pull/94/files/ad56baafab381ef967f504b1c2d9dc30d61bc96e#r205984653

Add concept of "optional" parameter

For example, if I wanted to (as a nox user) impl. my own support for arch (as in #60), then I'd want to do something like:

$ nox -s "unit(py='2.7', arch='32')"

but I wouldn't want

$ nox -s "unit(py='2.7')"

to run over all choices of arch, I would just want arch to be ignored (arch would only be relevant on OS X).

Since nox has a lot of pytest-like interfaces, I threw together an example of how pytest deals with optional test cases with pytest.mark.parametrize. (Isn't a perfect mapping.)

---

NOTE: @jonparrott and I discussed this earlier this week, I just never filed an issue

Locate Python interpreters on Windows via the `py.exe` launcher

On Windows, the versioned Python executables (python3.6 and similar) don't exist. So to set a specific interpreter needs a hard-coded path (as far as I can tell from some simple experiments). The nox code says that it is based on the tox code, but it omits the locate_via_py step in tox that uses the py.exe launcher to resolve names like python3.6.

Could this be added, as the "standard" location is wrong for Python 3.6+, and if the user overrides the standard location, the current nox code won't handle this whereas the launcher will?

I'm willing to try to put together a PR if needed.

Pass through the architecture on OS X

This allows nox to test on both 32-bit and 64-bit architectures.

With a Python script that is architecture aware (check.py) it's possible to write a nox config that sends along the "correct" arch -32 prefix for commands. (Unfortunately prepending arch -32 to a command doesn't show up in sys.argv.)

---

Running it with my magic trick turned on does the right thing:

$ /Library/Frameworks/Python.framework/Versions/3.6/bin/nox -s 'check(do_hack=True)'
nox > Running session check(do_hack=True)
nox > /Library/Frameworks/Python.framework/Versions/3.6/bin/python -m virtualenv ...
nox > chdir ${HOME}/nox-bug-report
nox > arch -64 python check.py
Architecture: 64-bit
      Prefix: ${HOME}/nox-bug-report/.nox/check-do_hack-true/bin/..
 Real prefix: /Library/Frameworks/Python.framework/Versions/3.6
nox > Session check(do_hack=True) was successful.
$
$ # Re-use
$ arch -32 \
>   /Library/Frameworks/Python.framework/Versions/3.6/bin/nox -s 'check(do_hack=True)' -r
nox > Running session check(do_hack=True)
nox > Re-using existing virtualenv at ${HOME}/nox-bug-report/.nox/check-do_hack-true.
nox > chdir ${HOME}/nox-bug-report
nox > arch -32 python check.py
Architecture: 32-bit
      Prefix: ${HOME}/nox-bug-report/.nox/check-do_hack-true/bin/..
 Real prefix: /Library/Frameworks/Python.framework/Versions/3.6
nox > Session check(do_hack=True) was successful.

Running it in the default mode for nox doesn't pass through the architecture

$ /Library/Frameworks/Python.framework/Versions/3.6/bin/nox -s 'check(do_hack=False)'
nox > Running session check(do_hack=False)
nox > /Library/Frameworks/Python.framework/Versions/3.6/bin/python -m virtualenv ...
nox > chdir ${HOME}/nox-bug-report
nox > python check.py
Architecture: 64-bit
      Prefix: ${HOME}/nox-bug-report/.nox/check-do_hack-false/bin/..
 Real prefix: /Library/Frameworks/Python.framework/Versions/3.6
nox > Session check(do_hack=False) was successful.
$
$ # Re-use
$ arch -32 \
>   /Library/Frameworks/Python.framework/Versions/3.6/bin/nox -s 'check(do_hack=False)' -r
nox > Running session check(do_hack=False)
nox > Re-using existing virtualenv at ${HOME}/nox-bug-report/.nox/check-do_hack-false.
nox > chdir ${HOME}/nox-bug-report
nox > python check.py
Architecture: 64-bit
      Prefix: ${HOME}/nox-bug-report/.nox/check-do_hack-false/bin/..
 Real prefix: /Library/Frameworks/Python.framework/Versions/3.6
nox > Session check(do_hack=False) was successful.

Running this with the wrong Python binary is a "not gonna happen":

$ arch -32 ${HOME}/.pyenv/versions/3.6.2/bin/nox -s check
arch: posix_spawnp: ${HOME}/.pyenv/versions/3.6.2/bin/nox: Bad CPU type in executable

This is relevant because it might mean you don't have to check if the Python binary is_dual_architecture().

virtualenv creation line is hilariously long after #47

For example:

nox > Running session functional(python_version='2.7')
nox > /home/dhermes/.pyenv/versions/3.6.2/bin/python3.6 -m virtualenv /home/dhermes/bezier/.nox/functional-python_version-2-7 -p python2.7
nox > chdir /home/dhermes/bezier

@jonparrott DYT anything should be done or it's fine?

nox start up errors

I don't know what I did, but I can't start nox any more.
I tried pip uninstall and then reinstalling
I tried restarting the computer (using Ubuntu 16.04)

This file has 0 bytes, ~/.local/venvs/nox-automation/bin/python
and I tried substituting that with #!usr//bin/python

This is the error message that I get
from: can't read /var/mail/nox.main
~/.local/bin/nox:10: syntax error near unexpected token ('`

~/.local/bin/nox:10: sys.argv[0] = re.sub(r'(-script.pyw?|.exe)?$', '', sys.argv[0])'

Any other suggestions?
Thanks.

If `session.virtualenv = False`, then `session.interpreter` is not "respected"

For example:

import nox


@nox.session
def foo(session):
    session.virtualenv = False
    session.interpreter = 'python3.6'
    command = 'import sys; print(sys.executable)'
    session.run('python', '-c', command)

results in

C:\Users\dhermes>venv\Scripts\nox.exe -s foo
nox > Running session foo
nox > chdir C:\Users\dhermes
nox > python -c import sys; print(sys.executable)
C:\Users\dhermes\AppData\Local\Continuum\Miniconda2\python.EXE
nox > Session foo was successful.

I expected to see

C:\Users\dhermes\AppData\Local\Programs\Python\Python36\python.EXE

as the value of sys.executable.

@jonparrott indicated that this could be fixed in which.

Publish changelog

Readers need to find the changes, ideally in the docs. If not, then the minimum would be to annotate the tags here on Github into actual releases documenting bugs fixed, features added, and particularly backward incompatibilities.

Make nox imperative, not declarative.

Because Nox collects all commands before executing them it's hard to do any sort of branching logic in sessions. We should consider changing Nox to be imperative. I argue that this is closer to how people actually conceptualize the session.

There is one big problem with this approach right now: the virtualenv configuration. Presently, you can tell Nox how to make your virtualenv by setting properties on the session:

@nox.session
def tests(s):
    s.interpreter = 'python3.6'

Unfortunately we can't do this if we switch to imperative. There are two options I can think of:

Option 1: Remove all of the properties and add a new imperative command called virtualenv to the session. It will create the virtualenv and then all following commands will use the virtualenv configuration:

@nox.session
def tests(s):
    s.virtualenv('python3.6')
    s.run('python' ,'--version')   # uses Python in the virtualenv.

This unfortunately will break almost every nox script currently in existence, but the "fix" is relatively straightforward and I could maybe even write a tool that will migrate for you. Also, the change in behavior from declarative to imperative might break some people.

Option 2: Do some magic. Almost all nox scripts in existence setup the virtualenv properties before calling install or run. We could make nox create the virtualenv on the first call to either install or run. I'm not a huge fan of this, but it would be mostly backwards-compatible.

/cc @pradyunsg @lukesneeringer @dhermes

Allow virtualenv-less sessions

Can nox be used to run multiple sessions in a certain order?

I would love to be able to run nox or nox -r and have it run tests, lint, and extract and compile translations.

The way I am thinking of doing this is providing two sessions for the two sets of command in my translation guide.

• nox -s extract_translations would run pybabel extract -F babel.cfg -o messages.pot . followed by pybabel update -i messages.pot -d ./translations
• nox -s compile_translations would run pybabel compile -d ./translations

The problem with doing it this way is that I want to be certain that the extract_translations session runs before the compile_translations session. I could combine them all in one, but in general I'd want to be able to extract first, edit the output in POEdit and then compile, but if I'm being lazy / don't want to translate everything right away I'd want to run both sessions.

Maybe I shouldn't worry about this and just do the extract_translations session for now? That's the most important one to run, I think, to make sure translators have the latest messages to work with.

Python files break directory parametization

As mentioned offline,

@nox.parametrize('sample', ALL_SAMPLE_DIRECTORIES)
def session_lint(session, sample):
    """Runs flake8 on the sample."""
    session.install('flake8', 'flake8-import-order')

not all sessions are getting found if there's another Python file in same directory as nox.

Not a big deal, just creating tracking issue.

Add a "shared cache" subdirectory of `.nox` and add API for accessing it

@theacodes And I have discussed this before but I keep forgetting to file an issue.

A few applications:

• Python extensions with long compile times can cache object files and other built resources there (can share object files across different Python versions)
• Store hashes of non-Python source files, so that way the .so/.pyd modules in an editable install can be updated when the source changes

Windows failures

This is a tracking bug for this AppVeyor failure, which initially looks to be a problem with nox (since @nox.session and @nox.parametrize ought to exist).

I am currently attempting to rebuild with the nox.py file renamed to noxfile.py to see what happens.

Relax dependency version requirements

When a Python version isn't installed, nox fails (without going on to the next session)

I have a nox.py file for testing my project, and I want to specify all of the Python versions I support. That's easy enough, and works fine for CI. But when running nox on my local PC, I don't have all those Python versions installed. As a result, I get RuntimeError: Unable to locate Python interpreter "python3.5". when I run plain nox, and the run stops there.

Two things would be a huge improvement:

1. Respect the --stop-on-first-error setting, and by default skip sessions that can't be created because the Python interpreter isn't installed.
2. Avoid the ugly traceback, and simply print an error "Python interpreter XXX not installed - skipping".

Manually specifying just the environments I want to run isn't really practical (apart from anything else, the syntax for specifying a parametrised environment is much more verbose than tox's -e py36).

`-r` flag should not skip `session.install()`

It seems the concept --reuse-existing-virtualenvs is getting mixed up with _should_install_deps.
Here is where the skip happens.

But if the virtualenv already exists and the deps have already been installed, then pip install --upgrade is usually a no-op.

The one exception (which is what past-tense @jonparrott may have been thinking) is that if the user has installed the "current" package, but not in editable (-e) mode, then it may confuse the nox users.

Parametrization

Building a bit on https://www.reddit.com/r/Python/comments/48qz7w/nox_virtualenvtest_automation_similar_to_tox_but/d0m3q4l, another way to handle parametrization is like this:

@nox.parametrize('python', ['/path/to/python2.7', '/path/to/python3.5', '/path/to/pypy', ...], ids=['py27', 'py34', 'pypy', ...])
@nox.parametrize('django', ['1.9', '1.8', ...])
def session_test(session, python, django):
   ...

This is quite identical to pytest parametrization.

The advantage over your initial proposal is that you can customize the display names (via ids).

Also, would be good to know how far and where you'd take nox. IOW, what goals does nox have?

PS. There is no contribution guide.

`nox` always exits with 0, even if a test fails.

See repro. It is making my builds pass when they didn't mean to.

H/T to @will-e-p for being my OS X guinea pig.

Migration from tox.ini

Just putting this out here for consideration.

It would be nice if there was some tool that could convert tox.ini to a nox.py.

This would mean there needs to be some feature parity with tox (related: #1 (comment))

For me this isn't so important but it would help with nox's adoption I think.

Add `session.skip(reason)`

See googleapis/google-cloud-python#3475

This way sessions can

• Fail
• Succeed
• Be Skipped

Add support for later/lazy evaluation of Python code

For example if one command generates files and a second command needs to rely on them:

session.run('do', 'thing', 'to', 'files', nox.lazy(glob.glob, *args, **kwargs))

Be less explicit about string matching in parametrized sessions?

$ nox -l
Available sessions:
* unit_tests(python_version='2.7')
* unit_tests(python_version='3.4')
* unit_tests(python_version='3.5')
* unit_tests(python_version='3.6')
* lint
* cover
$ nox -e 'unit_tests(2.7)'
nox > Sessions unit_tests(2.7) not found.
$ nox -e 'unit_tests(python_version=2.7)'
nox > Sessions unit_tests(python_version=2.7) not found.
$ nox -e 'unit_tests(python_version="2.7")'
nox > Sessions unit_tests(python_version="2.7") not found.
$ nox -e "unit_tests(python_version='2.7')"
nox > Running session unit_tests(python_version='2.7')
...

Add --nocolor flag for plain text output

I mostly look at nox output in text files, in contexts that don't render ansi escape sequences. So the output looks like this:

Step #7: ^[[36mnox > ^[[32mSession unit(py='3.6') was successful.^[[0m
Step #7: ^[[36mnox > ^[[33mRan multiple sessions:^[[0m
Step #7: ^[[36mnox > ^[[32m* unit(py='2.7'): success^[[0m
Step #7: ^[[36mnox > ^[[32m* unit(py='3.4'): success^[[0m
Step #7: ^[[36mnox > ^[[32m* unit(py='3.5'): success^[[0m
Step #7: ^[[36mnox > ^[[32m* unit(py='3.6'): success^[[0m
Step #7: ^[[36mnox > ^[[31m"Sessions not found: unit(py='2.7'), unit(py='3.4'), unit(py='3.5'), unit(py='3.6')"^[[0m
Step #7: ^[[36mnox > ^[[33mRunning session unit(py='2.7')^[[0m
Step #7: ^[[36mnox > ^[[34m/usr/bin/python -m virtualenv /home/vmagent/app/google-cloud-python/.nox/unit-2-7 -p python2.7^[[0m
Step #7: ^[[36mnox > ^[[36mchdir /home/vmagent/app/google-cloud-python/bigtable^[[0m
Step #7: ^[[36mnox > ^[[34mpip install --upgrade mock pytest pytest-cov ../api_core ../core^[[0m
Step #7: ^[[36mnox > ^[[34mpip install --upgrade -e .^[[0m
Step #7: ^[[36mnox > ^[[34mpy.test --quiet --cov=google.cloud.bigtable --cov=tests.unit --cov-append --cov-config=.coveragerc --cov-report= --cov-fail-under=97 tests/unit^[[0m

It would be nicer if there was a command line flag to inhibit escape sequences in the output.

Add contributing.md

Importing issues w/ nox.py

I feel like I'm missing something obvious, but the recommendation to put configuration in a nox.py file isn't working for me (at least on my system).

Using the example from the docs:

$ cat nox.py
import nox

@nox.session
def tests(session):
    session.install('py.test')
    session.run('py.test')

@nox.session
def lint(session):
    session.install('flake8')
    session.run('flake8', '--import-order-style', 'google')

And the latest version:

$ pip freeze | grep nox
nox-automation==0.18.1

This is what I get:

$ nox
Traceback (most recent call last):
  File "/private/tmp/env/bin/nox", line 7, in <module>
    from nox.main import main
  File "/private/tmp/nox.py", line 3, in <module>
    @nox.session
AttributeError: module 'nox' has no attribute 'session'

As far as I'm aware this is the expected importing behavior when a local file shadows a 3rd party module... what am I missing?

Restrict to squash and merge

@jonparrott When convenient, can you restrict merges to always use "squash and merge", to mirror most of our other repos? I also assert that the master branch should have, at minimum, review required turned on.

`venv/bin/pip install` breaks when __PYVENV_LAUNCHER__ is present

... rather than just getting virtualenv from PATH. I am currently having some hard-to-debug issues on Travis CI (OS X, with python.org CPython installers) right now (e.g.) partly because the system virtualenv is not what I want nox to use. (Also relevant)

Allow passing env to `session.install()`

For example, if I want to build a C extension in "debug" mode, I have to swap

session.install('.')

for

session.run('pip', 'install', '--upgrade', '.', env={'DEBUG': 'True'})

For context, here are the current InstallCommand constructor and SessionConfig.install().

Delete v0.8.0 release notes draft?

Seems accidental?

(Also, should 0.18.1 get release notes?)

BUG: `nox` crashes if a parameter name collides with a session name

I would not rate this bug as very severe.

import nox


@nox.session
@nox.parametrize('py', ['2.7', '3.5', '3.6'])
def py(session):
    session.virtualenv = False
    session.interpreter = 'python{}'.format(py)
    command = 'import sys; print(sys.executable)'
    session.run('python', '-c', command)

results in

C:\Users\dhermes>venv\Scripts\nox.exe -s "py(py='2.7')"
nox > Running session py(py='2.7')
Traceback (most recent call last):
  File "C:\Users\dhermes\venv\Scripts\nox-script.py", line 11, in <module>
    load_entry_point('nox-automation==0.18.1', 'console_scripts', 'nox')()
  File "C:\Users\dhermes\venv\lib\site-packages\nox\main.py", line 107, in main
    tasks.final_reduce,
  File "C:\Users\dhermes\venv\lib\site-packages\nox\workflow.py", line 44, in execute
    return_value = function_(*args, global_config=global_config)
  File "C:\Users\dhermes\venv\lib\site-packages\nox\tasks.py", line 175, in run_manifest
    result = session.execute()
  File "C:\Users\dhermes\venv\lib\site-packages\nox\sessions.py", line 296, in execute
    self._create_config()
  File "C:\Users\dhermes\venv\lib\site-packages\nox\sessions.py", line 249, in _create_config
    self.func(self.config)
  File "C:\Users\dhermes\venv\lib\site-packages\nox\_parametrize.py", line 80, in call_wrapper
    return func(*args, **kwargs)
TypeError: py() got an unexpected keyword argument 'py'

Windows interpreters

Using nox on Windows with custom interpreters fails, because the virtualenv is passed -p pythonX.Y, and that is not the correct thing on Windows.

I am not entirely sure what the right way to handle this is. Tox does this, which nox could basically port into nox. (Nox already has a which function, but it does a subset of this, expects a path, and also does not run on virtualenv creation.)

Alternatively, nox could expose a function (e.g. nox.path.resolve(maj, min) that would return the appropriate string, which would have to be manually called and assigned to session.interpreter. That would make this behavior explicitly opt-in.

This can be worked around in nox now (since nox.py is a Python script), but is painful for my use case because I would have to copy this to tons of files. Thoughts?

Better error message for invalid session names

To reproduce:

• git clone google-cloud-python
• cd google-cloud-python
• nox -f container/nox.py -e "unit(py='2.7')"

Actual result:

nox > "Sessions not found: unit(py='2.7')"

Desired result:

Something with the word "ERROR" or "FAIL". Ideally something with the name of the nox.py file and/or current directory.

The actual error message is red on the terminal, but when I was looking at it in a log file, everything is just unrendered escape sequences that I mentally filter out.

Add a default session list

Invoking nox with no command line arguments runs every session. It would be useful if the nox.py could specify a default list of sessions to run in that case, for example

nox.default_sessions([ 'lint', 'tests' ])

Add a list of projects using Nox to the documentation.

• https://github.com/dhermes/bezier
• https://github.com/GoogleCloudPlatform/google-resumable-media-python

Add option to use pyenv instead of virtualenv?

pyenv is an alternative way to create virtualenvs, by installing multiple copies of python (different versions). It uses the pyenv virtualenv syntax instead of virtualenv , and activates with pyenv activate . Should be possible as a config option.

Use virtualenv from the current Python running nox

... rather than just getting virtualenv from PATH.

As @jonparrott mentioned

This would be pretty straightforward, we should just invoke python -m virtualenv

(#44 was originally titled this, but I accidentally repurposed that issue)

Docker integration

Support `python -m nox`

Currently this fails because nox is a package and nox.py doesn't exist.