[PROPOSAL]: About The Project Layout

[uptutu]

What Is Your Expect

I want to change the layout like this:

tkeel
├── charts
│   ├── auth
│   │   └── templates
│   ├── core
│   │   ├── charts
│   │   └── templates
│   ├── keel
│   │   └── templates
│   ├── plugins
│   │   └── templates
│   ├── tkeel-middleware
│   │   ├── charts
│   │   └── templates
│   └── tkeel-plugin-component
│       └── templates
├── cmd
│   ├── auth
│   ├── keel
│   └── plugin
├── config
│   ├── common
│   │   └── component
│   ├── keel
│   │   └── components
│   └── plugin
│       └── components
├── demo
│   └── deploy
│       ├── chart
│       │   └── demo-echo
│       │       ├── charts
│       │       │   └── tkeel-plugin-component
│       │       │       └── templates
│       │       └── templates
│       └── k8s
│           └── crd
├── docker
│   ├── auth
│   ├── keel
│   └── plugins
├── docs
│   ├── api
│   │   └── auth
│   ├── decision_records
│   │   ├── cli
│   │   ├── engineering
│   │   ├── openapi
│   │   ├── plugin-auth
│   │   ├── plugin-keel
│   │   └── plugin-plugins
│   ├── development
│   ├── images
│   │   └── img
│   │       └── auth
│   └── release_notes
├── envutil
├── k8s
│   ├── auth
│   ├── keel
│   └── plugins
├── keel
│   ├── env
│   └── testdata
├── logger
├── openapi
├── readutil
├── service
│   ├── auth
│   │   ├── api
│   │   │   └── params
│   │   ├── client
│   │   └── model
│   ├── keel
│   └── plugin
├── token
└── version

The benefits of this change to our project are :

- import tkeel/plugin 
- plugin.Plugin{}
+ import tkeel
+ tkeel.Plugin{}
// Other Example
- import tkeel/pkg/plugin/plugins
+ import tkeel/service/plugin

Clearer semantics

About the pkg

Removed pkg and changed some package names to make them more readable.
this is not a standard Go project layout In this issue Cox gives some suggestions, in the spirit of organising the code better and keeping close to the Zen of Go.

Some about pkg issue : golang-standards/project-layout#10
People discuss the good and bad of using pkg.

We are now able to make this change at no great cost.

Original project structure

tkeel
├── charts
│   ├── auth
│   │   └── templates
│   ├── core
│   │   ├── charts
│   │   └── templates
│   ├── keel
│   │   └── templates
│   ├── plugins
│   │   └── templates
│   ├── tkeel-middleware
│   │   ├── charts
│   │   └── templates
│   └── tkeel-plugin-component
│       └── templates
├── cmd
│   ├── auth
│   ├── keel
│   └── plugins
├── config
│   ├── common
│   │   └── component
│   ├── keel
│   │   └── components
│   └── plugins
│       └── components
├── demo
│   └── deploy
│       ├── chart
│       │   └── demo-echo
│       │       ├── charts
│       │       │   └── tkeel-plugin-component
│       │       │       └── templates
│       │       └── templates
│       └── k8s
│           └── crd
├── docker
│   ├── auth
│   ├── keel
│   └── plugins
├── docs
│   ├── api
│   │   └── auth
│   ├── decision_records
│   │   ├── cli
│   │   ├── engineering
│   │   ├── openapi
│   │   ├── plugin-auth
│   │   ├── plugin-keel
│   │   └── plugin-plugins
│   ├── development
│   ├── images
│   │   └── img
│   │       └── auth
│   └── release_notes
├── k8s
│   ├── auth
│   ├── keel
│   └── plugins
├── keel
│   └── testdata
├── pkg
│   ├── config
│   │   ├── env
│   │   └── testdata
│   ├── keel
│   ├── logger
│   ├── openapi
│   ├── plugin
│   │   ├── auth
│   │   │   ├── api
│   │   │   │   └── params
│   │   │   ├── client
│   │   │   └── model
│   │   ├── keel
│   │   └── plugins
│   ├── token
│   ├── utils
│   └── version
└── tests

About Some Ambiguities

plugin/plugins in this project, plugins is more like a managed service. So I changed it to service/plugin. There are two keel in the project that also contain controversies, so I suggested that the name of one keel be made more concrete, like I named it sidecar.

Code of Conduct

• I agree to follow this project's Code of Conduct

Contact Details

No response

[imneov]

Our project is contains deployment configuration directories such as charts k8s. If we removing pkg , will the root directory be messy?

[uptutu]

Our project is contains deployment configuration directories such as charts k8s. If we removing pkg , will the root directory be messy?

I don't think it would be messed up.

If needed, rename it to _docker.
Or consider putting a folder like docker into config, or splitting it up into each of the corresponding services in service/xxx, which might be better.

[OdysseusC]

I don't think we can remove pkg/.

I agree with this comment.

If you remove pkg/, it will make it difficult for you to know from the name of the folder whether this is a go package or a collection of non-Go-source files.

Same as cmd/, when you have multiple binaries being built. It gives you a good starting point to understand how the library is imported / consumed. So pkg/ is the starting point for providing Go files.

[uptutu]

Our conclusion is that there is no need to remove the /pkg directory.
Becoz. The form of this project differs from the usual exportable go tool class libraries. The files in the project serve the project itself, only to construct executable services.

[jia-zhengwei]

According to Standard Go Project Layout, maybe pkg is not very bad.

Such as

• moby
• kubernetes