Design around multiple configurations in one file

[stsewd]

Related code https://github.com/rtfd/readthedocs.org/blob/a98441717ea50b19fe6bb0f1ea52df092dbc8190/readthedocs/config/config.py#L988-L988

I'm not sure what use case has. Maybe a monorepo? But still, rtd doesn't support that workflow (more the one doc per project).

[agjohnson]

I'm +1 on getting rid of the logic that searches for a readthedocs.yml file. I think we should only support one top-level config file, all of the other UX patterns are weird.

• Config in some other directory: why not just put it top level?
• Multiple configs: which one are we supposed to use?
• Config in submodule or something: why would you want to use it?

[stsewd]

Oops, I think I put the wrong title here, for multiple configurations files the issue is #4669. This is for a configuration file with multiple configurations (yaml support having a top level dict)

[humitos]

@stsewd I found this issue a bit confusing. Can you expand on the purpose of it and what it's needed to do/decide here?

[stsewd]

Our code is designed to support several configurations in one yaml file (yaml allows to have more than one top dict), but in reality we only use the first one, so we have some dead code here, and maybe we aren't going to use it (v2 uses only one too).

[humitos]

I see...

So,

But still, rtd doesn't support that workflow (more the one doc per project).

RTD does not support more than one doc per project, but if the repository has multiple translations the use will import the same repo many times as different (sub)projects. In that case, we may want to allow:

1. multiple YAML files
2. multiple configs on the same YAML file
3. none of the above and force to build all the projects with the same YAML since the only thing that should change on each different translation are the .po files.

I'm mentioning 3) even though it's not a problem in that particular case, but as an example that it could be useful in some weird case, maybe.

At first, it seems we could kill that code.

[agjohnson]

I think our translations workflow needs to be ripped apart eventually. Adding a translation should not require a separate file on the repo. However, currently, you shouldn't need a separate config file for this, the language selector is in the admin UI.

We've discussed in other tickets, but translations will eventually just be another project setting (ie, just enable "Español" translation to your project like you do versions, not add a separate project).

I'm still -1 on multiple config files I think, this is in line with other services like travis and circleci

[stsewd]

Just to be clear, this is about having multiple configs in one file p: anyway, looks like we don't have a use case for this is kind of the same as having multiples files.

[ericholscher]

+1 on removing multiple configs in a single file. I don't see any use-case for this. I do see value in being able to do something like defining multiple translations for a project, but I don't think having totally different configs in a single file make sense for that currently.