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
MacOS: Implement XDG for MacOS (#4) #35
Conversation
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.
Also, while I'm on the topic of breaking changes: thoughts on making roaming, multipath, and the proposed force_xdg kwargs keyword only?
This will be a hard no from my side. Also no need to rework the world, your changes really should only impact the macos (and perhaps the unix - though not yet sold on that) file.
Finished writing tests for coverage of the old/fallback cases for macOS. It's not 100% coverage, but it could cover the important branches pretty comprehensively. |
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.
The scope of this PR is clearly well defined, and affects only macos. I'm not sure why you're touching so many unrelated files.
|
||
class MacOS(PlatformDirsABC): | ||
|
||
class MacOS(Unix, PlatformDirsABC): |
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.
Why does this need to extend from unix?
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.
That's from the old version, forgot to remove it.
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.
Please fix it then 👍
|
||
XDG_SUPPORT = { |
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.
Why do we need this map, in the unix we achieve it without doing this 🤔
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.
It's there for the purposes of supporting testing. It's used to determine which compat tests to skip for macOS because of the introduction of XDG.
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.
Let's remove it. Tests should not really on globals from modules, otherwise a typo here would never be caught potentially.
|
||
XDG_SUPPORT = { | ||
"user_data_dir": "XDG_DATA_HOME", | ||
# "site_data_dir": "XDG_CONFIG_DIRS", # Not supported |
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.
Why not supported?
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.
Decided against, because a quick survey of what I have installed on my Mac shows that nothing actually used the site_*
/*_DIRS
variables except in vendored copies of appdirs. Actual usage of this seems to be much rarer than usage of XDG_{CONFIG,DATA,CACHE}_HOME
, which I believe is the part with the most adoption in practice.
As for logging: macOS's Console.app reads from the well-known platform logging directories. As such, it's a violation of platform expectations to drop logs elsewhere.
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.
Decided against, because a quick survey of what I have installed on my Mac shows that nothing actually used the
site_*
/*_DIRS
variables except in vendored copies of appdirs. Actual usage of this seems to be much rarer than usage ofXDG_{CONFIG,DATA,CACHE}_HOME
, which I believe is the part with the most adoption in practice.
I'd rather follow the XDG spec then such local quick surveys, unless macOS clearly advises against it (as is the case of the logging).
# "site_config_dir": "XDG_CONFIG_DIRS", # Not supported | ||
"user_cache_dir": "XDG_CACHE_HOME", | ||
"user_state_dir": "XDG_STATE_HOME", | ||
# "user_log_dir": "XDG_CACHE_HOME", # Not supported b/c Console |
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.
Because what console, please be more descriptive, but better add it right within user_log_dir not here.
@@ -93,6 +113,7 @@ def user_state_dir(self) -> str: | |||
path = os.path.expanduser("~/.local/state") | |||
return self._append_app_name_and_version(path) | |||
|
|||
# TODO: As per XDG spec, logs should be placed under XDG_STATE_HOME |
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.
Please no todos 👍
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.
Forgot to remove. Will file another issue for it, if I remember.
"user_log_dir": "XDG_CACHE_HOME", # Should be in XDG_STATE_HOME as per spec | ||
} | ||
# Mapping between function name and relevant XDG var | ||
XDG_DEFAULTS = { |
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.
You define these but doesn't seem used. The scope of this PR is to change only macos, so not sure why we need to touch even this file.
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 wanted to document the spec compliance in a way such that it was usable in testing.
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'd be -1 on this. IMHO the tests should not use such globals, because effectively you're no longer testing the content of this. A typo in this silently would be ignored. Let's not do this, the test can declare it's own copy of this, so we have some sanity check in between them.
def test_compatibility(params: Dict[str, Any], func: str) -> None: | ||
if sys.platform == "darwin": | ||
@pytest.mark.parametrize("system", ("darwin", "unix", "win32")) | ||
def test_compatibility( |
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 don't agree we need to touch this test in any shape and form.
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 can revert that specific change and add it to a different PR. However, the test does need to be changed so that it doesn't fail on known compat breaks: i.e. when the supported subset of XDG_* is in os.environ
.
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.
In the previous format the test does not validate compatibility with XDG on 🤔
Aside from the nits, what needs to be discussed is testing. I think that there's enough shared utilities to justify making a |
You have fixtures to share code, so you don't need utils. Also I'd prefer if this PR would not try to revamp the existing testing infrastructure, and we do that as a follow-up PR. |
I'll close this for now due to lack of progress, if you pick this up again I'm happy to reopen it. |
This also does some minor test restructuring.
Also, while I'm on the topic of breaking changes: thoughts on making
roaming
,multipath
, and the proposedforce_xdg
kwargs keyword only?TODO: rebase onto main, and write tests for MacOS proper.
Closes #4.