Split code by task to improve maintainability [#2273517]

Right now the only feature is pulling, but when we start adding other tasks, it'll start getting messy real quickly.

I think there should be a basic module called hosting_git for common stuff (basically hooks and git config), and each task should have its own submodule (within this project for the basic ones). For example there would be a submodule called hosting_git_pull. That would allow for cleaner, more easily expandable code, while forcing us to have a good hook architecture (good for other contrib modules wanting to build on this one), and just greater flexibility in general.

I think it would be a good idea to do that refactoring before other features are added and other modules start depending hosting_git. We may not want to force people to have the git pull task.

Thoughts?

Comments

Comment #1

helmo CreditAttribution: helmo commented 26 May 2014 at 09:44

Is your motivation also to limit the number of available tasks for a user? We can do that with the access permissions.

I don't mind splitting in multiple sub modules but don't wanna complicate things either.
I see #2201133: [meta] Consolidate Git modules as a was to reduce the number of contrib projects and maintenance overhead.

Comment #2

gboudrias CreditAttribution: gboudrias commented 6 June 2014 at 18:42

Is your motivation also to limit the number of available tasks for a user? We can do that with the access permissions.

The motivation for the features is just not cluttering the interface with tasks we're not using. But really the main motivation is code separation and the separation into features just follows logically.

As for maintenance, I think having all the modules in one place already greatly reduces the maintenance, compared to pushing/pulling multiple repos and keeping them in sync. It also makes it easier to have consistent code/APIs.

The only way to not have to maintain that code one way or another is to not have the extra features. I think it's worth having at least basic functionality, and imo the only way that it'll remain manageable is by them being organized clearly and consistently.

I've created one feature since there were none. I'll make a branch for the rest for now.

Comment #3

ergonlogic

he/him

English

Montréal, Québec 🇨🇦

CreditAttribution: ergonlogic commented 6 June 2014 at 20:17

I like the idea of being able to enable such commands individually. We should definitely keep them in the same project though. Also, they can all be listed in a common Hosting features file.

Comment #4

gboudrias CreditAttribution: gboudrias commented 6 June 2014 at 22:02

Title:	Create hosting features and split code accordingly	» Split code by task to improve maintainability
Related issues:		+#1404862: Add git clone/checkout support on site install, +#2273495: Push/commit support

I created and pushed 7.x-3.x-code-split

As per ergonlogic's remark, there's still a single feature file, but there is now a hosting_git_pull module, and I put everything pull-related into it.

After the complexity involved in isolating the pull-related stuff, I consider this a pre-requisite to adding other features such as #1404862 and #2273495

Please review and merge the 7.x-3.x-code-split branch.