Skip to content

Fix configuring astropy cache location#17514

Merged
neutrinoceros merged 2 commits intoastropy:mainfrom
eerovaher:read-xdg_cache_home
Dec 12, 2024
Merged

Fix configuring astropy cache location#17514
neutrinoceros merged 2 commits intoastropy:mainfrom
eerovaher:read-xdg_cache_home

Conversation

@eerovaher
Copy link
Member

@eerovaher eerovaher commented Dec 6, 2024

Description

657c91a (from #16997) introduced a bug to customizing the astropy cache directory. The XDG_CACHE_HOME environment variable has no effect, instead XDG_CONFIG_HOME controls both configuration and cache directories.

The first commit adds a regression test to reveal the bug, the second fixes it.

PS https://www.astropy.org/team does not document who the maintainers for config are.

  • By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

@github-actions
Copy link
Contributor

github-actions bot commented Dec 6, 2024

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

  • Do the proposed changes actually accomplish desired goals?
  • Do the proposed changes follow the Astropy coding guidelines?
  • Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
  • Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
  • Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
  • Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
  • Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
  • Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
  • At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

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.

Looks good to me, thanks @eerovaher!

if (
(xdg_config_home := os.getenv("XDG_CONFIG_HOME")) is not None
and (xch := Path(xdg_config_home)).exists()
(xdg_dir := os.getenv(f"XDG_{fallback.upper()}_HOME")) is not None
Copy link
Contributor

Choose a reason for hiding this comment

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

Might be useful to specify above that fallback can take a limited number of values.

Copy link
Contributor

Choose a reason for hiding this comment

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

yes. We could also expose the environment variable directly as a separate argument, since it's a private function, there's no pressure to preserve its API.

Copy link
Member Author

@eerovaher eerovaher Dec 11, 2024

Choose a reason for hiding this comment

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

Might be useful to specify above that fallback can take a limited number of values.

A good way to do that would be to change the type annotation of the fallback parameter from str to Literal["cache", "config"], but it would also be a good idea to update the annotation of the cls parameter from type to type[_SetTempPath] and there is more room for improvement elsewhere in this file. My preference would be to only make minimal required changes here to fix the bug and to open a separate pull request for the annotations.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds like a plan to me. Final question before I merge: do you want to do the follow up yourself too ? (either way is fine)

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 wouldn't mind updating the annotations myself.

Copy link
Contributor

Choose a reason for hiding this comment

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

alright then :shipit:

@eerovaher
Copy link
Member Author

I've figured out why the double test CI job failed, but I don't have a good solution how to get it to work. The double test job uses the astropy test runner, whereas the other jobs run pytest directly:

astropy/tox.ini

Line 125 in 2e7cf84

double: python -c 'import sys; from astropy import test; test(); sys.exit(test())'

The astropy test runner configures the cache directory using set_temp_cache():
with set_temp_cache(astropy_cache, delete=True):

set_temp_cache() is supposed to have priority over environment variables, which fully explains why changing the environment variables in the new test has no effect in that one CI job.

The best solution would be to skip the new test if and only if the tests are run using the astropy test runner, but I don't know how to do that. A simple solution would be to use set_temp_cache() and set_temp_config() in the test, but I don't like the idea of adding these extra steps to the test just because of the astropy test runner.

@neutrinoceros
Copy link
Contributor

A simple solution would be to use set_temp_cache() and set_temp_config() in the test, but I don't like the idea of adding these extra steps to the test just because of the astropy test runner.

One more data point in favor of killing the test runner, but as long as we agree to live with it, this might be the only way out.

pllim
pllim previously approved these changes Dec 9, 2024
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.

Good catch. Thanks!

Original config designer was probably mdboom who left some time ago. 🙈

@pllim
Copy link
Member

pllim commented Dec 9, 2024

Your tests seem to fail in the "double" run, so that needs to be fixed before this can be merged: https://github.com/astropy/astropy/actions/runs/12203451342/job/34046435787?pr=17514

@eerovaher
Copy link
Member Author

Your tests seem to fail in the "double" run, so that needs to be fixed before this can be merged: https://github.com/astropy/astropy/actions/runs/12203451342/job/34046435787?pr=17514

I find it quite disturbing that you have approved this pull request when it is clear that you have not read the discussion at all.

@mhvk
Copy link
Contributor

mhvk commented Dec 9, 2024

Like many (certainly like me), @pllim probably looks at the actual changes and approves those, and then realizes a test is broken. That that was discussed further above just goes to show that the github way of organizing things is far from optimal -- reading longer discussions is extremely tedious since there is no organization, no way to resolve pieces of the main thread, etc.

Anyway, @pllim, know we know you are the one that keeps this ship going! Thanks!!

@pllim
Copy link
Member

pllim commented Dec 9, 2024

Yes, indeed I jumped to the diff first. I do not have time to always read all the discussions, especially since now I am trying to play catch up after being away. But that is neither here nor there. I should probably dismiss my approval for now. Thanks, all.

@pllim pllim dismissed their stale review December 9, 2024 23:02

Failing CI

@pllim
Copy link
Member

pllim commented Dec 9, 2024

Re: double trouble -- A workaround is to set a IS_DOUBLE for the "double" job and have a test skip on that condition. Maybe here:

setenv =

Or maybe like this:

https://github-actions-workflows.openastronomy.org/en/stable/tox.html#setenv

Not pretty but it would disappear when we remove the test runner.

@neutrinoceros
Copy link
Contributor

I just merged #17529 and set its backport to auto-merge.

It should be possible to configure the `astropy` configuration and cache
directories with the `XDG_CONFIG_HOME` and `XDG_CACHE_HOME` environment
variables, but the new test reveals that the latter has no effect.
657c91a (MNT: Run PTH flake test in
prep for supporting pathlib (config)) introduced a bug which caused the
`XDG_CACHE_HOME` environment variable to be ignored and
`XDG_CONFIG_HOME` to control both configuration and cache directories
(if set). The correct behaviour has been restored, but removing any
cache files from unintended locations is not attempted.
@neutrinoceros
Copy link
Contributor

neutrinoceros commented Dec 11, 2024

Approving now but giving time for @eerovaher to answer the one hanging thread before I merge

@eerovaher eerovaher deleted the read-xdg_cache_home branch December 12, 2024 13:45
pllim added a commit that referenced this pull request Dec 12, 2024
…514-on-v7.0.x

Backport PR #17514 on branch v7.0.x (Fix configuring `astropy` cache location)
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.

5 participants