Path: csiph.com!news.redatomik.org!news.neodome.net!news.mixmin.net!news.unit0.net!news.panservice.it!bofh.it!news.nic.it!robomod From: Gordon Ball Newsgroups: linux.debian.maint.python Subject: Re: Python 3 Statsmodels & Pandas Date: Mon, 18 Sep 2017 19:30:01 +0200 Message-ID: References: X-Original-To: debian-python@lists.debian.org X-Mailbox-Line: From debian-python-request@lists.debian.org Mon Sep 18 17:24:44 2017 Old-Return-Path: X-Amavis-Spam-Status: No, score=-9.2 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, LDO_WHITELIST=-5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -6.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 8bit X-Mailing-List: archive/latest/15199 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/735e2fae-8a0b-f82e-73ce-82529d774913@chronitis.net Approved: robomod@news.nic.it Lines: 61 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Mon, 18 Sep 2017 19:24:22 +0200 X-Original-Message-ID: <735e2fae-8a0b-f82e-73ce-82529d774913@chronitis.net> X-Original-References: <1384861181.23137.1.camel@debiousci.pietrobattiston.it> <3385857.0h487Vp43N@jatayu> <1505711658.1083.20.camel@ghic.org> <167334734.77WkzDjbVa@jatayu> Xref: csiph.com linux.debian.maint.python:9817 On 18/09/17 09:48, Stuart Prescott wrote: > Hi Diane, > > On Sunday, 17 September 2017 22:14:18 AEST Diane Trout wrote: >> I just did it that way because it was the least disruptive change I >> could make that would let me build and test the package. > > Sure, that's entirely sensible. > >> In my experience I'm much more likely to to notice a build time test >> failure than one from the CI system. > > Absolutely agreed. I'm thinking that this is a rather exceptional situation > because of the circular dependency and the fall-out that we regularly see from > that. > >> What do other people think? If there are autopkgtests, should you still >> let dh_auto_test run tests? > > (I know I'm not the 'other people' from whom you solicit replies, I was just > perhaps unclear in what I was musing on before so I want to be more clear now) > > Like you, I would *normally* run all tests in both places: buildd tests catch > severe problems right now; ci.d.n reruns the tests each time new versions of > dependencies are uploaded too and later breakage is caught. > > Perhaps this is not a normal situation, however. Either one of "circular > dependencies" or "packages that often FTBFS on one or more architectures" > would be unusual enough to justify doing something different. All I am > wondering (from my position of ignorance!) if in this case, perhaps the tests > that cause the circular dependency can be disabled or xfailed, with the > remaining tests run as normal. I now prefer to use autopkgtest in place of build-time tests; the former has the advantages: * testing the installed package rather than the source tree, which ensures that the binary package has sufficient dependencies and the correct (or at least sufficient) contents * avoids dependency loops, as noted * avoids the need for workarounds required because of the location of the files being tested at build time (see nbconvert issues with entry_points not being found at build time) * can detect external breakage between uploads via ci.d.n The downsides are that: * boilerplate is required (copying test files out of the source tree to $AUTOPKGTEST_TMP to avoid testing against the source tree, instead of the installed package) * extended build times if using autopkgtest as a post-build hook (installing a chroot multiple times, if using sbuild/similar), and other devs aren't guaranteed to run such tests at build/upload time I wonder if it is possible (or a worthwhile use of time) to try and provide an extended autodep8 python mode which runs the equivalent of dh_auto_test as an autopkgtest, for packages which would opt-in with, eg "Testsuite: autopkgtest-pkg-python-pytest|nose", rather than the basic namespace-can-be-imported test. Gordon