Comments (6)
I've talked about this notion at length elsewhere but I think the Go community has their dependency management story wrong. A lot of this is because the core team works in a mono-repo environment, and lots of the community is coming from development communities where breaking simple monolithic applications down into a hundred tiny sublibraries (none of which are useful on their own) is considered best practice and where the dependency story is even worse.
Also, I'm not sure I agree that Godep is the de-facto complete solution at this point either. The Golang development team has introduced the "vendor experiment" and it's almost certainly going to be the case that this is adopted as the standard. Godeps doesn't currently match up with this very well.
What's the value proposition for making this change?
from containerpilot.
Mostly this came out of my inability to get my tooling to detect the libraries required for using autocompletion. Conforming to go's conventions seem to alleviate this for most tooling.
I agree golang's dependency story is pretty bad, but it does seem that godep is used most often (a close second to using nothing). Vendor experiment is that - an experiment; however, godep supports this if you set an environment variable.
One use case is that I can run godep restore
from the repository and my GOPATH will get all of the required libraries at their versions defined in Godeps.json - which allows my tooling (right now Atom Editor + go-plus) to find all the necessary libraries - in other words; no need to manually git clone <repo> && git checkout <ref>
each dependency.
However; I concede that this proposal doesn't add much intrinsic value to the project or its users:
- It's a binary, not a library - so no one should be importing it into their own projects (yet?)
- It only really helps my workflow, but most likely doesn't help everyone (unless you're using atom + go-plus)
from containerpilot.
As much as I'm skeptical of the official golang approach, realistically I'm can't oppose the idea of trying to bring things in-line with the community if it reduces friction for contributing. But it does look like Go 1.6 has accepted the vendor experiment:
Go 1.6 keeps the vendoring support, no longer considered experimental, and enables it by default.
So we should probably rework #77 to support that model.
from containerpilot.
I'm can't oppose the idea of trying to bring things in-line with the community if it reduces friction for contributing.
@tgross, Do you agree with the proposed directory structure change? Namely putting a main.go
shim at the top in the main
package, and then putting all of the real code in the containerbuddy
package
So we should probably rework #77 to support that model.
I'll look into getting this supported in place of the Godeps/_workspace
model
from containerpilot.
Do you agree with the proposed directory structure change?
Yeah, that's fine.
from containerpilot.
Released in https://github.com/joyent/containerbuddy/releases/tag/0.1.3, which I'm hoping to be our final RC.
from containerpilot.
Related Issues (20)
- Stability issues with signal events under SmartOS/LX HOT 2
- [Question]How to disable default metrics and only response custom defined metrics? HOT 5
- Building inside a docker container HOT 2
- SmartOS and LX brand issues with Go 1.9
- Docs incorrectly say 'initialStatus', should be 'initial_status' HOT 2
- Telemetry custom metrics always zero HOT 4
- Run as user per job HOT 5
- Allow for an ADHoc Sending of a signal to a ContainerPilot job. HOT 1
- Project status HOT 3
- Error parsing environment variable in config template
- Unable to execute job HOT 1
- CP ends up ignoring that it's jobs have been killed
- Local build on SmartOS fails due to upstream changes
- 100% CPU Usage
- github url's in documentation
- Documentation Update: docker-compose --scale "change"
- consul with TLS does not read env vars set by -putenv
- Broken link to blog/wordpress-on-autopilot
- Container Pilot process get hung and cannot recover when health check timeouts continues for more than an hour
- Support consul service meta data HOT 5
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 containerpilot.