replace setup.py integration with a warning

[RonnyPfannschmidt]

fixes #375
fixes #330

[FRidh]

to to

[bittner]

@RonnyPfannschmidt Can you please quote the "standard packaging approaches" and "many downstream distributions"? I don't know about any.

The argument sounds strongly biased. We should care about transparency.

Cc @hpk42

[bittner]

Also, discouraging is one thing. I'd prefer to read about the "recommended approach".

[FRidh]

@bittner I agree it sounds biased and should therefore be rephrased. I don't think anyone has a good overview of how downstream distributions deal with this or similar situations. Perhaps we should document this somewhere? But where? And who will keep this up to date, as such information will always lag on the current practices of the distributions.

PEP 426 mentions the following:

python setup.py test : run the distribution's test suite in place given an sdist, source archive or VCS checkout

The distribution means here the package.

Neither this PEP, nor others (as far as I know), mention what the test suite can and cannot cover. Therefore, using tox like that is supposedly fine.

However, as a Python on Nix packager that would very much annoy me and I would argue that

python setup.py test is for testing against the current env, and tox is for testing against multiple envs.

#330 (comment)

[RonnyPfannschmidt]

@bittner the recommended approach is not calling tox from setup.py - it is basically outlined in the rest of the documentation

[hpk42]

In subsequent commits i revised the text. See

https://github.com/tox-dev/tox/blob/master/doc/example/basic.txt#L237

The basic argument is that setup.py test should invoke the eventual test runner, not tox which creates multiple envs and does downloads from the web for it -- i doubt distros are happy about such test behaviour and think several maintainers confirm.

On Tue, Oct 11, 2016 at 04:08 -0700, Frederik Rietdijk wrote:

FRidh commented on this pull request.

-Now if you run::

- python setup.py test

-this will install tox and then run tox. You can pass arguments to tox

-using the --tox-args or -a command-line options. For example::

- python setup.py test -a "-epy27"

-is equivalent to running tox -epy27.
+.. warning::
+

• Integrating tox into setup.py is strongly discouraged as
• it breaks standard packaging approaches as used by many downstream distributions
• which expect setup.py test to to test the current interpreter

@bittner I agree it sounds biased and should therefore be rephrased. I don't think anyone has a good overview of how downstream distributions deal with this or similar situations. Perhaps we should document this somewhere? But where? And who will keep this up to date, as such information will always lag on the current practices of the distributions.

PEP 426 mentions the following:

python setup.py test : run the distribution's test suite in place given an sdist, source archive or VCS checkout

The distribution means here the package.

Neither this PEP, nor others (as far as I know), mention what the test suite can and cannot cover. Therefore, using tox like that is supposedly fine.

However, as a Python on Nix packager that would very much annoy me and I would argue that

python setup.py test is for testing against the current env, and tox is for testing against
multiple envs.

#330 (comment)

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#376