-
Notifications
You must be signed in to change notification settings - Fork 888
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure a smooth transition for existing docsy-as-submodule users #848 #852
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for adding the READMEs and the useful links and explanations that they contain.
This solution seems promising, but I'm concerned that it won't work for projects who want to use modules in a production
environment. Might we have to revert to using multiple config files instead?
Can you elaborate con your concerns a bit, please? What are you exactly concerned about? Why do you think that a multiple config approach might be more promising? |
Some docsy code makes use of hugo.IsProduction (a feature that was added by gohugoio/hugo#6953). As far as I can tell, there can be only a single value for hugo.Environment, so setting it to Unless we can find a way to allow hugo.IsProduction to be true while still using Docsy as a module, we won't be able to use the config directory approach.
I don't know if using multiple config files will work, but it would be worth exploring. WDYT? |
Yes, I see the point.
I like the config directory approach, so I tried to make in work in another way: we now do have two config directories and we can use hugo's Using docsy as git submodule
Using docsy as hugo module
Empty default
@chalin, WDYT? If you like it, I will start testing my new approach. |
That's a very interesting proposal! Let me think about it and get back to you shortly. |
For my detailed feedback, see #848 (comment). |
Ooh, that's a very interesting approach, though does it mean that if you just run |
Yes, in its current form, nothing happens, which will break existing build. Not good, no option at all.
There certainly is a way: we simply copy |
Thanks @deining, it feels like this is the right way to go! |
This PR is superseded by #871. |
This PR solves #848. It implements the following behaviour:
Using docsy as git submodule
Using docsy as hugo module
This PR works as of hugo version 0.84. With this version, hugo learned to make proper use of the
config
directory inside themes. This is the minimum required version when using docsy theme as module. Using docsy as submodule might work with earlier versions, too, which is good since the majority of sites will still run docsy as submodule.