Skip to content
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

Add function to generate the configuration file #10148

Merged
merged 17 commits into from
Apr 28, 2020

Conversation

saimn
Copy link
Contributor

@saimn saimn commented Apr 15, 2020

Ref #10146. This was fun and quick enough to do, but I had to hard-code the list of modules to import, not sure if there is a more clever (and simple) solution ?

Result: https://gist.github.com/saimn/b01966dbc6cef2c8c849ac4b933e84d3
This is almost the same as astropy.cfg, the order of subpackages is slightly different (alphabetical with the function here), and the only thing missing is the manual subsections like ### CORE DATA STRUCTURES AND TRANSFORMATIONS.

Next steps:

  • Find a way to include the output in the docs
  • Should this be used to update astropy.cfg occasionally, or replace it ?
  • Replace astropy.cfg is not so easy since it is used as a template for the default config file, which is checking while importing astropy. But the solution here takes a bit of time since it needs to import all modules with config items...

EDIT: Fix #10146

@pllim pllim requested a review from eteq April 15, 2020 12:45
@pllim
Copy link
Member

pllim commented Apr 15, 2020

A quick grep shows you where they are defined:

astropy/config/configuration.py:92:        conf = Conf()
astropy/io/fits/__init__.py:62:conf = Conf()
astropy/io/votable/__init__.py:36:conf = Conf()
astropy/logger.py:87:conf = Conf()
astropy/nddata/__init__.py:51:conf = Conf()
astropy/samp/__init__.py:39:conf = Conf()
astropy/table/jsviewer.py:30:conf = Conf()
astropy/table/__init__.py:45:conf = Conf()  # noqa
astropy/units/quantity.py:59:conf = Conf()
astropy/utils/data.py:95:conf = Conf()
astropy/utils/iers/iers.py:145:conf = Conf()
astropy/visualization/wcsaxes/__init__.py:41:conf = Conf()
astropy/__init__.py:134:conf = Conf()

Re: Replacing astropy.cfg -- Let's not get too ambitious right now, especially if we decide on not using it by default anymore as mentioned in #10090 (comment) . Also even if we want to replace it, how is it going to be generated in a way that is compatible with the various way that people might be installing it? Easiest option is maybe add a step for the release maintainer to do, as with updating the leap seconds table (ref).

@pllim pllim requested a review from mhvk April 15, 2020 13:00
@mhvk
Copy link
Contributor

mhvk commented Apr 15, 2020

This looks very good! My own sense would be to try to aim to have it auto-included in the documentation. If that's done at the end, we don't even have to worry about importing astropy modules...

@saimn

This comment has been minimized.

@saimn

This comment has been minimized.

@bsipocz
Copy link
Member

bsipocz commented Apr 16, 2020

@saimn
Copy link
Contributor Author

saimn commented Apr 16, 2020

@bsipocz - thanks, I just pushed something using pkgutil.walk_packages, and just skipping test packages.

@saimn
Copy link
Contributor Author

saimn commented Apr 21, 2020

So I added a very simple Sphinx extension to include directly the generated config in the docs:
https://64628-2081289-gh.circle-artifacts.com/0/docs/_build/html/config/astropy_config.html#astropy-config-file
with a link in https://64628-2081289-gh.circle-artifacts.com/0/docs/_build/html/config/index.html#getting-started

Should this extension go in sphinx-astropy ?
Should I update the astropy.cfg file for now ?

@pllim
Copy link
Member

pllim commented Apr 21, 2020

Should this extension go in sphinx-astropy ?

This extension only works for the core library, right? Should it just stay here like it is already in the PR?

@saimn
Copy link
Contributor Author

saimn commented Apr 21, 2020

Fine by me 👍

@bsipocz
Copy link
Member

bsipocz commented Apr 21, 2020

I see that we might want to use something like this for astroquery where we have configs for all subpackages, but keeping it in core for now sounds reasonable.

Copy link
Contributor

@mhvk mhvk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks very nice! I'll leave the question about where this should live to @astrofrog, but think starting in astropy certainly makes sense. Only one suggestion for making the creation a bit more elegant.

astropy/config/configuration.py Outdated Show resolved Hide resolved
docs/ext/astropy_config.py Outdated Show resolved Hide resolved
@saimn saimn added this to the v4.1 milestone Apr 23, 2020
@saimn

This comment has been minimized.

Copy link
Member

@pllim pllim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, this needs astropy/sphinx-astropy#30 for the HTML build to work properly, right?

Maybe add an entry to releasing procedures to update the astropy.cfg with this function before a release, near the instruction to update leap seconds table?

Overall, LGTM! I think with this in, the risk of the default astropy.cfg falling behind will decrease significantly. I also really appreciate the extra work that went into make the function useful for affiliated packages down the road. Thanks!

I'll let the sphinx-astropy dependency question get sorted out first before approving.

@@ -1,144 +1,169 @@
# -*- coding: utf-8 -*-
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

coding is removed. Does it affect anything?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was mostly an issue with Python 2, but with Python 3 it should be ok:

If no encoding declaration is found, the default encoding is UTF-8.
https://docs.python.org/3/reference/lexical_analysis.html#encoding-declarations

for mod in pkgutil.walk_packages(path=package.__path__,
prefix=package.__name__ + '.'):

if mod.module_finder.path.endswith('tests'):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just in case?

Suggested change
if mod.module_finder.path.endswith('tests'):
if mod.module_finder.path.endswith(('tests', 'test')):

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

# module name, but not if this is the root package...
if item.module != pkgname:
modname = item.module.replace(f'{pkgname}.', '')
fp.write(f"[{modname}]\n\n")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it safer to use os.linesep instead of "\n"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

open takes care of this by default:

  • On input, if newline is None, universal newlines mode is
    enabled. Lines in the input can end in '\n', '\r', or '\r\n', and
    these are translated into '\n' before being returned to the
    caller. [...]
  • On output, if newline is None, any '\n' characters written are
    translated to the system default line separator, os.linesep.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that's so good to know!

with open(outfile) as fp:
conf2 = fp.read()

for c in (conf, conf2):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a comment to explain why these specific lines are selected for testing? Were they arbitrarily selected or were there reasons?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a random selection 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment.

Copy link
Member

@pllim pllim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Since this depends on new feature in sphinx-astropy, I'll let @bsipocz and/or @astrofrog figure out when to merge.

Thanks!

@bsipocz
Copy link
Member

bsipocz commented Apr 28, 2020

Yes, merging this should wait until the sphinx-astropy release is out. Alternatively we can add the dev version as dependency in the meantime and wait with the release until the end of the RC testing period. Either would work equally well for me.

There is one more thing, we'll need to add a new minimum sphinx-astropy version requirement, otherwise the docs build will fail with the missing directive error.

@astrofrog
Copy link
Member

I've just released sphinx-astropy 1.3! Can you try adding that as a minimum requirement if we are going to be relying on this new plugin? (and this will also trigger a CI build)

@saimn
Copy link
Contributor Author

saimn commented Apr 28, 2020

It works: https://66219-2081289-gh.circle-artifacts.com/0/docs/_build/html/config/astropy_config.html#astropy-config-file

@bsipocz
Copy link
Member

bsipocz commented Apr 28, 2020

Thank you @saimn, this looks awesome now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature request: auto-generate overview of config items for docs
5 participants