Latest PR requires repository was always configured with sphinx-multiversion
Closed this issue · 3 comments
Earlier this week I was playing around with the source code because I noticed that to build with sphinx-multiversion, I could not simply run sphinx-multiversion . _build/html within the docs sub-directory, it had to be from the repo root.
I was debating about creating a PR for smartly finding gitroot, but it looks like #13 resolved that issue as well.
However, it also introduces an issue which requires the repository to have the sphinx-multiversion extension installed and enabled for all previous git refs, which isn't the case in my scenario.
Would reverting
https://github.com/Holzhaus/sphinx-multiversion/blob/bda14735f9ccb5b6bc416b373999e4991a64a428/sphinx_multiversion/main.py#L192
back to
https://github.com/Holzhaus/sphinx-multiversion/blob/756a60beb34501b2afa2fa742bf81f2c2729d298/sphinx_multiversion/main.py#L188
break the issue brought up in #11?
I'm having a related, but different problem after #13 .
One of the extensions that I use (sphinx-gallery) has changed its type requirements on certain configuration settings; one setting that used to accept bool now fails on that type. This is easy enough to fix with the current conf.py, but for older tags, this breaks the entire doc build because it's trying to use the current extension version with an older config version.
Prior to merging #13 (ie on version 0.2.3), this works fine, because the configuration pulls from the main conf.py (ie confpath not abspath(confdir)) and not the historical version. I expect that this general problem will arise elsewhere in the future, so it would be good to have a generally flexible solution here.
Maybe a user-defined switch to determine whether to use the main conf (old behavior) would be appropriate here?
Maybe a user-defined switch to determine whether to use the main conf (old behavior) would be appropriate here?
No, the old behavious was correct and the new one is a bug. I'll check if I can reproduce it.