Skip to content
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

Increase default log level to WARN (but revise the log statements) #5203

Closed
kaushalmodi opened this Issue Sep 11, 2018 · 16 comments

Comments

Projects
None yet
3 participants
@kaushalmodi
Copy link
Member

kaushalmodi commented Sep 11, 2018

While trying to figure out why the warnings were not getting printed in #5201 (comment), I realized that warnings were intentionally being masked from showing up on Stdout.

Once I made this change:

diff --git a/commands/hugo.go b/commands/hugo.go
index 3f1697ea..2f2f7410 100644
--- a/commands/hugo.go
+++ b/commands/hugo.go
@@ -124,7 +124,7 @@ func (c *commandeer) createLogger(cfg config.Provider) (*jww.Notepad, error) {
 		logThreshold    = jww.LevelWarn
 		logFile         = cfg.GetString("logFile")
 		outHandle       = os.Stdout
-		stdoutThreshold = jww.LevelError
+		stdoutThreshold = jww.LevelWarn
 	)
 
 	if c.h.verboseLog || c.h.logging || (c.h.logFile != "") {

I could see all the warnings.

They were helpful to me, because for one of the sites, I wasn't using sections (taxonomy and taxonomyTerms too) at all. Looking at the warnings, I was able to add this to my site config to get rid of those:

disableKinds = ["section", "taxonomy", "taxonomyTerm"]

I still get these 3 warnings even when my site is not set up for multiple languages.. have to figure out how to get rid of these warnings:

WARN 2018/09/11 12:26:26 No translation bundle found for default language "en"
WARN 2018/09/11 12:26:26 Translation func for language en not found, use default.
WARN 2018/09/11 12:26:26 i18n not initialized, check that you have language file (in i18n) that matches the site language or the default language.

But apart from that, I don't see any warning noise.

Should the stdout threshold be bumped?

@onedrawingperday

This comment has been minimized.

Copy link
Member

onedrawingperday commented Sep 11, 2018

Personally, I don't want my console flooded with warnings that can be ignored.

Aren't the -v, --verbose, --verboseLog CLI flags and the verbose configuration setting enough?

@kaushalmodi

This comment has been minimized.

Copy link
Member Author

kaushalmodi commented Sep 11, 2018

Here is how I categorize the verbosity and have seen the same meaning in many languages (SystemVerilog, Emacs Lisp).

  • info: Nice to have info for user
  • warn: A message that user should take seriously; but not seriously enough to drop everything they have and tend to it.
  • error: A message that user should take seriously and do something to fix that now.

--verbose sets the level to info. With that I see:

WARN 2018/09/11 13:04:16 No translation bundle found for default language "en"
WARN 2018/09/11 13:04:16 Translation func for language en not found, use default.
WARN 2018/09/11 13:04:16 i18n not initialized, check that you have language file (in i18n) that matches the site language or the default language.
INFO 2018/09/11 13:04:16 Using config file: /home/kmodi/hugo/scripter.co/config.toml
Building sites … INFO 2018/09/11 13:04:16 removing all files from destination that don't exist in static dirs
INFO 2018/09/11 13:04:16 syncing static files to /
INFO 2018/09/11 13:04:17 found taxonomies: map[string]string{"category":"categories", "tag":"tags", "series":"series"}
INFO 2018/09/11 13:04:17 Alias "/replies/fragmentions" translated to "replies/fragmentions/index.html"
INFO 2018/09/11 13:04:17 Alias "/converting-org-keywords-to-lower-case/" translated to "converting-org-keywords-to-lower-case/index.html"
INFO 2018/09/11 13:04:17 Alias "/notes/string-functions-nim-vs-python" translated to "notes/string-functions-nim-vs-python/index.html"
INFO 2018/09/11 13:04:17 Alias "/ctags-verilog-and-emacs" translated to "ctags-verilog-and-emacs/index.html"
INFO 2018/09/11 13:04:17 Alias "/page/1/index.html" translated to "page/1/index.html"

Without --verbose, I see neither warnings nor infos.

So with the --verbose, it's very easy to miss out on the important warnings in the sea of infos.

My proposal is to always show the warnings so that the user fixes them at some point.

As I said, I see just 3 warnings related to i18n. So either I need to set something on my config, or Hugo needs to be fixed so that those warnings are not shown for English-only sites.

With that fixed, ideally 0 warnings are shown.

@onedrawingperday

This comment has been minimized.

Copy link
Member

onedrawingperday commented Sep 11, 2018

3 warnings related to i18n

I also get these when I use -v but since I am not using multiligual either (suprise), I ignore them.

But I certainly don't want to see warnings every time I spin a hugo server I already have more than enough to go through in the console, when pushing Hugo's functionality to the limit through trial and error.

@kaushalmodi

This comment has been minimized.

Copy link
Member Author

kaushalmodi commented Sep 11, 2018

But I certainly don't want to warnings every time I spin a hugo server

But if the root cause of the warnings is fixed, you wouldn't get any warnings.

My point is that currently, warnings have the same stature/severity as infos.. they aren't anything special. They are as ignorable as infos.. Should that be the case?

@kaushalmodi

This comment has been minimized.

Copy link
Member Author

kaushalmodi commented Sep 11, 2018

Seeing and acting upon warnings also makes your hugo build more efficient.

For example, in one site, I was seeing warnings related to section, taxonomy, taxonomyTerm templates not found. The reason was that that site didn't need to publish those pages.

But putting disableKinds = ["section", "taxonomy", "taxonomyTerm"] in my config, those warnings went away, and my site build became a bit more efficient. I wouldn't have learned about this easily if I had still kept the warnings masked.

@onedrawingperday

This comment has been minimized.

Copy link
Member

onedrawingperday commented Sep 11, 2018

Thanks for the advice. I certainly use disableKinds in every Hugo project I maintain.

But this issue you raised besides of what is proper in other programming languages is also about making Hugo day-to-day operations easier, (during and especially after the main development of a project).

I am really not in favor of increasing stdoutThreshold.

Maybe the verbose report should be just for info and then have another for warnings but that is not my place to say.

@kaushalmodi

This comment has been minimized.

Copy link
Member Author

kaushalmodi commented Sep 11, 2018

The warnings help discover a lot of masked bugs introduced by the user or hugo itself.

I just noticed this in one site:

WARN 2018/09/11 13:36:09 [en] Unable to locate layout for "404": [404.html theme/404.html]

Apparently, Hugo always looks for it, and warns if the user hasn't supplied that either. So to fix it, I either disable 404 Kind too (yes, it's another Kind), or add a 404.html template.

I see only plusses in enabling warnings. If certain "warnings" are not important enough to tell the user about, they should be downgraded to INFO.

@bep

This comment has been minimized.

Copy link
Member

bep commented Sep 11, 2018

We should consider:

  1. Look through all WARNING's and make the info statements into INFO. The "Unable to locate layout" would probably fall into that category.
  2. Make WARNING the default stdout threshold.
@kaushalmodi

This comment has been minimized.

Copy link
Member Author

kaushalmodi commented Sep 11, 2018

I have noticed these 3 categories of warnings so far:

  1. "Unable to locate layout" -- These, I was able to fix easily.
  2. i18n -- I cannot fix these; should they be made INFO, or Hugo should fix this by not trying to use i18n if only one language "en" or "en-US" is detected?
  3. Gitinfo -- I see these for posts that are drafts and never been committed to git.
WARN 2018/09/11 14:04:34 Failed to find GitInfo for page "posts/coderef.md"
WARN 2018/09/11 14:04:34 Failed to find GitInfo for page "posts/parsing-notes-from-logbook.md"

Update 1

I see these warns on hugoDocs site:

WARN 2018/09/11 13:35:58 No translation bundle found for default language "en"
WARN 2018/09/11 13:35:58 Translation func for language en not found, use default.
WARN 2018/09/11 13:35:58 i18n not initialized, check that you have language file (in i18n) that matches the site language or the default language.
WARN 2018/09/11 13:35:59 Translation func for language zh not found, use default.
WARN 2018/09/11 13:35:59 i18n not initialized, check that you have language file (in i18n) that matches the site language or the default language.

Update 2

As it turns out, the "layout not found" warning helped me fix another bug with the section Kind pages.. here. Earlier https://ox-hugo.scripter.co/doc/ gave a 404 (which I never checked). Now https://ox-hugo.scripter.co/doc/ redirects to https://ox-hugo.scripter.co/ (on server and when deployed) as I wanted.

@bep Do you see a use case where "Unable to locate layout" warnings are unfixable and should be ignored? Why not fix them if fixing those makes the site be more predictable?

@onedrawingperday

This comment has been minimized.

Copy link
Member

onedrawingperday commented Sep 11, 2018

I see these warns on hugoDocs site

Because there is also a Chinese language version that is unfinished.

  1. Look through all WARNING's and make the info statements into INFO. The "Unable to locate layout" would probably fall into that category.
  2. Make WARNING the default stdout threshold.
    Ok.

How about downgrading the i18n warning to info also? It's pretty useless for monolingual sites. I suppose that for multilingual setups this will be an error.

@kaushalmodi

This comment has been minimized.

Copy link
Member Author

kaushalmodi commented Sep 11, 2018

How about downgrading the i18n warning to info also?

I think that Hugo can detect monolingual sites internally. In such cases, it should not enter the i18n logic at all. Downgrading that WARN to INFO would be masking that warning.

A warning must always be fixed.

@bep

This comment has been minimized.

Copy link
Member

bep commented Sep 11, 2018

I don't think we can "debate a solution here". That will take too long time.

@kaushalmodi

This comment has been minimized.

Copy link
Member Author

kaushalmodi commented Sep 11, 2018

I don't think we can "debate a solution here". That will take too long time.

What's your take on the i18n stuff? Is it possible to auto-detect mono-lingual sites and skip the i18n logic?

@bep

This comment has been minimized.

Copy link
Member

bep commented Sep 11, 2018

I will comment two of the items above. Then I will assign this to myself and eventually fix it:

  1. The i18n warnings are not connected to "having more than one language". We have no way of knowing if the user wants/needs a /i18n bundle when we print the WARNING => INFO
  2. Many don't want/need 404, most themes don't have a template for it, so it would be counter productive to WARN about it => INFO
@kaushalmodi

This comment has been minimized.

Copy link
Member Author

kaushalmodi commented Sep 11, 2018

@bep I just added "Update 2" above. The "layout not found" warn actually helped me fix a bug.

@bep bep added this to the v0.51 milestone Nov 1, 2018

@bep bep self-assigned this Nov 1, 2018

@bep bep changed the title Should stdoutThreshold be increased to LevelWarn? Increase default log level to WARN (but revise the log statements) Nov 1, 2018

@bep bep added the Enhancement label Nov 1, 2018

bep added a commit to bep/hugo that referenced this issue Nov 1, 2018

Make WARN the new default log log level
This commit also pulls down the log level for a set of WARN statements to INFO. There should be no ERRORs or WARNINGs in a regular Hugo build. That is the story about the Boy Who Cried Wolf.

Fixes gohugoio#5203

bep added a commit to bep/hugo that referenced this issue Nov 1, 2018

Make WARN the new default log log level
This commit also pulls down the log level for a set of WARN statements to INFO. There should be no ERRORs or WARNINGs in a regular Hugo build. That is the story about the Boy Who Cried Wolf.

Fixes gohugoio#5203

bep added a commit to bep/hugo that referenced this issue Nov 1, 2018

Make WARN the new default log log level
This commit also pulls down the log level for a set of WARN statements to INFO. There should be no ERRORs or WARNINGs in a regular Hugo build. That is the story about the Boy Who Cried Wolf.

Fixes gohugoio#5203

bep added a commit to bep/hugo that referenced this issue Nov 2, 2018

Make WARN the new default log log level
This commit also pulls down the log level for a set of WARN statements to INFO. There should be no ERRORs or WARNINGs in a regular Hugo build. That is the story about the Boy Who Cried Wolf.

Since the WARN log is now more visible, this commit also improves on some of them, most notable the "layout not found", which now would look something like this:

```bash
WARN 2018/11/02 09:02:18 Found no layout for "home", language "en", output format "CSS": create a template below /layouts with one of these filenames: index.en.css.css, home.en.css.css, list.en.css.css, index.css.css, home.css.css, list.css.css, index.en.css, home.en.css, list.en.css, index.css, home.css, list.css, _default/index.en.css.css, _default/home.en.css.css, _default/list.en.css.css, _default/index.css.css, _default/home.css.css, _default/list.css.css, _default/index.en.css, _default/home.en.css, _default/list.en.css, _default/index.css, _default/home.css, _default/list.css
```

Fixes gohugoio#5203

bep added a commit to bep/hugo that referenced this issue Nov 2, 2018

Make WARN the new default log log level
This commit also pulls down the log level for a set of WARN statements to INFO. There should be no ERRORs or WARNINGs in a regular Hugo build. That is the story about the Boy Who Cried Wolf.

Since the WARN log is now more visible, this commit also improves on some of them, most notable the "layout not found", which now would look something like this:

```bash
WARN 2018/11/02 09:02:18 Found no layout for "home", language "en", output format "CSS": create a template below /layouts with one of these filenames: index.en.css.css, home.en.css.css, list.en.css.css, index.css.css, home.css.css, list.css.css, index.en.css, home.en.css, list.en.css, index.css, home.css, list.css, _default/index.en.css.css, _default/home.en.css.css, _default/list.en.css.css, _default/index.css.css, _default/home.css.css, _default/list.css.css, _default/index.en.css, _default/home.en.css, _default/list.en.css, _default/index.css, _default/home.css, _default/list.css
```

Fixes gohugoio#5203

bep added a commit to bep/hugo that referenced this issue Nov 3, 2018

Make WARN the new default log log level
This commit also pulls down the log level for a set of WARN statements to INFO. There should be no ERRORs or WARNINGs in a regular Hugo build. That is the story about the Boy Who Cried Wolf.

Since the WARN log is now more visible, this commit also improves on some of them, most notable the "layout not found", which now would look something like this:

```bash
WARN 2018/11/02 09:02:18 Found no layout for "home", language "en", output format "CSS": create a template below /layouts with one of these filenames: index.en.css.css, home.en.css.css, list.en.css.css, index.css.css, home.css.css, list.css.css, index.en.css, home.en.css, list.en.css, index.css, home.css, list.css, _default/index.en.css.css, _default/home.en.css.css, _default/list.en.css.css, _default/index.css.css, _default/home.css.css, _default/list.css.css, _default/index.en.css, _default/home.en.css, _default/list.en.css, _default/index.css, _default/home.css, _default/list.css
```

Fixes gohugoio#5203

@bep bep closed this in #5389 Nov 3, 2018

bep added a commit that referenced this issue Nov 3, 2018

Make WARN the new default log log level
This commit also pulls down the log level for a set of WARN statements to INFO. There should be no ERRORs or WARNINGs in a regular Hugo build. That is the story about the Boy Who Cried Wolf.

Since the WARN log is now more visible, this commit also improves on some of them, most notable the "layout not found", which now would look something like this:

```bash
WARN 2018/11/02 09:02:18 Found no layout for "home", language "en", output format "CSS": create a template below /layouts with one of these filenames: index.en.css.css, home.en.css.css, list.en.css.css, index.css.css, home.css.css, list.css.css, index.en.css, home.en.css, list.en.css, index.css, home.css, list.css, _default/index.en.css.css, _default/home.en.css.css, _default/list.en.css.css, _default/index.css.css, _default/home.css.css, _default/list.css.css, _default/index.en.css, _default/home.en.css, _default/list.en.css, _default/index.css, _default/home.css, _default/list.css
```

Fixes #5203
@kaushalmodi

This comment has been minimized.

Copy link
Member Author

kaushalmodi commented Nov 3, 2018

I confirm this fix. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.