From what I can see that means nested modules end up with the ‘parent’ module having the repo name in it’s config.toml, which means that any theme, or other module, that depends on the ‘parent’ module will use the full repo name for the nested module.
That breaks my use case. Also I’m not sure using a different
path in config.toml than
init is quite right when I look at the Go module documention (for which Hugo modules is a thin wrapper). It probably manages to work, but I’m not sure it’s within spec. (But that’s less of a concern than the nested module situation; vendoring helps with that, but there are often reasons to no vendor, or for a user of a nested module system to not want to use the vendoring, so the full hierarchy of
hugo mod get needs (in my opinion) to be work as expected).
I had a moment of hope when I read your reply, but from my experimentation this isn’t going to be a solution that fits what I’m looking for (assuming there is one).
I guess I could probably have a script to allow using replacements (maybe involving replacements environment variables) that I could allow users to default to my primary mirror (it is supposed to primary after all), but allow users to override to Github. I want to be cross-platform so I guess that means either supplying both a ‘.sh’ and a ‘.cmd’.
The other question is how much of a hinderance is using custom hosting to folks who want to use the modules. If no one cares (and I have the scripts, which are also on github, if the hosting is down) then maybe I’m just makeing extra work for myself.
In the end though,if it’s not possible to easily support Github as an alternate module source (rather than just source code mirror), I’m going to choose my own hosting as my preference, for various reasons that are OT.