refactor: use a configure interface for settings #7511

New Issue

GiteaMirror · 2025-11-02T07:28:07-06:00

GiteaMirror commented

2025-11-02 07:28:07 -06:00

Originally created by @6543 on GitHub (Jun 26, 2021).

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

Originally created by @6543 on GitHub (Jun 26, 2021). 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. ```go 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_

GiteaMirror added the type/proposal type/refactoring labels 2025-11-02 07:28:07 -06:00

GiteaMirror commented

2025-11-02 07:28:08 -06:00

@6543 commented on GitHub (Jun 26, 2021):

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

@6543 commented on GitHub (Jun 26, 2021): 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

GiteaMirror commented

2025-11-02 07:28:08 -06:00

@lunny commented on GitHub (Jun 27, 2021):

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.

@lunny commented on GitHub (Jun 27, 2021): 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.

GiteaMirror commented

2025-11-02 07:28:09 -06:00

@6543 commented on GitHub (Jun 27, 2021):

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

@6543 commented on GitHub (Jun 27, 2021): I'm fine with both as long as you can easely find related things in codebase

GiteaMirror commented

2025-11-02 07:28:09 -06:00

@lunny commented on GitHub (May 16, 2022):

I think #18058 will fix this partially.

@lunny commented on GitHub (May 16, 2022): I think #18058 will fix this partially.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7511