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

MacOS: Implement XDG for MacOS (#4) #35

Closed
wants to merge 5 commits into from
Closed

Conversation

0az
Copy link

@0az 0az commented Aug 3, 2021

This also does some minor test restructuring.

Also, while I'm on the topic of breaking changes: thoughts on making roaming, multipath, and the proposed force_xdg kwargs keyword only?

TODO: rebase onto main, and write tests for MacOS proper.

Closes #4.

@0az 0az marked this pull request as draft August 3, 2021 05:31
@0az 0az mentioned this pull request Aug 3, 2021
Copy link
Contributor

@gaborbernat gaborbernat left a 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.

src/platformdirs/macos.py Outdated Show resolved Hide resolved
tests/common.py Outdated Show resolved Hide resolved
@0az
Copy link
Author

0az commented Aug 4, 2021

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.

Copy link
Contributor

@gaborbernat gaborbernat left a 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):
Copy link
Contributor

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?

Copy link
Author

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.

Copy link
Contributor

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 = {
Copy link
Contributor

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 🤔

Copy link
Author

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.

Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not supported?

Copy link
Author

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.

Copy link
Contributor

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.

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
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

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

Please no todos 👍

Copy link
Author

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 = {
Copy link
Contributor

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.

Copy link
Author

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.

Copy link
Contributor

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.

tests/test_android.py Show resolved Hide resolved
def test_compatibility(params: Dict[str, Any], func: str) -> None:
if sys.platform == "darwin":
@pytest.mark.parametrize("system", ("darwin", "unix", "win32"))
def test_compatibility(
Copy link
Contributor

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.

Copy link
Author

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.

Copy link
Contributor

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 🤔

@0az
Copy link
Author

0az commented Aug 4, 2021

Aside from the nits, what needs to be discussed is testing. I think that there's enough shared utilities to justify making a utils module under tests/, which I feel is a better structuring. At the very least, I can move the additions to .unix to it.

@gaborbernat
Copy link
Contributor

gaborbernat commented Aug 4, 2021

Aside from the nits, what needs to be discussed is testing. I think that there's enough shared utilities to justify making a utils module under tests/, which I feel is a better structuring. At the very least, I can move the additions to .unix to it.

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.

@gaborbernat
Copy link
Contributor

I'll close this for now due to lack of progress, if you pick this up again I'm happy to reopen it.

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

Successfully merging this pull request may close these issues.

Allow XDG_CONFIG_HOME on macOS
2 participants