Re: Python 3 Statsmodels & Pandas
Hi,
On Mon, Sep 18, 2017 at 05:48:48PM +1000, Stuart Prescott wrote:
> 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.
If my poor opinion counts: For the moment we should run those tests in
the build process than can be easily be run. Everything else should
probably be sorted out later (in autopkgtest or another later upload if
somebody has a clue how we can solve the circular depenendecies).
We somehow need to get some working spatstats to continue with other
packages.
Thanks to all who contributed
Andreas.
--
http://fam-tille.de
Reply to: