Comments (3)
At the moment go-commons is an all-in-one module, this is coming with several caveats.
- Cutting a new release affects all the libraries, this is not desired since a project could want to stick on an specific release of a library.
Yes we can manage the version of the package in a go.mod file. So, the downstream will not see any breaking changes until unless they make changes to their dependency version.
- Creates too many dependencies, a project only using one of the libraries will inherit all go-commons dependencies.
IMHO, go vendoring only inherits the packages that are used as import statements in a project. For example clair-load-test only uses this import statement github.com/cloud-bulldozer/go-commons/indexers
and we only have indexers package downloaded in the vendor files and used in building a binary. No other packages are downloaded.
├── github.com
│ ├── cloud-bulldozer
│ │ └── go-commons
│ │ └── indexers
│ │ ├── elastic.go
│ │ ├── factory.go
│ │ ├── local.go
│ │ ├── opensearch.go
│ │ └── types.go
Splitting the project in different modules comes also with some downsides, the versioning handling of the different modules will be the most problematic one.
Correct me if I am wrong, I don't think this is required. From the answer to the above question, as the downstream only inherits the imported package, changes in other packages should not affect them.
Let's use this issue to discuss about the possibilities
Inline answers for the above questions.
from go-commons.
I believe, a good solution for this problem would be to have unit tests written for this library with > 90% of coverage. That should help us to mitigate most of the issues in development phase itself. Open to other thoughts too. Thank you!
from go-commons.
Regarding multiple modules, getting the configuration for each of them should not be a problem, the biggest issue i see is the versioning of releases, for my part I have not seen a project that does this.
I can think on hacks on how to limit the version for only a module using retract
on the others but it will be a heavy burden to maintain.
Have you seen this done somewhere @rsevilla87? it would be nice to have an idea on how it has been done before.
from go-commons.
Related Issues (8)
- [RFE] Metadata collection
- [CI] for the projects interested in using `go-commons` HOT 1
- Integrate Prometheus library in Go-Commons HOT 1
- README needs documention
- Node-density with mastersSchedulable: true
- Use native prometheus aggregations instead of stats package HOT 6
- [RFE] Threshold comparisons HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-commons.