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

Refactor the globals out of site build #2701

Closed
bep opened this Issue Nov 17, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@bep
Member

bep commented Nov 17, 2016

There currently is a controlled, but careful, dance in the tests to set a set of global state before each test. While this is controlled and has no performance impact for the end result, it it not best practice, it is hard to reason about and it prevents us from using t.Parallel to potentially speed up the test suite.

We have done some considerably work around this area, so when we get some of the big PRs in the pipeline merged, it may be time.

From my head this means:

  • HugoSites should contain:
  • viper
  • template
  • hugofs
  • jww logger
  • translator/i18n bundles handling
  • image config cache

There are plenty of details left out in the above, but it should be complete in general.

@bep bep added the Enhancement label Nov 17, 2016

@bep bep self-assigned this Nov 17, 2016

@bep bep added this to the v0.19 milestone Jan 1, 2017

@bep bep added the InProgress label Jan 3, 2017

bep added a commit that referenced this issue Jan 3, 2017

bep added a commit to bep/hugo that referenced this issue Jan 6, 2017

bep added a commit to bep/hugo that referenced this issue Jan 7, 2017

all: Refactor to non-global logger
Note that this looks like overkill for just the logger, and that is correct,
but this will make sense once we start with the template handling etc.

Updates #2701

bep added a commit that referenced this issue Jan 7, 2017

all: Refactor to non-global logger
Note that this looks like overkill for just the logger, and that is correct,
but this will make sense once we start with the template handling etc.

Updates #2701

bep added a commit to bep/hugo that referenced this issue Jan 9, 2017

bep added a commit that referenced this issue Jan 10, 2017

bep added a commit to bep/hugo that referenced this issue Feb 3, 2017

bep added a commit that referenced this issue Feb 4, 2017

bep added a commit to bep/hugo that referenced this issue Feb 17, 2017

all: Refactor to nonglobal Viper, i18n etc.
This is a final rewrite that removes all the global state in Hugo, which also enables
the use if `t.Parallel` in tests.

Updates #2701
Fixes #3016

bep added a commit to bep/hugo that referenced this issue Feb 17, 2017

tpl: Refactor package
Now:

* The template API lives in /tpl
* The rest lives in /tpl/tplimpl

This is bound te be more improved in the future.

Updates #2701

bep added a commit to bep/hugo that referenced this issue Feb 17, 2017

@bep bep closed this Feb 17, 2017

bep added a commit that referenced this issue Feb 17, 2017

all: Refactor to nonglobal Viper, i18n etc.
This is a final rewrite that removes all the global state in Hugo, which also enables
the use if `t.Parallel` in tests.

Updates #2701
Fixes #3016

bep added a commit that referenced this issue Feb 17, 2017

tpl: Refactor package
Now:

* The template API lives in /tpl
* The rest lives in /tpl/tplimpl

This is bound te be more improved in the future.

Updates #2701

bep added a commit that referenced this issue Feb 17, 2017

@bogem

This comment has been minimized.

Show comment
Hide comment
@bogem

bogem Feb 19, 2017

Contributor

I think, it would be better to rename and Deps(Cfg).Cfg to Deps(Cfg).Provider. The provider means, what it provides the config.
It should be renamed, because cfg.Cfg says nothing.

Contributor

bogem commented Feb 19, 2017

I think, it would be better to rename and Deps(Cfg).Cfg to Deps(Cfg).Provider. The provider means, what it provides the config.
It should be renamed, because cfg.Cfg says nothing.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Feb 19, 2017

Member

You should create a new issues for new issues, a closed issue is ... closed.

However, provider does not tell what it provides -- Cfg at least tell that it contains configuration.

Member

bep commented Feb 19, 2017

You should create a new issues for new issues, a closed issue is ... closed.

However, provider does not tell what it provides -- Cfg at least tell that it contains configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment