Skip to content

Allow custom root directory for config#8237

Merged
bsipocz merged 26 commits intoastropy:masterfrom
Cadair:config-custom-dir
Oct 28, 2019
Merged

Allow custom root directory for config#8237
bsipocz merged 26 commits intoastropy:masterfrom
Cadair:config-custom-dir

Conversation

@Cadair
Copy link
Member

@Cadair Cadair commented Dec 6, 2018

This PR makes three main changes to the way configuration files are handled, one is intended for affiliated package authors and two affect end users.

  1. Allow the customisation of the directory name for configuration files, via the rootname argument. This allows affiliated package authors to use a directory like ~/.dkist/config/dkist.cfg rather than ~/.astropy/config/dkist.cfg

  2. Provide a user facing helper (the previous API wasn't user facing but hasn't been changed) to be called if the user wants to write out the default config for subsequent manual editing.

  3. Remove the code that automatically writes the template config to disk on import of astropy (fixes Consider providing template config file in docs instead of writing to disk #8552)

It also makes one minor change, get_config_dir now defaults to create=False so as to not create the config dir when a config file is not to be written to it.

This is a replacement for #6985

TODO:

  • Add documentation on writing and editing default config files.
  • Rebase this mess.

@Cadair
Copy link
Member Author

Cadair commented Dec 6, 2018

So this seems to be working in DKISTDC/dkist#3

@pllim pllim requested a review from eteq December 6, 2018 20:13
@pllim pllim added the config label Dec 6, 2018
@pllim pllim added this to the v3.2 milestone Dec 6, 2018
@Cadair
Copy link
Member Author

Cadair commented Dec 6, 2018

Edit: This is now irrelevant.

@eteq I think this is almost ready to roll. The one bit I don't understand is how it interacts with this:

https://github.com/astropy/package-template/blob/cookiecutter/%7B%7B%20cookiecutter.package_name%20%7D%7D/%7B%7B%20cookiecutter.module_name%20%7D%7D/_%7B%7B%20cookiecutter._parent_project%20%7D%7D_init.py#L43-L60

bit of the package template. That code seems obnoxiously complex and if we have to ask affiliated package authors to modify it like I have here: https://github.com/DKISTDC/dkist/pull/3/files#diff-03100dba6855f116c1325d9e7258e54e then it might need a re-think.

@astrofrog
Copy link
Member

Can a template version of that code not exist in astropy.config instead of in affiliated packages?

@codecov
Copy link

codecov bot commented Apr 16, 2019

Codecov Report

Merging #8237 into master will decrease coverage by 0.16%.
The diff coverage is 88.05%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8237      +/-   ##
==========================================
- Coverage   87.13%   86.96%   -0.17%     
==========================================
  Files         408      400       -8     
  Lines       62061    59330    -2731     
  Branches     1096     1100       +4     
==========================================
- Hits        54077    51597    -2480     
+ Misses       7362     7092     -270     
- Partials      622      641      +19
Impacted Files Coverage Δ
astropy/config/configuration.py 84.07% <100%> (-0.04%) ⬇️
astropy/utils/data.py 80.93% <100%> (-1.27%) ⬇️
astropy/config/paths.py 70.68% <69.23%> (+1.33%) ⬆️
astropy/visualization/wcsaxes/coordinates_map.py 86.88% <0%> (-11.65%) ⬇️
astropy/modeling/mappings.py 84.31% <0%> (-8.79%) ⬇️
astropy/convolution/src/convolve.c 80.68% <0%> (-8.34%) ⬇️
astropy/stats/jackknife.py 89.28% <0%> (-7.39%) ⬇️
astropy/wcs/src/str_list_proxy.c 60.43% <0%> (-7.38%) ⬇️
astropy/wcs/src/unit_list_proxy.c 54.92% <0%> (-5.94%) ⬇️
astropy/stats/histogram.py 92% <0%> (-5.85%) ⬇️
... and 201 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 297589c...a6c4169. Read the comment docs.

@Cadair
Copy link
Member Author

Cadair commented Apr 16, 2019

Oh good, the tests seem to write the config to a different path on Python 3.5 🤦‍♀️

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.

Only had a glance, really, but like where this is going. Comments incomplete.

Copy link
Member

@astrofrog astrofrog left a comment

Choose a reason for hiding this comment

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

Looks good to me! Other than the minor comments/questions below, could you add a small section to the narrative docs mentioning this capability? (http://docs.astropy.org/en/stable/config/index.html)

pkgname : `str`, optional
The package name to use to locate the download cache. i.e. for
``pkgname='astropy'`` the default cache location is
``~/.astropy/cache``.
Copy link
Member

Choose a reason for hiding this comment

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

Related to my previous comment, here you have ~ as the prefix for the config dir.

Copy link
Member Author

Choose a reason for hiding this comment

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

I am not entirely sure what the behaviour is here, so I think this is probably the best way to doc it.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe instead of assuming it is ~/.astropy, crosslink to the config doc, since over there, it explains that user can further customize with XDG stuff?

Copy link
Member Author

Choose a reason for hiding this comment

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

To be honest I am going to open another PR after this which will change all the directories stuff anyway, so I don't really think it's worth going down the pit with.

@Cadair
Copy link
Member Author

Cadair commented Apr 17, 2019

Ok I have now added docs to this, (I also removed the old 0.4 migration docs) and addressed all the comments. I think this is ready for review again.

@bsipocz bsipocz requested a review from astrofrog April 17, 2019 23:38
@pllim pllim self-requested a review April 18, 2019 17:00
@pllim
Copy link
Member

pllim commented Apr 18, 2019

For item 3 you mentioned above, are there unwanted side effects? Like, we added a new item or changed default of existing item but template no longer gets copied over, but user has an older version from last install, so user now accidentally using an outdated config?

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.

Usage of both "config" and "configuration" interchangeably is confusing to read. Either do something like "configuration (hereafter, config)" and then only use "config" after, or stick to "configuration" unless you are referring to config as in a variable name.

For affiliated package maintainers like myself, I would like a section to help those who want to transition from ~/.astropy (as they had no choice before) to using their own root name now; i.e., what function to call differently in their own config, how they should tell their users about the switch (what old files to get rid of), and so on. Helper functions would be even better but probably out of scope here.

return digest in known_configs


def write_default_config(pkg, rootname=None):
Copy link
Member

Choose a reason for hiding this comment

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

I find it very confusing that this function has the same name as the one in __init__.py.

Copy link
Member Author

Choose a reason for hiding this comment

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

The purpose of this is to be overrideable for affiliated packages and the one in __init__.py just has the defaults set for the specific package.

pkgname : `str`, optional
The package name to use to locate the download cache. i.e. for
``pkgname='astropy'`` the default cache location is
``~/.astropy/cache``.
Copy link
Member

Choose a reason for hiding this comment

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

Maybe instead of assuming it is ~/.astropy, crosslink to the config doc, since over there, it explains that user can further customize with XDG stuff?

@pllim pllim modified the milestones: v3.2, v4.0 Apr 19, 2019
@Cadair Cadair force-pushed the config-custom-dir branch from b7bf526 to b49a18c Compare April 24, 2019 10:14
@Cadair
Copy link
Member Author

Cadair commented Apr 24, 2019

For item 3 you mentioned above, are there unwanted side effects? Like, we added a new item or changed default of existing item but template no longer gets copied over, but user has an older version from last install, so user now accidentally using an outdated config?

This behaviour is the same as before, currently if the user has changed their config a new template is written with the version number appended. This is the same behaviour as used here, just it happens explicitly when called rather than on import.

@Cadair
Copy link
Member Author

Cadair commented Apr 24, 2019

@pllim I think I have addressed all your review comments now.

@Cadair Cadair force-pushed the config-custom-dir branch from 08e0697 to 6319363 Compare April 24, 2019 14:43
@Cadair
Copy link
Member Author

Cadair commented Apr 24, 2019

The doc fail seems unrelated.

@Cadair Cadair force-pushed the config-custom-dir branch 2 times, most recently from db42f39 to 5dd0285 Compare April 25, 2019 10:59
@Cadair Cadair force-pushed the config-custom-dir branch from 3b1b136 to d98b06d Compare October 28, 2019 13:58
@Cadair
Copy link
Member Author

Cadair commented Oct 28, 2019

Ok, I finally fixed the stupid changelog.

@astrofrog astrofrog changed the title Allow custom root directory for config (Mk III) Allow custom root directory for config Oct 28, 2019
Copy link
Member

@astrofrog astrofrog left a comment

Choose a reason for hiding this comment

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

Just confirming that this looks good to me

@pllim
Copy link
Member

pllim commented Oct 28, 2019

Shall we merge then?

@bsipocz
Copy link
Member

bsipocz commented Oct 28, 2019

Let's get on with this then.

Thank you @Cadair!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consider providing template config file in docs instead of writing to disk

6 participants