Add gala recipe

[jni]

Hi all! Here's my second recipe. This one has a bunch of Cython to build, so fingers crossed that things go smoothly! Thanks!

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/gala) and found it was in an excellent condition.

[ocefpaf]

@jni b/c gala relies on numpy's ABI you need to specify numpy x.x here and below to bake the numpy build string and ensure the same numpy version used in the build will be installed at run time.

[jni]

Ah right. Can I specify a numpy range, numpy>=1.11? So that it still gets built correctly when 1.12 comes out?

[ocefpaf]

Can I specify a numpy range, numpy>=1.11?

You can specify it twice when there is a numpy version limitation, like it only works > 1.10, for example.

So that it still gets built correctly when 1.12 comes out?

No need in that case b/c the numpy matrix is defined automatically by conda-forge. Right now our lower limit is numpy 1.10.

[jni]

Sorry can you clarify what you meant with "specify it twice"? What's the spec?

[jakirkham]

Example below in the diff. Hope that clarifies it.

[patricksnape]

Cython.Compiler.Errors.InternalError: Internal compiler error: 'dtypes_cy.pxi' not found

[patricksnape]

This is likely a mistake in your setup.py - I think your MANIFEST.IN wants to add

recursive-include gala *.pyi

[jakirkham]

So if there are some errors that are going to require some iteration on the repo, would suggestion switching to cloning it from the git repo. We will have to switch it back later, but this allows us to keep progressing and then you can make a patch release once we have everything working.

[jakirkham]

Should also be numpy x.x

[jakirkham]

To further restrict numpy one can tweak this as follows.

    - numpy x.x
    - numpy >=1.7

This would then be repeated in run too.

[jni]

Woot! Now that I've got my first successful build with Cython deps, I have some questions:

• how does one incorporate continuous builds on the master branch? I think I remember @jjhelmus mentioning a specific channel for dev/pre-release builds?
• with using git as a source, as mentioned above by @jakirkham, does the git_rev have to be a tag or can it be a branch?
• what tools are people using to automate releases? A particular pain point for me is not having a single point of control for the version number or for the dependencies (which will now exist in requirements.txt, envirnoment.yml, and the conda-forge feedstock, and is error-prone as shown by my zmq commit).

[patricksnape]

1. Although some talk has been had around dev/pre-release branches, I don't think that conda-forge is the appropriate place to be kicking off your continuous integration. I think you should be doing that over on the gala github repo. Setting that up is pretty easy actually, you just need to copy the .travis.yml, circle.yml and appveyor.yml files and sign up on those services to start builds going. You may want to pare down the complications of conda-forge since you don't require building multiple recipes etc. For a very rough example of this, you can look at condaci which I use for one of my projects (an example usage on Travis is here).
2. I believe because of the fact that git makes no distinction between tags and branches it can be either.
3. In terms of dependency version numbers, I am not sure. I would be interested to hear about something to handle that as well. In terms of project version number, I recommend versioneer which totally automates the process of versioning for projects that use git and tagging for releases.

[jjhelmus]

how does one incorporate continuous builds on the master branch? I think I remember @jjhelmus mentioning a specific channel for dev/pre-release builds?

As @patricksnape mentioned conda-forge is not intended for continuous builds, rather for releases (or "near" releases). We are limited on our CI resources and continuous builds on a handful of highly active projects could use all of these up.

There is a conda-forge enhancement proposal which lays out a plan for making and labeling pre-releases/rc/beta/alpha/etc conda packages which may be of interest.

[jakirkham]

with using git as a source, as mentioned above by @jakirkham, does the git_rev have to be a tag or can it be a branch?

Sure that can be done.

To respond to others more generally, the point of my asking @jni to try this is so that we can fix some packaging issues that are unique to PyPI/conda-forge. The best place to fix them is here.

Now I'm not suggesting that we package some untagged release. On the contrary, I'm suggesting we try iron out these package issues first before we get hung up on the details of how to get this released. Once they are resolved it would be good if @jni is able to either make a new patch release with these fixes or include patches for the near term to work around these issues as has been done before.

This hardly something unique to this case and we have occasionally let people do this of their own accord before.

[jni]

Hi everyone!

Thanks for the responses. My own below:

1. Ah ok, I misunderstood. I'll look at the conda-CI resources @patricksnape mentioned. Now that I have some recipes set up, it should be easier for me to get this going on my own channel.
2. Thanks, makes sense. But @jakirkham now that the package is working at 0.4.1, can we leave the git source experiment for another package? =) The process of removing/fixing the modules that fail testing is going to be long and tedious and won't happen for some time. It would be very useful in the meantime for my package to be on conda-forge.
3. Will look at versioneer, thanks @patricksnape, but it wouldn't update the meta.yaml, would it???

[jakirkham]

Sure, the suggestion was given only in response to hearing there were compilation issues. As it builds fine now, it seems hardly necessary. Hope that makes sense.

[jakirkham]

Thanks @jni.

[jakirkham]

Probably worth noting that gala is on conda-forge in this feedstock. 😉

cc @stephenplaza @DocSavage

[jakirkham]

Also forgot to cc @stuarteberg . Sorry about that.