This failure was just a coveralls timeout.

I think we should go ahead and have Cython 0.20.1 across all builds. 0.19.0 (maybe 0.18.0 too) should work, but it's easier to just require the one that works across all Python versions I think. I updated our docs to reflect that you should use 0.20.1 but older version may work. The 0.17.x series definitely won't AFAIK.

This will close #1500. If you didn't know, you can add a 'closes #1500' to the commit message that does so and github will do it automatically and link the issue and the PR.

Oops. I did not know that, but I also didn't pay attention to the two different buttons.

Pretty helpful

https://help.github.com/articles/closing-issues-via-commit-messages

I'm not sure we need to test all of these combinations. I also don't think we should have coveralls run in each instance. I think we should have one test that does our minimum requirements

Python  Numpy    Scipy    Cython  | Patsy  Pandas  Matplotlib
   2.6  1.6.2   0.11.0    0.20.1    0.2.0  0.12.0       1.3.0

Then maybe 2 more with the latest releases from conda packaging

   2.7  Latest Release    0.20.1  | Latest Releases
   3.3
   3.4  Latest Release    0.20.1  |  Latest release

I'm not sure we need 3.3 and 3.4 (or if 3.4 is available on Travis). I think maybe just 3.4, if it's possible. I'd also run coverage only on the 2.7 branch.

For Python versions, I think all of 2.6, 2.7 and 3.3/3.4. I would also suggest that the accompanying packages for 2.6 should be generally older than those for 3.4, since if someone is on 3.4, you can be pretty sure they aren't worried about legacy support. Something like

2.6 with all minimums
2.7 two or three ways

• conservative using similar/same as 2.6
• moderate, say 1.7.x and 0.12.x
• aggressive, using up-to-date packages

3.3/3.4 with most-up-to-date

If the no-2to3 patch gets in, then coverage will be identical except for things in compat.

It is important to test up-to-date since this is what someone who uses a binary installer will tend to get by default, and the only important difference will be whether the user is on 2.7 or 3.3/3.4. It also will show how subtle changes, like optimizer behaviour, affect things.

So...we mostly agree? 2.6 with minimum version requirements, the rest with the most recent releases? I don't see any reason to retest minimum requirements for 2.7. Maybe moderate for 2.7, but I think it's fine to assume that those packages have backwards compatibility and use the latest releases. We just want to make sure our code complies with minimum and isn't broken by changes on travis not that the intermediate versions are bug free I don't think.

I don't know well enough the changes between 3.3 and 3.4 to say whether it's redundant. My view on 3.X is always that if a user is using 3.3 then they'll probably upgrade to 3.4 when available. That said, 3.4 is brand new.

I would guess that most people are on 2.7 now, so it might make sense to test more extensively there: something that would approximate 2.7 with typical platform-installed packages, and 2.7 using a binary installer.

I think once you get to 3.2 that pretty much similar.

Typical platform-installed packages is tough. That's why I'd say use whatever comes with conda or is available on pypi. We ubuntu testing elsewhere from their packaging system.

Let me know when (if) you have a chance to edit this. Need to rebase a few PRs on travis with new Cython. I can merge and then edit if that's preferable from your end.

Happy to edit, but not sure which edits you are referring to? The target packages? Or scaling back the build config?

Coverage remained the same when pulling f755e00 on bashtage:travis-miniconda into 3456ced on statsmodels:master.

Both. We need Cython >= 0.20.1 (might as well) and I think we only need 3-4 build configs. Your changes look good to me unless we want to add a 3.4 build into the mix assuming travis can be set up for it.

@josef-pkt what do you think? Look ok to merge?

Any idea about the build failure on 2.6?

coda didn't work for python 3

overall worth a try to merge this,
the version collection looks good to me, and it looks nice and simple enough

If we get conda specific test problems, we can switch back to something more "official".
(I'm not planning to figure out how conda works anytime soon.)

There are a few issues here:

1.   Segfault on Python 2.6, NumPy 1.6.2.  This will take a little bit more investigation on a local VM to see if I can replicate.  It may require some updates to work correctly
   

2.   General failures on modern SciPy – These are driven by optimization changes which produce incorrect results for 3 tests
   

the python 2.6 log shows that scipy is not properly installed, missing scipy linalg files.
That looks independent of statsmodels.

to 2. gmm.poisson failure are known, I will go back to merging and looking at test failures tomorrow

This I understand the issue – conda is for some reason installing a version that expects MKL even though it shouldn’t be.

general question on the setup:
Is it possible to mix conda and apt-get: use apt-get for the ones that are available on Travis (Ubuntu LTS) and conda for the newer versions?

Unfortunately not – this said, it should be possible to have a Travis script that uses both separately (e.g. one on system python, one on conda).

I didn't pay attention so I tried Pandas < 0.12, which produces test failures:

https://travis-ci.org/bashtage/statsmodels/jobs/21883086

So 0.12 must be a lower bound.

grouputils are still WIP, so it might not be sufficient reason to increase the pandas version requirement. There are currently several failures on Ubuntu and Debian across versions, and I still need to see what's noise and what might be serious.

This PR results in failures, but these are to do with code not invovled in the PR. It is working as expected, save one small issue in conda

conda/conda#629

which requires MKL for Blas. When this bug is patched, it is simple to remove the mkl package from the list.

There still seems to be something wrong with python 3.3
No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.
might indicate an endless loop

depending on the scipy version, endless loops were possible in optimization (I don't think there was one recently.)
depending on the version of Lapack/Blas in numpy, svd can hang on nan or inf (np.linalg.pinv)
or it can be specific to the conda build

I think that is just Travis-induced randomness. Build 207.3 errored in the usual time:

https://travis-ci.org/bashtage/statsmodels

Good, this time results look good,
both 2.6 and 3.3 errors already have separate issues.

Good to merge? Can work on test failures separately afterwards.

It is ready.

@jseabold #1535 is trivial and will produce passes on 2.6.

The other failures are due ot the known issue with newer SciPy.

build results look good, but in the latest coveralls for this PR there are no files.

That is expected - it only affects two non-Python files.

the test suite still runs, and it should show the "all files" > 0

we can try rebase a PR on master and see if it triggers coveralls

I see you are correct - I hadn't been looking at coveralls on this one since I know it wasn't changing Python code.

the include in .travis_coveragerc might be wrong now.
What's the path to the installed package?

also: there are 2 python 2.7 test runs, can we select coverage to run only on one of them?

Eventually – but will need to use a different variable. I wanted to set one to =2 and the other to =2.7, but =2 selects 2.6 for some reason.

This is the issue – The rc has /usr/bin… when it has moved now to reside in anaconda. I am trying a patch that uses /statsmodels/ instead.