Use travis and appveyor to build conda packages

[astrofrog]

I already have a repository set up to do this for other projects so I will create another repository in the astropy organization and copy over some of the recipes from here.

cc @mwcraig

[mwcraig]

I've had this on the back burner for several months now...more specifically, it would be almost trivial to build affiliated packages on travis/appveyor and then upload to an astropy conda channel, because python setup.py bdist_conda builds without needing a recipe.

One other use of these builds would be to build a package for astropy on every commit to master that affiliated packages could use for testing without needing to build astropy from source.

Won't likely have time to do any of this until mid-March, though...

[astrofrog]

I already had a repository ready for something like this because I had to do it for the RC. I've just updated it and put it in the astropy organization:

https://github.com/astropy/conda-builder

It's trivial to add new recipes as needed.

[mwcraig]

I see, so as recipes are added to https://github.com/astropy/conda-builder they are automatically built and uploaded.

Would it make sense to have a separate binstar account for affiliates, e.g. astropy-affiliated, or transition to a structure like this:

astropy - main astropy binstar channel astropy/ci-extras -- replaces current ci channel astropy/affiliated -- affiliated packages astropy/rc -- release candidates astropy/latest -- build from most recent master (would maybe need to be done from the main astropy repo?)

Playing around right now with channels on binstar to see how they work...

[astrofrog]

@mwcraig - that might be a good idea. What we need to think about is how to avoid re-building every single package every time - we could have a file in which we list which packages should be built in the next CI run.

Anyway, no rush for now, but just wanted to make sure for now that we upload the latest packages to astropy-ci-extras since some affiliated packages need that. It would be nice to have a more generalized system in future.

[mwcraig]

Turns out the naming isn't as elegant as it could be; the channels need to have channel in the name, e.g. astropy/channel/ci-extras.

Will think about limiting the builds -- it can be done without needing to make an explicit list, I think, by trying to install each package before building with --dry-run and only building if that fails.

[astrofrog]

@mwcraig - that's a good idea, I was wondering how we could make it so that it only builds things not already on binstar (and we can delete from binstar to force new build).

[mwcraig]

@astrofrog -- I have a package with a much smaller build matrix I can try this out on.

The gist is that this command returns exit status 1 if the package is not on binstar, zero if it is on binstar already (assuming the astropy-ci-extras channel is already add via conda config):

conda create --dry-run -n dummy astropy=1.0 numpy=1.6 python=3.2

[mwcraig]

@astrofrog -- FYI, conda now understands numpy and python versions with dots, so you can do CONDA_NP=1.7 and CONDA_PY=3.3, i.e. the build matrix doesn't need CONDA_PY at all, just add --python $PYTHON to the conda build statements (don't remember if travis actually calls the python version $PYTHON or something else, but you get the idea).

[astrofrog]

@mwcraig - regarding your last comment, we now set language: c so that it also works for MacOS X, so we need to still specify CONDA_PY manually (see the conda-builder repo)

[mwcraig]

@astrofrog -- true that $PYTHON is no longer set, but both $python and $CONDA_PY are set in your matrix, and could have the same value. Looks like you could actually drop the python=X.Y altogether even. Not that this is really important.

[astrofrog]

@mwcraig - ah yes indeed! Have dropped the python=X.Y to see if it still works.

[astrofrog]

It does indeed still work :)