doc: proposed design #16
Conversation
| Configurations are distinct from data, although the line is hard to define. | ||
| In our approximation, an application can run without data, but it cannot run | ||
| without a configuration. A configuration can be packaged and imported, but | ||
| data cannot. |
There was a problem hiding this comment.
I like this philosophy statement! I'm not 100% sure what "packaged" or "imported" mean in this context, but I'm willing to believe them.
There was a problem hiding this comment.
It's pretty fuzzy, and I think we can really improve the language here. Maybe:
A configuration can be packaged and imported, but data cannot.
Unlike data, a configuration has a fixed size and structure and can easily be expressed in code.
|
This is looking great! I've read a portion so far before needing to head out; I'll be sure to get back to this soon. |
|
|
||
| :: | ||
|
|
||
| user_config_paths(*paths) |
There was a problem hiding this comment.
Organizational note: perhaps the from_* functions, which return configurations, should get a separate section from these other source-finding utilities.
There was a problem hiding this comment.
Absolutely.
|
This is looking great! We're definitely on the right track. For the next few steps, would you rather work in your fork (I send pull requests there) or create a "v2" branch here (and I'll still use pull requests from "feature branches" to get your feedback)? |
|
I'd rather work in my fork and let you pull things in as you like. I've started work on the implementation, I think I can have a prototype in a few days, as I find time. I'll try to port the tests too. |
|
OK, sounds great. I may even send pull requests your way while we're still living in the branch. |
I moved the changes to a branch, killing the old pull request. This way you can rebase onto master for a clean log if you want.