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

Preferences: allow formats other than .ini/ConfigObj #268

Open
corranwebster opened this issue Dec 22, 2020 · 1 comment
Open

Preferences: allow formats other than .ini/ConfigObj #268

corranwebster opened this issue Dec 22, 2020 · 1 comment

Comments

@corranwebster
Copy link
Contributor

Currently apptools.preferences uses .ini files mediated by ConfigObj. This was a reasonable choice in 2008, but now there are other possible configuration file formats that might be reasonably used. Candidates include:

  • JSON
  • YAML
  • TOML
  • XML

Different applications may want to used different formats because they are easier to manually write, or because they need to be interpreted by other systems where .ini format does not have an easily available reader; or integrate with existing systems which have made different choices. Also the long-term future of ConfigObj is unclear - it works, but is also not being updated frequently.

Fortunately the actual file-handling code in the main Preferences is wholly contained within the save and load functions. It would be straightforward to add hooks to read from different formats based on file extensions; and to write to a particular format based on configuration of the preferences system.

One consideration is that the current system assumes that all data is text, while other systems permit additional data types for things like numbers, lists and mappings. This is primarily an issue for reading of files, particularly if they have been manually edited; other value types may need to be explicitly cast to strings.

Similarly, other formats have notions of hierarchical structure which have been imposed on the .ini format manually (by .-separated section names). Some thought may need to be put into how we want to handle this: do we want a flat structure with .-separated sections, or a nested structure using the components.

@mdickinson
Copy link
Member

mdickinson commented Sep 1, 2021

I think the dependence on the configobj package is going to become untenable longer term. The last release of that package was over 7 years ago. One way in which it might fail is that configobj still requires six, and I could see six becoming unsupported in some future version of Python (there are already bits of six that issue warnings with Python 3.8 and fail with Python 3.9, for example).

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

No branches or pull requests

2 participants