Some non-functioning-APIs fixed #2019

krngrvr09 · 2014-01-29T13:22:24Z

26 out of the 36 non-functioning APIs in 'whatsnew' folder are fixed. #1221

mdboom · 2014-01-29T13:25:30Z

docs/whatsnew/0.1.rst

@@ -12,7 +12,7 @@ package with a unified installer, including:

 * asciitable as :mod:`astropy.io.ascii`
 * PyFITS as :mod:`astropy.io.fits`
- * votable as :mod:`astropy.io.vo`
+ * votable as :mod:`astropy.io.votable`


This is more of a question for the wider audience: I wonder if we should retroactively update these... It certainly was correct at the time. In this specific case, it probably doesn't matter, but for someone considering updating from 0.1 to 0.2, when 0.3 is already released, this kind of thing could add confusion.

And to clarify -- I wouldn't be opposed to this changing to:

``astropy.io.vo``

i.e., a non-link, in order to make nitpicky mode happy.

EDIT: Replaced "would" with "wouldn't" above

I also agree that we shouldn't change the name of the module in the 0.1.rst file - it should reflect what the code was at the time.

@mdboom - what do you suggest we should use instead of double backticks for cases like this? Should we just leave the single backticks and live with the warnings?

To some extent, this applies to any other renaming - why not use the double backticks to refer to old names that no longer resolve?

Oops: I mistyped above. I meant "wouldn't be opposed" rather than "would be opposed." Sorry about that ;)

So I agree that double backticks are probably the best solution here -- it will resolve the warning without renaming it for the reader.

Ok, sounds good :)

@krngrvr09 - could you change this example to:

``astropy.io.vo``

rather than rename it?

mdboom · 2014-01-29T13:28:11Z

Aside from my question (which is really just a policy question about changelogs), this looks good. Thanks for doing this kind of work: it really enhances the overall polish.

astrofrog · 2014-01-29T14:23:42Z

docs/whatsnew/0.3.rst

@@ -240,7 +242,7 @@ return Numpy arrays.

 As shown above, all the coordinate classes have now been renamed to drop the
 ``Coordinates`` suffix (e.g. ``ICRS`` instead of ``ICRSCoordinates``). In
-addition, `HorizontalCoordinates` has now been renamed to `AltAz`.
+addition, ``HorizontalCoordinates`` has now been renamed to `astropy.coordinates.builtin_systems.AltAz`.


I think there should be a ~ in the link for AltAz, i.e. ~astropy.coordinates....

It doesn't seem to make a difference. The absence of '~~', seemed unusual to me too, but since it was not showing a warning, I let it go. What does the '~~' signify?

Without the ~, you should see 'astropy.coordinates.builtin_systems.AltAz' and with it, you should see 'AltAz' - i.e. when you add it, you say that you only want to see the last part of the path.

Oh, alright. Since I was checking only the warning, I didn't realize that. Thank you.

astrofrog · 2014-02-01T08:00:02Z

@krngrvr09 - I just saw you added some commits - in general once you've resolved issues we raised, add a comment otherwise GitHub doesn't tell us there have been updates to the pull request.

astrofrog · 2014-02-01T08:01:40Z

@krngrvr09 - this looks good now - shall I merge it, or do you want to add more fixes first?

embray · 2014-02-03T17:05:53Z

docs/whatsnew/0.1.rst

@@ -12,7 +12,7 @@ package with a unified installer, including:

 * asciitable as :mod:`astropy.io.ascii`
 * PyFITS as :mod:`astropy.io.fits`
- * votable as :mod:`astropy.io.vo`
+ * votable as :mod:``astropy.io.vo``


This should drop the :mod: directive too. It should just read

* votable as ``astropy.io.vo``

Just so I know, what does the :mod: do?

Also, build_sphinx is showing, astropy.io.fits as broken. Any idea why?

embray · 2014-02-03T17:07:53Z

I just added a couple more suggestions, but other than that this is good.

krngrvr09 · 2014-02-05T09:36:31Z

@astrofrog Almost everything is fixed.
astropy.cosmology.core.Cosmology, is broken, should I add single ticks?

astrofrog · 2014-02-05T10:10:56Z

@krngrvr09 - yes, could you add single ticks? The link will still be broken (I will raise this issue separately) but single ticks is the right thing in this case.

krngrvr09 · 2014-02-06T18:37:19Z

Broken links of the whatsnew folder are fixed. Currently working on 'wcs'.

astrofrog · 2014-02-06T19:34:29Z

@krngrvr09 - will you push that here too, or would you prefer to open a new pull request?

krngrvr09 · 2014-02-07T04:53:03Z

I think I'll push them here. After fixing 3-4 modules, you can merge them.

krngrvr09 · 2014-02-09T19:47:59Z

@astrofrog 'vo' and 'wcs' modules are fixed now.
Few questions:

'astropy.io.fits' and 'astropy.io.votable.validator.result.Result' are broken. They shouldn't be. Why is there not a link for them in the docs?
I have adjusted the formatting of a docstring. I believe, I shouldn't have pushed that in this PR. But apparently, 'git commit .' pushes the commits that were not even staged. (Lesson learnt).
Is it good, if you merge after I fix, 'utils', 'units', and 'time'?

astrofrog · 2014-02-09T21:10:04Z

@krngrvr09 ignore the fact that 'astropy.io.fits' and 'astropy.io.votable.validator.result.Result' don't work for now. For the latter, I think @embray can fix that, and for the latter we either need to document the Result class, or @mdboom or @pllim will need to remove the references to the classes. The links themselves are correct and don't need fixing.

For the accidental change to wcs.py, just unindent the code again (it should be as it was originally) and commit a fix.

Once you've fixed the ones you mention, we can merge - thanks!

pllim · 2014-02-10T15:07:23Z

I thought we already discussed astropy.io.votable.validator.result.Result in the past. We decided: It is used by astropy.vo.validator but users do not need to know more than that, so it's okay to just leave it mentioned by undocumented. Has that changed?

mdboom · 2014-02-10T16:46:14Z

@pllim: You're exactly right. I think we just need to not refer to it from vo/validator.rst... Maybe there's a way to reword that paragraph?

pllim · 2014-02-10T16:47:50Z

Will using double quote thingy suffice? Like

``astropy.io.votable.validator.result.Result``

mdboom · 2014-02-10T16:56:26Z

@pllim: That's probably fine, but it seems a little rude to refer to an undocumented class like that. (Like a dictionary that for a definition says "see X" but then doesn't define X). But I'm actually not sure what you mean by "original attribute names" -- do you mean the dictionary keys? Maybe we should just list what they are?

pllim · 2014-02-11T15:09:11Z

@krngrvr09 and @astrofrog , astropy.vo doc was fixed in #2071 . FYI.

mdboom · 2014-02-12T16:56:21Z

docs/wcs/relax.rst

@@ -20,8 +20,8 @@ out only standard keywords), in accordance with `Postel's prescription
 Header-reading relaxation constants
 -----------------------------------

-`~astropy.wcs.WCS`, `~astropy.wcs.Wcsprm` and
-`~astropy.wcs.find_all_wcs` have a *relax* argument, which may be
+`~astropy.wcs.wcs.WCS`, `~astropy.wcs.Wcsprm` and


This is a tricky one. The actual place where we want users to import astropy.wcs.wcs.WCS from is astropy.wcs.WCS, but the documentation generates it for its "real" location. I know that there's some work going on to fix this problem in #1826 and elsewhere...

@eteq: Since you're much more involved with all this than I am, can you comment? Would it make sense for @krngrvr09 to hold off on this for now until #1826 is resolved. I'm just worried if we make this change now, we'll just have to change it back to what we really want it to be later...

Hmm, good point @mdboom. But there are a lot of places where we've been doing this already, so we'll have to go correct it all en masse in the future.

I guess if you think this will be merged soon, I'd say go ahead and accept this, as it might still take more time for #1826 to get working (lots of Sphinx black magic going on there...). We'll probably want to try to find an automated way to take care of it anyway after #1826...

Sounds good to me, if #1826 is still a ways off...

mdboom · 2014-02-12T16:58:19Z

I just looked over the wcs part of this. For the most part, it totally makes sense. I'm not sure how best to handle the APIs that currently say what we want them to, but currently break because Sphinx wants to document the classes in their source location rather than their API location. Hopefully that's resolvable, but I think @eteq and @kbarbary will have more insight into that than I...

krngrvr09 · 2014-02-19T05:44:17Z

@astrofrog Done. Unsure about a few things.

[units.equivalencies.rst]Couldn't find the forward and backward function. As far as I have researched, they were originally a part of pyparsing. But now we are no longer using pyparsing(right?). So, should I leave it as it is, put double ticks, or will it be eventually removed from the docs. (Correct me, if I'm wrong about anything,)
[units.equivalencies.rst] find_equivalent_units method is in the class EquivalentUnitsList. In the docs it astropy.units.core.Unit.find_equivalent_units. Is this an error?
Couldn't find a link to astropy.utils.compat.

@mdboom I have not changed anything in wcs/relax.rst. Let me know if something is required.

P.S - 300 broken links fixed!

astrofrog · 2014-02-19T07:59:52Z

@krngrvr09 - in the following sentence:

`from_unit` and `to_unit` are the equivalent units.  `forward` and
`backward` are functions that convert values between those units.

all the ones in single ticks should be in double ticks. These are just made up variable names for what an equivalency should consist of.

For the find_equivalent_units, the current link is correct:

In [3]: Unit('m').find_equivalent_units()
Out[3]: 
  Primary name | Unit definition | Aliases     
[
  AU           | 1.49598e+11 m   | au           ,
  Angstrom     | 1e-10 m         | AA, angstrom ,
  cm           | 0.01 m          | centimeter   ,
  lyr          | 9.46073e+15 m   | lightyear    ,
  m            | irreducible     | meter        ,
  micron       | 1e-06 m         |              ,
  pc           | 3.08568e+16 m   | parsec       ,
  solRad       | 6.95508e+08 m   | R_sun, Rsun  ,
]

the issue is that indeed it does not appear in the docs:

http://docs.astropy.org/en/stable/api/astropy.units.core.Unit.html#astropy.units.core.Unit

maybe @mdboom or @eteq can look into why?

astrofrog · 2014-02-19T08:00:26Z

See the note at the top of http://docs.astropy.org/en/stable/utils/index.html for astropy.utils.compat. I think you should use double backticks.

krngrvr09 · 2014-02-19T08:56:16Z

Oh yes. I had read that note. Somehow forgot. My bad!

krngrvr09 · 2014-02-27T12:55:58Z

@astrofrog Is there anything else, I have to do?

mdboom · 2014-02-27T16:18:28Z

docs/units/equivalencies.rst

@@ -253,9 +253,9 @@ of ``c`` is used instead of the constant.
 Displaying available equivalencies
 ----------------------------------

-The :meth:`~astropy.units.core.Unit.find_equivalent_units` method also
+The :meth:`~astropy.units.core.UnitBase.find_equivalent_units` method also


Just to confirm: this looks like the correct change to me.

astrofrog · 2014-02-27T17:59:55Z

@krngrvr09 - we should rebase this (without squashing) to get rid of the merge commits here. I can send instructions on doing that later this evening.

astrofrog · 2014-02-27T18:10:46Z

@krngrvr09 - I made a backup of your branch in case anything goes wrong. Just do:

git fetch upstream
git rebase -i upstream/master

Don't edit the commits, just save and continue and it will start the rebase. I think you will get a conflict, so try and resolve it and then proceed. I have a backup of the branch so as a last option I can merge it manually - but it'd be good to learn to rebase.

There are some instructions here:

http://docs.astropy.org/en/stable/development/workflow/development_workflow.html#rebase-on-trunk

If you have any questions, feel free to ask here or see if anyone is on IRC.

For future, if you want to update the commits in your branch, don't merge master into the branch - instead, rebase of the upstream master to always include your commits at the top.

…lder

…to 'Astropy'

krngrvr09 · 2014-02-27T18:36:39Z

Successfully rebased. On git diff master, I see all my commits. Should I push or force push?

astrofrog · 2014-02-27T20:37:43Z

@krngrvr09 - you'll need to force push for the changes to appear here.

krngrvr09 · 2014-02-27T20:43:13Z

@astrofrog Done.

astrofrog · 2014-02-27T20:58:34Z

@krngrvr09 - great job with the rebasing :) This looks good now, let's just wait on Travis.

krngrvr09 · 2014-02-27T20:59:38Z

All thanks to you. :)

On Fri, Feb 28, 2014 at 2:28 AM, Thomas Robitaille <notifications@github.com

wrote:

@krngrvr09 https://github.com/krngrvr09 - great job with the rebasing
:) This looks good now, let's just wait on Travis.

Reply to this email directly or view it on GitHubhttps://github.com//pull/2019#issuecomment-36290577
.

astrofrog · 2014-02-27T21:01:54Z

@krngrvr09 - I just realized that two or three of the API links may have to be changed back now that #1826 has been merged. Now that you have rebased you should have these changes so if you run the build_sphinx again, would you mind double check if any of the fixes included here have re-appeared as warnings?

krngrvr09 · 2014-02-27T21:20:52Z

I'll do that right away.

On Fri, Feb 28, 2014 at 2:31 AM, Thomas Robitaille <notifications@github.com

wrote:

@krngrvr09 https://github.com/krngrvr09 - I just realized that two or
three of the API links may have to be changed back now that #1826 https://github.com/astropy/astropy/pull/1826has been merged. Now that you have rebased you should have these changes so
if you run the build_sphinx again, would you mind double check if any of
the fixes included here have re-appeared as warnings?

Reply to this email directly or view it on GitHubhttps://github.com//pull/2019#issuecomment-36290952
.

krngrvr09 · 2014-02-28T16:21:40Z

@astrofrog Broken links have gone up to 2600.

Some non-functioning-APIs fixed

astrofrog · 2014-03-01T10:16:56Z

@krngrvr09 - thanks for the contribution!

mdboom reviewed Jan 29, 2014
View reviewed changes

astrofrog reviewed Jan 29, 2014
View reviewed changes

embray reviewed Feb 3, 2014
View reviewed changes

astrofrog mentioned this pull request Feb 5, 2014

Cosmology class missing from API docs #2045

Closed

pllim mentioned this pull request Feb 10, 2014

Removed undocumented Result class from VO documentation. #2071

Merged

mdboom reviewed Feb 12, 2014
View reviewed changes

mdboom reviewed Feb 27, 2014
View reviewed changes

Karan added 10 commits February 27, 2014 23:48

Fixed 26 out of the 36 (non-functioning-api)warnings in 'whatsnew' fo…

fb94378

…lder

Fixed broken API links

cb32e2e

Fixed remaining issues

4d18c85

Made more improvements. Almost ready for merge.

9b71559

Fixed broken links in 'vo' and 'wcs' modules.

7065cc0

Fixes the warnings during test runs.

5c42957

Fixed broken links in time, and few in units module

34b9202

Fixed 3 broken links.

d17f3f0

Fixed a link in equivalencies.rst

b1ab4b8

added double tiks around "2010-01-01 00:00:00" and changed 'astropy' …

458ce17

…to 'Astropy'

astrofrog added the ready-for-final-review label Feb 27, 2014

astrofrog added this to the v0.4.0 milestone Feb 27, 2014

Fixed a few broken links after the rebase

3801eae

astrofrog added a commit that referenced this pull request Mar 1, 2014

Merge pull request #2019 from krngrvr09/broken_api

d34d53f

Some non-functioning-APIs fixed

astrofrog merged commit d34d53f into astropy:master Mar 1, 2014

krngrvr09 deleted the broken_api branch March 1, 2014 15:15

embray removed the Ready-for-final-review label Jan 13, 2015

Some non-functioning-APIs fixed #2019

Some non-functioning-APIs fixed #2019

Conversation

krngrvr09 commented Jan 29, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdboom commented Jan 29, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astrofrog commented Feb 1, 2014

astrofrog commented Feb 1, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

embray commented Feb 3, 2014

krngrvr09 commented Feb 5, 2014

astrofrog commented Feb 5, 2014

krngrvr09 commented Feb 6, 2014

astrofrog commented Feb 6, 2014

krngrvr09 commented Feb 7, 2014

krngrvr09 commented Feb 9, 2014

astrofrog commented Feb 9, 2014

pllim commented Feb 10, 2014

mdboom commented Feb 10, 2014

pllim commented Feb 10, 2014

mdboom commented Feb 10, 2014

pllim commented Feb 11, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdboom commented Feb 12, 2014

krngrvr09 commented Feb 19, 2014

astrofrog commented Feb 19, 2014

astrofrog commented Feb 19, 2014

krngrvr09 commented Feb 19, 2014

krngrvr09 commented Feb 27, 2014

Choose a reason for hiding this comment

astrofrog commented Feb 27, 2014

astrofrog commented Feb 27, 2014

krngrvr09 commented Feb 27, 2014

astrofrog commented Feb 27, 2014

krngrvr09 commented Feb 27, 2014

astrofrog commented Feb 27, 2014

krngrvr09 commented Feb 27, 2014

astrofrog commented Feb 27, 2014

krngrvr09 commented Feb 27, 2014

krngrvr09 commented Feb 28, 2014

astrofrog commented Mar 1, 2014