Closed tac0turtle closed 1 year ago
🙏 +1
How are we defining the split? Personally I prefer how we have it now.
Here's some thoughts: https://github.com/golang-standards/project-layout/issues/10
The downside is increasing import length and maybe breaking some code. Don't have a strong opinion though
Wont import length stay the same with vanity urls?
Maybe you're right, not 100% sure. We should do a test case.
How are we defining the split? Personally I prefer how we have it now.
Here's some thoughts: golang-standards/project-layout#10
reading the issue, it looks like the conclusion is do what you think is best for your project. There are equally enough pros and cons for both.
The reason I was thinking about this is I'm not a fan of massive root directories and with vanity urls they can be imported under what evert we would like
A golang "standard" was never really created.
I personally adhere to the pkg
and internal
heuristic fairly closely, gives our repos a sense of orderliness and hierarchy.
A massive root directory (in my opinion) prevents the repo from having a "flow". Sounds cheesy, but the repo file structure should read like a logically ordered book.
before making the final call we should make sure Cosmossdk.io/math would still work with a directory path of cosmos-sdk/pkg/math
looking into this, urls would need to change, so its not worth making this breaking change for users
no stress, not that serious
for the record, I think the current layout is better. It's a Go project, so there is no need for root directories like src
or packages
. Moreover every directory, in go standard, is a package.
In light of many things being spun out into their own go.mod or package, I'd like to propose packages like errors math collections are put into a packages directory to not increase the size of the root directory.