go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.67k stars 5.46k forks source link

refactor: use a configure interface for settings #16264

Open 6543 opened 3 years ago

6543 commented 3 years ago

I remain unconvinced of the wisdom of moving more things in to setting and in fact intend to make a refactor that will require mostly reverting this.

We should be using a Configure interface e.g.

setting.Configure(setting.Configurable) error

so that the explicit dependency on setting everywhere can eventually be dropped.

Originally posted by @zeripath in https://github.com/go-gitea/gitea/issues/15241#issuecomment-868991406

6543 commented 3 years ago

my thoughts: of now it's convinient to just have to look to one place if you search for settings or like to change gitea behaviour if we going to split setting into it's related modules and move it into that modules, we should considder carefully how to do so and what conventions we follow so we still know without thinking where to look at / put code at

cc @lunny

lunny commented 3 years ago

I think they are different designs. One is to keep all settings on one package(setting), another is to keep configurations on feature packages. Both them have advantages and disadvantages.

We could discuss what's the benefit to convert one to another.

6543 commented 3 years ago

I'm fine with both as long as you can easely find related things in codebase

lunny commented 2 years ago

I think #18058 will fix this partially.