Closed cdeil closed 10 years ago
What about including imageutils
as a subrepository for now? Otherwise, I'm fine with a very early 0.1 release.
On the pypi issue: astroimageutils
?
or astropy-imageutils
:+1: to astropy-imageutils
if we go with 2.
I'm about 50/50 on 1 vs 2. I agree having a release might be nice for feedback and such. But someone has to deal with being the release manager. It's not a huge amount of work, but it is some. So I think we need to first have a definite committment from someone to do that (and bugfixes). Fortunately, it's not really "long-term", because the plan is to merge into the astropy core. But it could be ~a year and multiple releases, depending on when that merging happens and how much we want in it.
So if no one is going to volunteer to be the maintainer/manager for imageutils
with the above expectations, then we should go with 1.
@eteq I'd be happy to do the 0.1 release, unless @keflavich or @larrybradley want to do it ... even better.
About your comments concerning long-term maintenance of imageutils
and multiple releases: this is not what we want! As stated on the front page of the imageutils docs, we only plan to accrete and polish image utils here for a month or two and then make a pull request which add this to the astropy core, well before the 1.0 release.
Actually, while we're at it, we could set the date when we plan to make this pull request and stop working on the imageutils
repo here as well. ... how about September 25th?
Again, I'd be happy to do it, but if @keflavich or @larrybradley have time to do it ... even better.
The advantage of setting dates now is that everyone can plan their work for the coming weeks and has time to add / improve the things they want easily (i.e. with a much quicker review / merge response time than is the case for Astropy core).
@keflavich, @larrybradley Would you prefer more time to work in the imageutils
repo, i.e. make the pull request against Astropy core in October? (I don't think we should wait until November, because then it's too close before the Astropy 1.0 release ... there might be long API discussions.)
Ah, alright. In that case, I'm less sure what the point of putting it on PyPI is: it will then just be left as an artifact with a single release, right? I guess that tilts me slightly in favor of 1 over 2, now because it seems like less trouble for everyone... After all, if we encourage people to try it out, we'll probably still have to support it for a little while even after it gets merged into astropy
.
But if you'd rather just put the one release on PyPI, I'm ok with that too.
Thinking about it some more, I agree with @eteq that option (2), doing a release on PyPI for a package that we don't plan to support in a few months is maybe not very nice, plus there's the hairy package name conflict.
I don't have a preference for (1) or (2) or (3) any more ... let's see what the others prefer.
I think this discussion is still useful, so that we are all on the same page with the schedule and can create two milestones on Github:
astropy-dev
and ask for feedback / contributions Aug 25 (irrespective if we do an 0.1 release or not)?That sounds good to me, although of course with the usual caveats of "Soft deadlines, depending on whether anything critical is pending" and such.
(And if it wasn't clear from above, I strongly prefer (1) over (3), and slightly favor (1) over (2) )
I'm slightly in favor of (1) now. Is it possible to have imageutils
as a subrepository in phoutils/extern
(i.e. will it get packaged OK in the photutils
release)? I haven't used extern
yet.
If we go with (2), I can do the release (and I like astropy-imageutils
). That's unfortunate about the PyPI name.
@cdeil Those dates sound fine with me.
Is there a freeze date for photutils 0.1
?
@larrybradley @cdeil - Actually, this makes me favor (1b), which is to include imageutils
in extern in the release, but in the repository, have it be a git submodule
. Basically, exactly what we do with astropy_helpers right now.
What I don't know is how complicated that will be to get working. It may be we can re-purpose the stuff in ah_boostrap
to do this fairly trivially, but I haven't looked into it too closely. (maybe @embray can tell us?)
Thanks everyone for the feedback!
In the end all of the options discussed have pros / cons and would work, but I think everyone's OK with the plan to bundle imageutils
in photutils
as a submodule or by copying the files ... we can discuss this here: https://github.com/astropy/photutils/issues/132
So the plan is that we won't make a PyPI release of imageutils
at all ... OK if I close this issue now?
I've made two milestones for imageutils
as discussed above ... please try to make issues / pull requests at least a few days before so that we have time to sort them out:
https://github.com/astropy/imageutils/milestones
Sounds good to me.
photutils
now depends onimageutils
, and I wanted to ask you how we should handle that for the upcomingphotutils 0.1
release (on August 28).I think the options are:
imageutils
inphotutils/extern
as a temp solution (easiest for users)imageutils 0.1
release on PyPI (pretty easy for users becausepip install photutils
will automatically installimageutils
)imageutils
from githubI think trying to get
imageutils
merged into Astropy core before is unrealistic, plus having one release ofimageutils
with an announcement onastropy-dev
could be nice to get some users and feedback. So my preference would be option (2) ... I could make theimageutils 0.1
release (or help if someone else wants to do it) on August 25th.We could use this issue to discuss any questions about this release, e.g. the Python package name
ImageUtils
is taken on PyPI, so we'd have to pick a different PyPI name.But first, @keflavich, @larrybradley, @astrofrog, @eteq, which option would you prefer? (feel free to propose a different one if it's missing in the list above)