New configuration API

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Implemented code proposal.png This article features an already implemented code proposal.

Implemented Proposals have had code checked in to the SVN repository. The Implemented Proposals should serve as documentation for the actual implementation. Developers should strive to update these as needed.

This is a proposal to replace the current configuration system with something more Pythonic and user-friendly.

Contents

Summary

Currently, configuration files are written in XML, which is overly verbose for this particular use case. An INI file would be easier for people to read and modify with a standard text editor.

Rationale

It might be argued that the files are never edited directly, but should the game crash due to a malformed XML file, a user might prefer being able to manually tweak a couple of lines in a configuration file, rather than deleting a file that they possibly spent a lot of time on and starting from scratch.

Furthermore, configuration file paths are currently hard-coded which restricts how the game can be packaged. Essentially, the way settings are handled currently prevents ticket #275 from being implemented properly.

Also, the current API for settings seems rather C++/Java-like rather than Pythonic. This proposal, if implemented, would make the interface more intuitive for Python programmers, and would actually reduce the amount of characters needed to manipulate configuration options. Please consider the following syntactic differences:

#simplified from common/utils.py and objects/actor.py
from fife.extensions.fife_settings import Setting

filename = 'settings.xml'
settings = Setting(app_name='PARPG', settings_file=filename)
speed = settings.get("PARPG", "PCSpeed") - 1

vs

#the new API
from parpg.settings import Settings

# filename is generated dynamically, so only the path to that file is needed
path = '.'
settings = Settings(path)
speed = settings.parpg.PCSPeed - 1

While it is not obvious from the above example, it is worth mentioning that my Settings class is able to load settings from multiple sources (eg. loading a system-wide configuration, then updating with user preferences).

Pros and Cons

Pros:

  • The format for config files is dramatically simplified.
  • accessing and manipulating these files is easier for programmers and players alike.
  • No quotes or parenthesis -- minimal punctuation.
  • No getter style methods. Sections and options are accessed as properties.
  • possibility to load from multiple config files (system vs user)
  • the previous point removes the need for a srettings version declaration. new options are automatically propogated to user config files

Cons:

  • default setting file needs to be converted from xml to ini format. (done)
  • source code needs to be adapted to cope with new settings api (done)

Implementation

  • my settings module (see [2] below) would need to be added to PARPG
  • initially, the only code that need be modified is the import statements and lines that instantiate the settings object (done)
  • eventually, all occurrences of settings.get() should need to be replaced by property access calls (done)
  • something similar would need to be done for portions of code that set setting values (done)
  • portions of fife_settings that dont belong in the new settings module should be migrated to a more suitable place (done)

Notes

  • If a settings file does not exist (or was accidentally deleted, the settings module is able to generate a new one, regardless of platform or deployment method.
  • The settings module automatically converts filetypes. As such, in most cases, str(), int(), float(), and list() methods should be unnecessary.
Personal tools