Is there any way, like a variable, to check whether Hugo version is extended version or not.
For example, say a variable hugo.Extended with value true if extended version and false if normal version.
I think it will be helpful in making the code run (say with a simple if statement) on any machine without caring whether Hugo’s extended version is installed there or not.
Not exactly what you’re asking, but this might be helpful
It certainly is useful. But, it might be quite handy to have a variable like hugo.Extended to ensure that project runs even on a machine where say asset pipeline is not available. @pointyfar, @bep, @davidsneighbour, thoughts?
I like the idea of having a variable available that hands us (template devs) a way to know what is running locally. This should not be limited to isExtended… Maybe:
This could be done by a local script, but in my experience NOBODY reads the README until something stops working and people got told to RT(F)M 
So, yeah, I am for a hugo setup variable or some kind of standard way to find that out. I don’t know a thing about Golang, but if we can catch errors somehow we can react to them in the templates?
The way I am doing it in my templates by the way would still lead to errors on hugo server if extended is not available. Maybe it might be good to create a way to stop the server from within the template system. Like an exception that can be thrown with a nice error message. I remember that this is not possible due to Golang restrictions.
This is included in the CLI --version command (which calls this function) info, so it should be simple to modify the build-it variable {{ Hugo.Version }} or add a new one.
Looks like the hugo object already has a IsExtended property. So if you want this, save @bep some work and submit a pull request modifying this file with something like this added in:
func (i Info) IsExtended() bool {
return IsExtended
}
Then also update the docs etc
I’m have not read this discussion in detail, but:
Which is meant as a way to tell Hugo what “you need”. It currently prints a warning (I think) if there is a version mismatch and this check does take the extended attr into account.
As a general remark: You can fail the build by using the errorf function.
Sorry for late.
I am not aware with Go syntax, yet by looking at the way things were written, I updated test file too, which is causing the build to fail. @angus could you please take a look.
I have added another commit that undid the commit causing the build to fail. (Commit message went with a typo, sry.)