cython building error about halotools HOT 13 CLOSED

Weird. Could you try adding 'cython' to the install_requires field of setup.py?

from halotools.

no dice. same error.

from halotools.

@duncandc - that is strange. Is it possible you've got conflicting python installations? Like it thinks cython isn't installed because it installed it in a place it can't see?

Can you push the commit in question up to some branch somewhere so that I can separately see if I get the same error?

from halotools.

@eteq and @aphearin

see merge latest request.

from halotools.

Awesome. I'll test it asap.

from halotools.

Ok, so I checked out the mock_obs_devel branch that @duncandc has up on his fork. The following works:

python setup.py build
from halotools import mock_observables

However, this seems to be because the init.py files are empty. I tested this with the following changes:

To halotools/mock_observables/init.py, I added:
from .pair_counters import *

And to halotools/mock_observables/pair_counters/init.py, I added:
from .sinha_pairs import *

With only these changes to the code, when I try to import the code I get:
ImportError: No module named sinha_pairs_wrapper

This is a little perplexing, because the code apparently does compile and build. Any ideas @eteq ?

from halotools.

I have noticed this odd import behavior. The following works:

from halotools import mock_observables.pair_counters.sinha_pairs as pairs

Then you can count pairs with
pairs.npairs()

from halotools.

Huh. That's puzzling. Let's see if @eteq has experience with something like this before we merge.

from halotools.

Also, I have not handled multiple simultaneous PRs before. Since @duncandc submitted this PR, I have updated the master branch at least once, I think twice, with significant changes to the documentation. @eteq - is it safe to just use the github tools to merge directly, or should I locally clone from the branch on @duncandc 's fork, merge locally, and submit a new PR? What do y'all do in Astropy?

from halotools.

I can do it on my machine.

from halotools.

I don't mind doing it at all. I just want to know whether it's necessary to go through that rigamarole.

from halotools.

@duncandc - just so we're on the same page, you meant #63, right? (If you just type #63 into a github comment it creates the link automatically so there's no ambiguity). That's what it seems like above, but I wanted to make sure.

To answer @aphearin's question: if github is showing the "merge" button it's nearly always safe to merge (which is indeed the case for #63), because that means there are no files in conflict. If there is a conflict, the merge button is greyed out. In Astropy, the way we nearly always deal with that is that we have the submitter get the latest master and then do "git rebase master". That basically re-writes history so that the new branch seems to be starting from the current master (rather than a past master). The submitter will then have to deal with the conflicts as part of the rebase, but that's usually better because they usually know the code best.

The alternative is to have one of the maintainers manually merge the branch into a local copy of master, make sure it all works right, and then push that up to the github master. Github (usually) recognizes this (at least if you mention the PR by number in the merge commit, and possibly even if you don't...), and automatically records the PR as "merged". I usually only use this approach when there's some minor change that's missing but for whatever reason the original author isn't going to rebase in a timely manner, or if there's something hideously complicated and the original author doesn't know how to do the rebase.

from halotools.

Also, @duncandc and @aphearin - am I understanding right that the Cython building problem has gone away now? If so,you might consider closing this issue and moving the conversation to #63, just to make that clearer. Or if you think this is ready to go of course you can just merge it and close this anyway.

from halotools.