Need to implement preferences parser.

[zancas]

This issue is complete when the specification of the preferences file (1.0) is complete, a parser has been implemented, tested, and documented.

The spec should include (at a minimum):

• more than 1 example "preferences.ini" file
• A first-draft list of ini heading "technologies", e.g. ".py", ".js",...
• An abstract specification of section names
• a vocabulary for discussing the components of the file

All of the above in some clear readable, format/location

[recursivelycurious]

@dangle - could point me to a good example specification for an ini file? I am trying to wrap my head around what the "specification" itself consists of as a deliverable, and Za suggested you might know of an example or two?

nvm - looking at tox :)

[recursivelycurious]

The deliverable that completes this project is part of the alpha documentation that would be used by a developer looking to contribute to the project.

[dangle]

One thing to note is that you can use ConfigParser. If you do go that route, import it from six.moves.configparser though.

[zancas]

@michaeldayreads @dangle

The Incorporate Preferences Unit receives:

(0) the required image
(1) the list of required technologies
(2) the preferences.ini file

It produces:

The preferences dockerfile

[zancas]

It can be broken down into subtasks, with subcontracts.

[zancas]

Wait... what's this business about "six", contain is >= python3.5.2 or python3.5.3, right?

[dangle]

Good call, but I thought we were going 3.3?

[dangle]

For the record, 3.4 is what we've agreed on out of band.

I'm going to rename this one and merge the other preference issues into this one. Those are subtasks at best.

Going forward, I suggest that we each issue we create for functionality be a complete piece of work, including testing and documentation.