[MIR] dependencies for tox - See LP: #1367016

[Matthias Klose]

These are all needed as B-Ds for tox, which is also a B-D for system-image, which is seeded for Ubuntu Touch.

[Matthias Klose (doko)]

that was seeded. now removed again

[Barry Warsaw (barry)]

Reopening all bug tasks since we need these to be MIR'd for system-image.

http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Barry Warsaw (barry)]

See also LP: #1367041

[Matthias Klose (doko)]

we are trying to not include any "upstream" eco system into main, like seen with maven. where we do it, we have continuous problems updating and fixing issues like with ruby-rails. python-pip tox are build-dependencies only, so please just avoid these during the build.

and the mir for tox seems to be missing here

[Matthias Klose (doko)]

it is my understanding that tox serves two purposes, one is a testing framework, the other doing the testing in a virtual environment. testing in a virtual environment makes sense as long as you don't know your environment, however this is not the case on a buildd or an autopkg test, where the environment is defined by the build dependencies or the test dependencies.

[Barry Warsaw (barry)]

On Sep 09, 2014, at 07:59 AM, Matthias Klose wrote:

>it is my understanding that tox serves two purposes, one is a testing
>framework, the other doing the testing in a virtual environment.

I'd agree with that. The really interesting bits for build-deps I think is
the ability to test under multiple versions of Python, and to provide a
one-command no-guesswork invocation of the test suite. What I mean by that is
that if you see a tox.ini, you know you can run `tox` and not worry about all
the various crazy things people do to run their test suite (and there's *a
lot* of variation there). Sadly, my suggestions to add official metadata for
test suite support to the various PEPs has not been accepted.

>testing in a virtual environment makes sense as long as you don't know
>your environment, however this is not the case on a buildd or an autopkg
>test, where the environment is defined by the build dependencies or the
>test dependencies.

Agreed that the "testing in a virtual environment" is the least interesting
aspect of tox as it relates to building Ubuntu packages. Unfortunately
there's no way to separate out those two aspects of tox.

[Barry Warsaw (barry)]

On Sep 09, 2014, at 02:02 AM, Matthias Klose wrote:

>we are trying to not include any "upstream" eco system into main, like
>seen with maven. where we do it, we have continuous problems updating
>and fixing issues like with ruby-rails. python-pip tox are build-
>dependencies only, so please just avoid these during the build.

I don't know the history of the maven problems, but I don't think pip,
virtualenv, or tox have been very difficult to maintain in either Debian or
Ubuntu. All upstreams are pretty friendly and in the past have actively
addressed issues that we have relating to these packages.

tox is really not an ecosystem tool, it's a testing tool. It happens to run
tests in a virtualenv and *can* use pip (although as a build-time test runner,
especially with pybuild, it won't be able to do anything interesting with
pip).

Ultimately I think we're swimming upstream to deny tox in main, since it's use
is pervasive and growing, and it's the only good one-command, no-guessing way
to run a test suite.

We know the fact that our cross-pocket restrictions, especially for build-deps
is a problem (thus archive reorg). I don't think it will always be possible
to just say "don't use tox to run your test suite" and I don't think it's a
good idea to avoid running a test suite at build time. DEP-8 tests run in
different environments and usually do not run automatically when doing local
testing so they are not a substitute for build-time tests. So I disagree with
prohibiting a common test tool from main.

All that said, in the particular case of system-image, I will see if it's
possible to bypass tox, but I'm not willing to avoid running its test suite at
build time.

[Matthias Klose (doko)]

well you could run these as autopkg tests instead

[Adam Conrad (adconrad)]

06:09 <infinity> Maybe tox just needs a tox-lite that doesn't have the pip/virtualenv bits turned on (and thus, hasn't the dependencies).
06:09 <infinity> Though, without archive reorg, that would still be a forked source package. :/
06:10 <infinity> Oh, unless it doesn't need them at build time, which I suppose it might not.

[Adam Conrad (adconrad)]

Oh, but looking, it very clearly needs pip/venv as build-deps, so yeah, nevermind that as a binary option, it would have to be a new forked source (icky).

[Matthias Klose (doko)]

closing all these as won't fix. We don't have Ubuntu Touch images anymore.