Release first stable version of astropy-helpers

[astrofrog]

@embray @eteq - I think we should do this soon, possibly even today or tomorrow. I've milestoned all issues I think we might want to deal with for this as 0.1, though we may decide on a different version number for the first release. What do you think?

[eteq]

@astrofrog - I agree except I'd add one more thing: a final decision on how to keep track of issues on astropy-helpers vs. astropy repo. If we're doing a true release, we need to describe very obviously how to report issues.

Also, we should merge APE4 if we're actually going ahead with this, but that doesn't necessarily have to be synced with the helpers release, I suppose?

[astrofrog]

Well, I'm in favor of allowing issues to be reported here, and also having an astropy-helpers in the astropy core package. Then advanced devs can report the issues here (and turn them into PRs) while we can simply tag issues in the core package if users report them there. But maybe @embray can comment on this - I seem to remember him saying something similar on another issue.

[astrofrog]

@embray @eteq - seems there haven't been any further astropy-helpers issues, shall we merge #51 and finalize the release?

[eteq]

@astrofrog - I just talked to @cdeil about some documentation clarifications he thinks should be in there (about e.g. how to do tasks related to submitting PRs or issues for astropy_helpers).

I'm pretty sure he didn't think those are crucial for the release, but @cdeil, can you clarify, just to be sure?

[eteq]

(if it wasn't obvious, though, other than that I think it's good to go!)

[astrofrog]

Note that the README says "More details will be added to this README before astropy-helpers v0.4 final is released. In the meantime, see the setup.py and setup.cfg files in the Affiliated package template for examples of its usage." so that will at least need to be re-worded before the release.

[astrofrog]

@embray - once #55 is merged in, do you want to go ahead and do the final release and submit a PR to the core package to update the submodule version?

[astrofrog]

@embray @eteq - looks like we are good to go for a release!

[embray]

I'm just waiting now on https://travis-ci.org/astropy/astropy-helpers/builds/30002815 It should pass though.

[embray]

Okay, it's go time!

[astrofrog]

:+1:

[embray]

Done! See:

https://pypi.python.org/pypi/astropy-helpers/0.4 https://github.com/astropy/astropy-helpers/tree/v0.4

[astrofrog]

Thanks for doing this! :fireworks:

[embray]

[cdeil]

I see LATEST: 0.4rc3 when pip asks PyPI, but pip install actually gets 0.4:

$ pip search astropy-helpers
astropy-helpers           - Utilities for building and installing Astropy, Astropy affiliated packages, and their respective documentation.
  INSTALLED: 0.4
  LATEST:    0.4rc3

Is this normal?

[eteq]

@cdeil - I see the same thing, but I believe this is nominally a bug in pip... the pip search command seems to not be aware of which packages are hidden or not, even though that's clearly relevant for what pypi returns (and what pip actually installs).

[astrofrog]

@eteq @cdeil @embray - we could remove the RCs from pypi to avoid confusion?

[embray]

I'd rather they stay. I didn't even know pip search existed but I think a bug should be reported there (if there isn't already one). In general users won't be directly installing astropy-helpers anyways.

[astrofrog]

I have pip 1.5.6 and I get:

$ pip-2.7 search astropy-helpers
astropy-helpers           - Utilities for building and installing Astropy, Astropy affiliated packages, and
                            their respective documentation.

(no version info)

[embray]

@astrofrog I only see the INSTALLED/LATEST listing if astropy-helpers is actually installed first (which seems silly).

[astrofrog]

@embray - you're right, I see that too.

[eteq]

@astrofrog @embray - now that I think about it, this isn't a big deal if nothing else because typically users won't be installing it anyway, right? (it should come in the using package's source distribution)

[astrofrog]

Right, it would only be a problem if pip was still fetching the RC as the latest version, which it's not. Now it does mean it will show the same for astropy when it is released though.

[embray]

So again, re Astropy itself, "Upstream-fix-required" :)

[cdeil]

(I've deleted my last comment because I now think it's really an issue in pip.)

I've reported the issue to pip here: https://github.com/pypa/pip/issues/1929

[embray]

Yes. If you ever want an example of "bikeshedding" to point to I can link you to about two dozen threads in which the allowed version schemes for Python packages were decided on :)

[embray]

Although tongue-in-cheek aside I think it was a really interesting and useful discussion, and the end result I think gives just the right amount of flexibility.

[embray]

@cdeil Thanks for making the report. Looking at the code now it's using legacy version comparison in that code that's not fully compatible with PEP 440, etc. and doesn't sort these versions properly.