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

configuration should be stored in a 'dot' file #21

Closed
jaraco opened this issue Feb 24, 2015 · 9 comments
Closed

configuration should be stored in a 'dot' file #21

jaraco opened this issue Feb 24, 2015 · 9 comments

Comments

@jaraco
Copy link
Owner

jaraco commented Feb 24, 2015

Using "keyring_pass.cfg" goes against years of standard conventions for configuration files. Instead it should start with a dot, ".keyring_pass.cfg" or ".pykeyringrc", so it doesn't clutter up the directory listing.


@jaraco
Copy link
Owner Author

jaraco commented Feb 24, 2015

The config file I meant to talk about is actually "keyringrc.cfg", but the same reasoning applies to both files.


Original comment by: erh

@jaraco
Copy link
Owner Author

jaraco commented Feb 24, 2015

Or, to reduce clutter in people’s home directories, follow the freedesktop.org Base Dir Specification.


Original comment by: Éric Araujo

@jaraco jaraco closed this as completed Feb 24, 2015
@jaraco
Copy link
Owner Author

jaraco commented Feb 24, 2015

I don't know if there are any cases where the .cfg file is written on Windows, but if it is, it should not be in a dot-prefixed directory or file, but in "%appdata%%vendor%\Python Keyring\config.txt" (or .ini or .xml or whatever extension reflects the content).


Original comment by: Jason R. Coombs

@jaraco
Copy link
Owner Author

jaraco commented Feb 24, 2015

I've put together [[https://bitbucket.org/jaraco/keyring-file-locations/compare/..kang/python-keyring-lib|these changesets that address this issue]]. The biggest challenge with this work is maintaining backward compatibility. I'd like someone to please review the changesets and suggest any enhancements before I integrate it into the main repo.


Original comment by: Jason R. Coombs

@jaraco
Copy link
Owner Author

jaraco commented Feb 24, 2015

I will look at it.


Original comment by: Jonathan Ballet

@jaraco
Copy link
Owner Author

jaraco commented Feb 24, 2015

Jason >

  • I didn't tested you changes yet, but it looks very reasonable so far, good work!
  • you also need to deal with the keyring configuration file in core.py, which should be stored in $XDG_CONFIG_HOME or ~/.config. You can apply the same process as you did for the keyring passwords, maybe you will want to have a backcompat.py module to put your relocate() function inside so that you can reuse it with core.py ;
  • don't address the search of the config file in the current directory if you are willing to, this should be addressed somewhere else ;

I think we will need to add loggers so that users can see where there configuration files are read from and write to, it's now less "obvious" at first glance. That can be addressed later, though.


Original comment by: Jonathan Ballet

@jaraco
Copy link
Owner Author

jaraco commented Feb 24, 2015

Keyring password storage is now stored in a platform-friendly way and not just in the user's home directory. Follows freedesktop.org Base Dir Specification on Unix and Windows convention on Windows. Fixes #21.

→ <<cset 946d290a34ff>>


Original comment by: Jason R. Coombs

@jaraco
Copy link
Owner Author

jaraco commented Feb 24, 2015

Thanks! There is a small issue in the patch: depending on your kernel and Python version, sys.platform may be 'linux3' or 'linux', so it looks like you need to expand the one-liner on the last line :)


Original comment by: Éric Araujo

@jaraco
Copy link
Owner Author

jaraco commented Feb 24, 2015

Thanks for the tip, Éric. I've update the code to [[https://bitbucket.org/kang/python-keyring-lib/changeset/a61b05b8449f|use the platform module]], which should address the issue and be more robust.


Original comment by: Jason R. Coombs

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

No branches or pull requests

1 participant