Perhaps a pip + virtualenv build as well since that's one way that is mentioned in the online docs for installing source code.  I can't think of anything else beyond that and what you suggested for the time being.

Greg

On Tue, Jan 26, 2016 at 6:59 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:


On Tue, Jan 26, 2016 at 2:13 AM, G Young <gfyoung17@gmail.com> wrote:
Ah, yes, that is true.  That point had completely escaped my mind.  In light of this, it seems that it's not worth the while then to completely switch over to pip + virtualenv.  It's might be better actually to rewrite the current Appveyor tests to use environments so that the test suite can be expanded, though I'm not sure how prudent that is given how slow Appveyor tests run.

At the moment Appveyor is already a bit of a bottleneck - it regularly hasn't started yet when TravisCI is already done. This can be solved via a paid account, we should seriously consider that when we have a bit more experience with it (Appveyor tests have been running for less than a month I think). But it does mean we should go for a sparse test matrix, and use a more complete one (all Python versions for example) on TravisCI. In the near future we'll have to add MingwPy test runs to Appveyor. Beyond that I'm not sure what needs to be added?

Ralf

 

Greg

On Tue, Jan 26, 2016 at 12:13 AM, Bryan Van de Ven <bryanv@continuum.io> wrote:

> On Jan 25, 2016, at 5:21 PM, G Young <gfyoung17@gmail.com> wrote:
>
> With regards to testing numpy, both Conda and Pip + Virtualenv work quite well.  I have used both to install master and run unit tests, and both pass with flying colors.  This chart here illustrates my point nicely as well.
>
> However, I can't seem to find / access Conda installations for slightly older versions of Python (e.g. Python 3.4).  Perhaps this is not much of an issue now with the next release (1.12) being written only for Python 2.7 and Python 3.4 - 5.  However, if we were to wind the clock slightly back to when we were testing 2.6 - 7, 3.2 - 5, I feel Conda falls short in being able to test on a variety of Python distributions given the nature of Conda releases.  Maybe that situation is no longer the case now, but in the long term, it could easily happen again.

Why do you need the installers? The whole point of conda is to be able to create environments with whatever configuration you need. Just pick the newest installer and use "conda create" from there:

bryan@0199-bryanv (git:streaming) ~/work/bokeh/bokeh $ conda create -n py26 python=2.6
Fetching package metadata: ..............
Solving package specifications: ..........
Package plan for installation in environment /Users/bryan/anaconda/envs/py26:

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    setuptools-18.0.1          |           py26_0         343 KB
    pip-7.1.0                  |           py26_0         1.4 MB
    ------------------------------------------------------------
                                           Total:         1.7 MB

The following NEW packages will be INSTALLED:

    openssl:    1.0.1k-1
    pip:        7.1.0-py26_0
    python:     2.6.9-1
    readline:   6.2-2
    setuptools: 18.0.1-py26_0
    sqlite:     3.9.2-0
    tk:         8.5.18-0
    zlib:       1.2.8-0

Proceed ([y]/n)?

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion



_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion