On Fri, Jan 29, 2016 at 11:39 PM, Nathaniel Smith <n...@pobox.com> wrote:
> It occurs to me that the best solution might be to put together a > .travis.yml for the release branches that does: "for pkg in > IMPORTANT_PACKAGES: pip install $pkg; python -c 'import pkg; pkg.test()'" > This might not be viable right now, but will be made more viable if pypi > starts allowing official Linux wheels, which looks likely to happen before > 1.12... (see PEP 513) > > On Jan 29, 2016 9:46 AM, "Andreas Mueller" <t3k...@gmail.com> wrote: > > > > Is this the point when scikit-learn should build against it? > Yes please! > > > Or do we wait for an RC? > This is still all in flux, but I think we might actually want a rule that > says it can't become an RC until after we've tested scikit-learn (and a > list of similarly prominent packages). On the theory that RC means "we > think this is actually good enough to release" :-). OTOH I'm not sure the > alpha/beta/RC distinction is very helpful; maybe they should all just be > betas. > > > Also, we need a scipy build against it. Who does that? > Like Julian says, it shouldn't be necessary. In fact using old builds of > scipy and scikit-learn is even better than rebuilding them, because it > tests numpy's ABI compatibility -- if you find you *have* to rebuild > something then we *definitely* want to know that. > > > Our continuous integration doesn't usually build scipy or numpy, so it > will be a bit tricky to add to our config. > > Would you run our master tests? [did we ever finish this discussion?] > We didn't, and probably should... :-) > > Why would that be necessary if scikit-learn simply tests pre-releases of numpy as you suggested earlier in the thread (with --pre)? There's also https://github.com/MacPython/scipy-stack-osx-testing by the way, which could have scikit-learn and scikit-image added to it. That's two options that are imho both better than adding more workload for the numpy release manager. Also from a principled point of view, packages should test with new versions of their dependencies, not the other way around. Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion