Ability to specify one-off custom .readthedocs.yml config when manually triggering builds

[apocalyptech]

I recently released a v1.4.0 of a project of mine but hadn't noticed that the RTD docs had been failing until after I'd cut the release and uploaded it elsewhere. The problem was basically down to not having a .readthedocs.yml in the project, and the only way to really "fix" the docs generation @ RTD was to commit a config file and then immediately cut a new v1.4.1.

It'd be nice if there was some way to specify a one-off .readthedocs.yml to use when triggering a manual build, so I could've kept my version at v1.4.0 and still have it be RTD-hosted. I expect this is probably a very nontrivial thing to request, and probably only useful in edge cases, but figured I'd float the idea anyway.

In my particular case, something else that would've enabled me to trigger a v1.4.0 rebuild and have it work would've been to have better control over the Python version in the Advanced Settings tab -- my issue was basically due to the doc-building process being run in Python 3.7. Python versions 3.8+ would've worked fine. The dropdown in Advanced Settings only lets one choose between 2.x and 3.x, though. I can understand that you'd prefer to direct folks to .readthedocs.yml rather than expand that area too much, though.

[humitos]

Hi! Thanks for your suggestion. Personally, I don't think we will implement this feature because it only solves a very particular case at the cost of adding too much complexity to the base code. However, we have talked about something related (specify a .yaml from the "Advanced settings") in #8811 but we decided to not go in that direction for now.

On the other hand, I personally like the usage of 1.4.x branch names to use them for documentation purposes instead of exact tags like 1.4.0 for different reasons. You already hit one, but also if there is a typo in the documentation you may want to fix it without making a new release. There are many cases like these where you want to update the documentation without making a new release of your code and these are the cases where, in my opinion, 1.4.x branches play nicely.

[apocalyptech]

Aha, thanks for the suggestion about branches! Hadn't occurred to me to do it that way, but that makes a lot of sense. :) Also, yeah, I figured the extra complexity probably wouldn't be worth it.

Thanks for the info and the reply. Cheers!

-CJ