Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

pyGBot.ini "channel" option fixes #37

Closed
Laogeodritt opened this Issue · 4 comments

3 participants

@Laogeodritt
Collaborator

Current "channel" option spec/behaviour in pyGBot.ini:

  • pyGBot.ini comments state not to quote the value (i.e. not to use field = "value").
  • channel parameter requires a space-separated list of channels without leading # character.
  • The # character is considered to begin an inline comment when used on a value line (by ConfigObj). It is interpreted as a literal character iff the value is quoted (i.e. ̀field = "value with a # character in it"` will interpret the literal # character as part of the value).
  • It is not possible to join a channel with a double-hash prefix, e.g. ##electronics, which is common on some networks like freenode.

Proposed changes:

  • Remove the line in the default ini comments stating not to use value quotes.
  • channel parameter shall require a space-separated list of channels with the leading # character (regular channel name), and MUST be placed in quotes for it to work. Edit the instructions to that effect.

ConfigObj reference: http://www.voidspace.org.uk/python/configobj.html

Submitting this as a todo when I find time for pyGBot, more or less. Feel free to pick this up if you want, though; the changes are fairly mundane.

@Dritz
Owner

I might pick this up myself soon, as a warmup to get me back into development.

@Dritz Dritz was assigned
@chaos95
Owner

Maybe we should just switch to YAML or JSON for config :P

@Dritz
Owner

YAML might work, but isn't JSON not as readable?

Either way, a rework like that should probably be filed under "someday maybe". This fix will be easy, at least.

@Laogeodritt
Collaborator

JSON is fairly readable if formatted nicely (... does the spec allow extra whitespace?), just requires a hell of a lot of extraneous quotation marks. (Not as bad as XML! Ugh, so verbose for no reason.) I would suggest against it for the reason that it's a bit too strict for hand-edited configuration; I'd rather go with a more leniently-specified language.

YAML might work. It represents arbitrary objects, so we might be able to organize everything decently.

I also think it'd be a good idea to separate out plugin configuration files so that third-party or separately-shipped plugins could ship with default/annotated plugins, instead of having to merge into the main bot config.

... again, all cursory ideas that should probably be submitted as enhancements XD

@Dritz Dritz closed this in 4c10f69
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.