Bundle imageutils for photutils 0.1 release - #132

Ideally we would use a submodule, but I don't know if it's possible.

A submodule is possible, so it's more a question of whether people using photutils from git will remember to checkout the submodule.

Yeah, but this it's a "solved problem" both in IPython and ah_bootstrap by having python setup.py build check the submodule situation. We could do that here...

OTOH, it might not be worth it given that it's only a transient situation that imageutils is a submodule. So it might just be better to do it manually (and also manually stick it into the release tarball), and it should be unnecessary for future releases.

I'm 👍 on copying the files into photutils/extern/imageutils, because it's the simpler solution where it's clear that it will just work without having to configure and investigate how a new git submodule interacts with python setup.py.

@cdeil - you mean just for the release, or actually tracking them in git? The latter is mildly problematic because we'll have to do a lot of updates given the rate of change in imageutils...

@cdeil - you mean just for the release, or actually tracking them in git?

Not sure which is better ... I'm fine with any scheme that works.
(I don't think it's too important because this is a temp situation anyways and the problem will be gone in a few months when Astropy 1.0 comes out with astropy.image.)

@cdeil - I thought the idea is that a lot of stuff that's getting added now in imageutils is needed for photutils, right? So the latter is sort of a "testing ground" for the former? Or are you thinking most of what photutils needs is already there by now?

@eteq - Everything photutils needs is already now in imageutils (because everything photutils needs was already available in photutils and we simply moved it to imageutils).
Now while we are re-factoring imageutils we have to adapt photutils ... it's a bit annoying and it would be best to progress quickly on imageutils in the next 10 days before the photutils 0.1 release, but everyone's time is limited.

It turns out that it's easier to include the source files by hand because including it as a submodule means we also have the root of the imageutils directory which we don't want - so unless there are any objections, I will go ahead and merge this (without this, it is not possible to run asv benchmarks since it requires all dependencies to be on pypi, and I think we are not planning on releasing imageutils).

In any case, development on imageutils has slowed down a bit (because what is there is close to converged) so the rapid development is no longer really an issue.

@cdeil or @larrybradley - does this seem ok to you?

Failing because of astropy/imageutils#22

Should be fixed now.

(I there are no objections I will merge this evening since we can always switch to a submodule if we want)

Can astropy/imageutils#17 be merged and included in this PR? I never merged it because I was expecting detailed comments. It may not address the needs of every affiliated package, but it's definitely better (and cleaner API) than what's currently in imageutils master.

@larrybradley - sounds good, I'll go and take a look at that PR

@larrybradley - I've merged astropy/imageutils#17 and have updated this PR.

@astrofrog - ah, good point about the problem of imageutil's root being the wrong thing... So I guess this works, then.