Use tox for configuration and testing

[guyer]

No description provided.

[tkphd]

tox is a generic virtualenv management and test command line tool you can use for:

• checking that your package installs correctly with different Python versions and interpreters
• running your tests in each of the environments, configuring your test tool of choice
• acting as a frontend to Continuous Integration servers, greatly reducing boilerplate and merging CI and shell-based testing.

[tkphd]

The benefit being that tox lets you run the tests through both py27 and py38 with just one tool, yeah?

[guyer]

@tkphd that, and a lot of packages (pytest, flake8, ...) are willing to look in tox.ini for their configuration, reducing the plethora of configuration files in the main directory.

There's a tox-conda variant, too, which is more relevant for FiPy than for this simple package.

I'm not totally sold on it. It just reports pass/fail, whereas it'd be nice if it interacted with the CircleCI workflow to report, e.g., [py27 FAIL] [py3k PASS].

[tkphd]

LGTM. Tox gives you a "congratulations" smiley!

[tkphd]

Can't decide if the Tox invocations are useful abstractions or obfuscations, but it definitely cleans up the Circle config, and LGTM 👍

[guyer]

@tkphd Thanks. I'm ambivalent about it, too. I added some discussion on using tox. Do you think it's clear and/or sufficient?

[tkphd]

Yes, the extra commentary is valuable.

[wd15]

Just a note that I think everything in the config files can be moved to pyproject.toml, which is superseding setup.cfg as a single place to have all configuration. It's not that important just something to be aware of. You have pytest.ini which could also go in setup.cfg. Also most of the stuff in setup.py could go in setup.cfg. Also tox.ini can probably go in setup.cfg.

[wd15]

Also, I couldn't get tox working with Nix unfortunately. I was just interested if it would work. It's a Nix package, but can't create the environments it seems.

[guyer]

I'm not wedded to tox. I was just going off this warning we get from the FiPy tests:

WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox.

I'll have to do some reading on PEP 518

[tkphd]

That's a good reason to use tox. Strange that tox is available for, but won't run on, Nix.

[wd15]

That's a good reason to use tox. Strange that tox is available for, but won't run on, Nix.

Pip works with a few hacks so no reason why tox wouldn't work with same sort of workarounds.

[guyer]

tox is intertwined with virtualenv. Could that be the issue?

[wd15]

I'm not wedded to tox. I was just going off this warning we get from the FiPy tests:

My comment was nothing to do with Tox really, just how the configuration for the package overall should be done.

WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox.

I'll have to do some reading on PEP 518

It seems like new Python projects have the toml file rather than the cfg file now. I think it's better because it differentiates between build and run time more clearly. Currently if you install something into a new environment and it needs cython in the setup.py you need to separately install cython first. Cython is a sort of requirement that you should get if you install with pip install . (likewise with setuptools etc). That's my impression. I haven't actually used pyproject.toml files.

[wd15]

tox is intertwined with virtualenv. Could that be the issue?

Yes, that's the problem. It probably just requires some environment variables set correctly before entering in the Nix shell. It also messes with PYTHONPATH I think from reading about it. Unfortunately, that then messes with Nix as it (Nix) gets all its Python packages from one ginourmous PYTHONPATH.

[guyer]

It probably just requires some environment variables set correctly before entering in the Nix shell. It also messes with PYTHONPATH I think from reading about it. Unfortunately, that then messes with Nix as it (Nix) gets all its Python packages from one ginourmous PYTHONPATH.

I'll leave those festivities to you.

If pyproject.toml is the modern way to assemble all that configuration info, though, I'm happy to drop this pull request and go back to explicitly calling pytest et al. I was mostly just experimenting with trying to get the configuration of a new project done "right", as opposed to all of the legacy cruft we've built up in FiPy. I already want to backport a whole bunch of things to FiPy that should simplify things a lot.

[wd15]

If pyproject.toml is the modern way to assemble all that configuration info, though, I'm happy to drop this pull request and go back to explicitly calling pytest et al. I was mostly just experimenting with trying to get the configuration of a new project done "right", as opposed to all of the legacy cruft we've built up in FiPy. I already want to backport a whole bunch of things to FiPy that should simplify things a lot.

No, that's not what I meant. Using or not using pyproject.toml is an orthogonal problem to pytest versus tox. Tox looks good. Keep using it. You can put all the Tox config in a setup.cfg or a pyproject.toml. I'm not sure what the benefit of that by itself other than having single file for config.

Doing it "right" on a new project is why I mentioned the toml thing though. I was planning on moving pymks to use this. Currently it uses a setup.cfg. I actually do have the issue of having to import cython in setup.py now so I was thinking of trying the new way. In the setup.py, I hide the cython import so that it's only needed when actually building the extension.

[wd15]

Sorry to carry on. The main problem with setup.py though is that you have to run python to find out about the package, which is a real issue. It was a real problem in Nix I think when dealing with Python projects which required a lot of workarounds. I think this is one of the reasons that they want to move to a full declarative standard.