Skip to content
This repository was archived by the owner on Mar 18, 2022. It is now read-only.

Make config file config option complete and a canonical source #29

Closed
agjohnson opened this issue Nov 2, 2017 · 1 comment
Closed
Labels
Needed: design decision A core team decision is required

Comments

@agjohnson
Copy link
Contributor

Currently, the configuration here is merged in with configuration from Project models in rtfd/readthedocs.org. This makes implementing configuration a confusing process, where configuration defaults here are not the defaults in rtfd/readthedocs.org, and there are discrepancies between the implementations.

Instead, this project should provide a complete configuration, with all of the options we want to move out of readthedocs.org and the admin dashboard -- or move to per-version configuration.

Requirements

Go through project admin dashboard and enumerate all of the configuration options that are missing. We first need to plan on the specification for the configuration structure additions/changes.

Once we have the spec firmed up, we need to add the options to the validation and parsing.

Finally, we can make the change on readthedocs.org that respects this as a canonical form of configuration. We probably still need a abstraction that maps the project configuration and config file configuration, just not in the manner it is structured now.

For instance, now, logic flow looks like this:

  • Get config parser from readthedocs-build
  • Parse config if its there
  • Config wrapper class looks for config option in parsed config
  • If no value there, look at project options
  • If no value there use arbitrary config default, not default defined in readthedocs-build spec

This should instead be:

  • Get config parser from readthedocs-build
  • Parse config if its there
  • Use config and defaults from parsed config if it exists
  • Use project options if config doesn't exist
@agjohnson
Copy link
Contributor Author

Superseded by #50

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Needed: design decision A core team decision is required
Projects
None yet
Development

No branches or pull requests

1 participant