-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
intersphinx xref #40
intersphinx xref #40
Conversation
a0b5de7
to
557cf89
Compare
astropy/astropy#11684 shows that this will not break astropy due to circular imports. |
I'm not convinced about the cross-reference/dependency with astropy, this may cause problems in the future. Could we put a static list instead ? I guess the list doesn't change often so we could avoid the dynamic generation. |
Do you mean having astropy be a run-time requirement of this package? I was initially concerned (hence astropy/astropy#11684) as I wasn't sure that the local package (astropy) got installed before the documentation requirements, but since it does, there shouldn't be any issues unless the installation order changes. I think PIP and Conda handle that, or does TOX also have a say? I feel good about PIP and Conda, but am not overly familiar with tox.
The issue then is that any time astropy wants to update the list, sphinx-astropy needs a new release. Dynamic generation obviates the maintainer burden.
Agreed. It is here. I have a comment explaining how to turn it on.
I don't think I understand what you're suggesting here. Could you please clarify what would go into One large danger with adding sphinx links to the numpydoc xref regardless of astropy version is that they can cause the docs to fail, depending on the astropy version. I don't think NOT including them will fail a numpydoc xref unless the the docs are built with an earlier version of astropy than is supported in the code. |
bc055c7
to
79f4303
Compare
ping @astrofrog @pllim @saimn @bsipocz. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am in agreement with @saimn that we shouldn't have astropy as a dependency here - instead we should just make use of it if it is installed but not otherwise. For most packages that use this astropy will be a required dependency anyway, and for astropy core we will avoid installing a stable astropy into a development build of the astropy docs.
To be clear, is there any risk of this breaking anything which would warrant a v2 config? I suspect not since this is opt-in, but just wanted to check.
@saimn, I've incorporated @astrofrog's suggestion to make Astropy an optional dependency. The xref dictionaries are empty if Astropy is not installed or <v4.3 and full otherwise. Does this address the points you raised about cross-dependencies and working around that by static lists? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @nstarman, yes I agree the approach seems reasonable now. Just needs a small change.
sphinx_astropy/conf/v1.py
Outdated
# convenience. | ||
numpydoc_xref_ignore = { | ||
"type", "optional", "default", "or", "of", "method", "instance", | ||
"class", "subclass", "keyword-only", "default", "thereof", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default
is listed twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. I'll push the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @nstarman, sounds good now.
@astrofrog - Do you want to have another look ?
Signed-off-by: Nathaniel Starkman (@nstarman) <[email protected]>
Signed-off-by: Nathaniel Starkman (@nstarman) <[email protected]>
Signed-off-by: Nathaniel Starkman (@nstarman) <[email protected]>
Signed-off-by: Nathaniel Starkman (@nstarman) <[email protected]>
Signed-off-by: Nathaniel Starkman (@nstarman) <[email protected]>
cleanup dynamic generation Signed-off-by: Nathaniel Starkman (@nstarman) <[email protected]>
The version check only runs if astropy is installed. Also update numpydoc xref ignores, from review comment. Signed-off-by: Nathaniel Starkman (@nstarman) <[email protected]>
d57a237
to
1001d69
Compare
Given the approval, I've squashed some unnecessary commits. GTG. |
Thanks @nstarman ! |
Thanks for the reviews! |
Re: release -- Probably needs a new release but... @saimn , looks like we never set up a auto publish workflow here. Hmm! |
Yep, will try to set it up in the coming days. |
@nstarman , this is now in https://pypi.org/project/sphinx-astropy/1.4/ |
Awesome! Thanks. |
Many thanks to @saimn ! 😸 |
Signed-off-by: Nathaniel Starkman (@nstarman) [email protected]
numpydoc_xref_aliases_astropy_glossary
, an xref mapping that can be added to thenumpydoc_xref_aliases
in packages by dictionary updating. This is designed for easy inclusion of astropy's glossary.numpydoc_xref_aliases_astropy_physical_type
, an xref mapping that can be added to thenumpydoc_xref_aliases
in packages by dictionary updating. This is designed for easy inclusion of astropy's physical-type x-refs.numpydoc_xref_astropy_aliases
, an xref ChainMap of the above mappings that can be added to thenumpydoc_xref_aliases
in packages by dictionary updating. This is designed for easy inclusion of ALL of astropy's intersphinx offerings.Fixes #39
Fixes #20
Request Review : @bsipocz @pllim @saimn @astrofrog