In Go, if you reference another package, e.g. something on GitHub, then Go always gets the latest version from the master branch. While this is great for development, I guess it's a problem in production: This way a build is not reproducible.
So, what is the correct way in Go to fix a version of a dependency, and how to handle this efficiently?
A friend pointed me to godep, and this seems fine, but I wanted to know what alternatives are there, and what's good / bad about godep?
Update 2018 with Go 1.11
Dependencies should now be referenced with modules (derived from the vgo project):
Go 1.11 adds preliminary support for a new concept called “modules,” an alternative to GOPATH with integrated support for versioning and package distribution.
Using modules, developers are no longer confined to working inside GOPATH, version dependency information is explicit yet lightweight, and builds are more reliable and reproducible.
See Defining a module. (and the original design proposal)
Update June 2015: first support for vendoring is making its way in Go 1.5!
See c/10923/:
When GO15VENDOREXPERIMENT=1 is in the environment, this CL changes the resolution of import paths according to the Go 1.5 vendor proposal:
If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.
When there are multiple possible resolutions, the most specific (longest) path wins.
The short form must always be used: no import path can contain “/vendor/” explicitly.
Import comments are ignored in vendored packages.
Update March 2015: the go team is thinking about defining a go dependency management system integrated to the language: the debate is in this thread.
We think it’s time to start addressing the dependency & vendoring issue, especially before too many conflicting tools arise and fragment best practices in the Go ecosystem, unnecessarily complicating tooling. It would be nice if the community could converge on a standard way to vendor.
Our proposal is that the Go project,
officially recommends vendoring into an “internal” directory with import rewriting (not GOPATH modifications) as the canonical way to pin dependencies.
defines a common config file format for dependencies & vendoring
makes no code changes to cmd/go in Go 1.5. External tools such as “godep” or “nut” will implement 1) and 2). We can reevaluate including such a tool in Go 1.6+.
One possible downside of godep is that you can no longer use "go build" or "go test" directly.
You need to precede those commands with godep (or type godep save).
An alternative is glide, which remains compatible with classic go commands.
Manage project-specific GOPATHs
Ease dependency management
Support versioning packages
Support aliasing packages (e.g. for working with github forks)
Remove the need for "vendoring" or munging import statements
Work with all of the go tools
More generally, the article "Know your guarantees, Go edition" is interesting:
It’s also a deliberate choice, where the Go authors chose not to implement a feature when they felt that the trade-offs were no good.
One low-level reason they made this choice is to avoid slow compilation and bloated binaries (which are two sides of the same coin).
Remember, packages depend on other packages. So Foo might depend on Bar 2.1. Foo might also depend on Baz which in turn depends on Bar 1.9, and on down the tree. So that would mean compiling and linking several copies of nearly identical code.
Depending on several versions of the same package also means knowing which version one is calling, whereby the dependency mess seeps into your source code.
Which leads us to the high-level reasoning behind the Go platform punting on this feature: they did not have a logical solution they considered acceptable. It’s not that they don’t understand the problem; it’s that, at the moment, there is not a solution they like. So they choose no feature over over a regressive one.
You handle dependencies like you do handle dependencies in other languages too: You vendor. For Go there is no Nexus which does the vendoring so most just copy external libraries into a "vendor" folder, there are tools helping here. Personally I found all this "fix version" panic a bit exaggerated as it works pretty well without.
You might wanna take a look at http://labix.org/gopkg.in and search golang-nuts for dependency management. I think there is even a whole mailing list devoted to this.
Related
Consider two software projects, proj_a and proj_b, with the latter depending on the former; and with both using CMake.
When reading about modern CMake, one gets the message that the "appropriate" way to express dependencies is via target dependencies; and one should arrange it so that dependent projects are represented as (imported) targets you can depend on. More specifically, in our example, proj_b will idiomatically have:
find_package(proj_a)
# etc etc.
target_link_library(bar proj_a::foo)
and proj_a will need to have been installed, utilizing the CMake installation-and-export-related commands, someplace where proj_b's CMake invocation will search for proj_a-config.cmake.
I like this approach and encourage others to adapt to it. It offers flexibility in the choice of your own version of proj_a vs the system version; and also allows for non-CMake proj_a's via a Findproj_a.cmake script (which again, can be system-level or part of proj_b).
So far so good, right? However, there are people who want to "take matters into their own hands" in terms of dependencies - and CMake officially condones this, with commands such as ExternalProject and more recently, FetchContent: This allows proj_b's configuration stage to actually download a (built, or in our case source-form) version of proj_a.
The puzzling part to me is that, after proj_a is downloaded, say to an external/proj_a directory, CMake's default behavior will be to
add_subdirectory(external/proj_a)
that is, to use proj_a as a subproject of proj_b and build them together. This, while the idiomatic use above allows the maintainer of proj_a to "do their own thing" in my CMakeFile, and only keep things neat and tidy for others via what I export/install.
My questions:
Why does it make sense to add_subdirectory(), rather than to build, install, and perform the equivalent of find_package() to meet the dependency? Or rather, why should the former, rather than the latter, be the default?
Should I really have to write my project-level CMakeLists.txt to be compatible with being add_subdirectory()'ed?
Note: Just to give some concrete examples of how this use constrains proj_a:
Must use unique option names which can't possibly clash with super-project names. So no more WITH_TESTS, BUILD_STATIC_LIB - it has to be: WITH_PROJ_A_TESTS and BUILD_PROJ_A_STATIC_LIB.
You have to account for the parent project having searched for other dependencies already, and perhaps differently than how you would like to search for them.
Following the discussion in comments, I decided to post a bug report about this:
#22904: Support FetchContent_MakeAvailable performing build+install+find_package rather than add_subdirectory
So maybe this will change and the question becomes moot.
Why does it make sense to add_subdirectory(), rather than to build, install, and perform the equivalent of find_package() to meet the dependency? Or rather, why should the former, rather than the latter, be the default?
FetchContent doesn't just have to be for project() dependencies. It can be used for fetching utility scripts too. I'm guessing it was designed with that kind of consideration in mind. If your utility script is just one file, you can just file(DOWNLOAD) and add_subdirectory() directly, but the utilities could be multiple files, such as is the case with aminaya/project_options. FetchContent() uses a lot of the same machinery as ExternalProject, so it can do a lot of the useful things that ExternalProject does. For example, you can use FetchContent to fetch aminaya/project_options as a remote git repo, or as its archive artifacts- ex. v0.20.0.zip
Should I really have to write my project-level CMakeLists.txt to be compatible with being add_subdirectory()'ed?
It's your choice! The reasoning here can be highly objective, or subjective. It's up to you. Some people just like to put in a lot of effort to support whatever their users might want. Some people have a lot of historical configuration baggage and are still catching up to newer CMake. And as you mentioned at the end of your question post, there are certain adjustments that need to be made to accomodate for cleanly allowing people to add_subdirectory() you as a dependency. One example of a project which chose "no" is glew (see issue #314 for explanation).
Just to give another reference to some related work mentioned in responses to the KitWare/CMake ticket your raised, here's the ticket which tracked work on "FetchContent and find_package() integration".
I have a deep dependency tree. Some of the packages depend on nodejs packages that I don't need. Is it possible for Yarn 2 (berry) to skip those packages, i.e. not install them?
Yarn has a Constraints feature, but I don't know what's possible with it. There are examples, but not for ignoring a package completely.
Is this possible? Thanks
Constraints allow you to enforce rules on the dependency your project (and workspaces) have. It's a tool for writing rules that are applied to what goes in your various package.json files, like "every workspace must have the same version of react" or "no workspace may depend on package X".
If you have a dependency that is depending on something that you believe is really an optional dependency, you can use .yarnrc to change that dependency into an optional one. Use yarn why <foo> find the package that is causing the unwanted deep dependency, and then add something like this to .yarnrc (specific example yoinked from here):
# Make `eslint-plugin-flowtype`'s peerDependency on `#babel/plugin-syntax-flow` optional.
# Use `dependenciesMeta` for non-peer deps, of course ;).
packageExtensions:
'eslint-plugin-flowtype#*':
peerDependenciesMeta:
'#babel/plugin-syntax-flow':
optional: true
Note that doing this is in general quite risky: you should probably be filing a bug upstream if you think a package is depending on something that should really be an optional dependency.
Lastly, note that it's very possible this whole thing is a non-problem: webpack (or whatever bundler is in fashion a week after I write this) is probably deleting the unwanted files at compile-time anyway? If you find the mere presence of the node packages you don't like is causing issues (eg. via typescript typings?) then that's a different problem that should be solved differently.
I'm working on a library with multiple layers of functionality. I want developers to be able to import only the parts they need, ie mylib-core, mylib-feature1, mylib-feature2, etc. Each lives in its own git repo. I'd also like to provide a simple mylib package which exposes a default set of functionality which is useful for developers new to the library. See d3.js version 4+ for something very similar to what I'm trying to accomplish.
The problems I've run into are
Apparently you can't share a package name between packages. This is a problem because it would be nice to import all the desired repos and then simply have everything available under the mylib name.
I don't see an obvious way to re-export functionality, in order to build the default mylib package.
Are there good solutions or a more idomatic go way to accomplish what I'm shooting for?
Answering your question, there is no idiomatic way of doing what you want. It is common in JavaScript to import a library and export its members without interference. This is not the case in Golang.
I advise you to host your whole library under a single repo, and split the functionality to packages. The Go compiler will only compile and use the imported packages.
And a tip for the future, Go is very different than almost any other language you previously know 😅
I want to make some changes to the Go crypto/tls standard library.
Is making a copy of crypto/tls in the vendor folder a good way to do this?
It almost works, it seems the vendored is copy used when I compile the application (Caddy webserver). Apart from one error I get:
go/src/github.com/user/caddy/caddytls/httphandler.go:40: cannot use "vendor/crypto/tls".Config literal (type *"vendor/crypto/tls".Config) as type *"crypto/tls".Config in field value
Is there a way of casting to get around this one error? Doesn't sound like good practice to me though.
I would have thought that the vendored copy would always be used, but it seems something is still using the standard crypto/tls library? (I think "net/http" is. Do I have to vendor this too?)
I actually had to do that. The most practical way is to copy and modify the package (as well as its internal dependencies) - this includes some import paths. And it is not really vendored (vendoring is basically using unmodified packages, otherwise vendoring tools will not work), it is a fork, under a different name. I would guess that caddy does not need the modified version - if it does, you need to fork and modify caddy as well.
It goes without saying, but be extremely careful when modifying crypto/tls package - I for example has to make a minimal change that does not really modify TLS operation (I needed to be able to derive key material from the session master secret and randoms).
Also, you have to fully realize that this has significant cost - when a new version of go is out, one that potentially has updates for the crypto/tls package or its dependencies, you will have to apply your changes once again, manually. Committing a diff between the vanilla version and your version helps. I don't think this is at all practical for non-trivial changes (mine were quite limited - a new public field in Config, few lines of code in handshakes, a new interface).
I need the same functionality. It seems like the crypto/tls package does not allow the reading of custom TLS extensions added from the client side in the ClientHello payload. It would be great to be able to check for any custom extensions and then marshal them out accordingly.
It is a pity that this is not a separate package as we could then in our go.mod file be able to use replace to specify a custom TLS package.
e.g
replace golang.org/x/crypto/tls => ./tls
Then running go mod vendor.
Where the ./tls is my local version with the changes applied.
I've been looking for ways to learn about the right way to manage a software project, and I've stumbled upon the following blog post. I've learned some of the things mentioned the hard way, others make sense, and yet others are still unclear to me.
To sum up, the author lists a bunch of features of a project and how much those features contribute to a project's 'suckiness' for a lack of a better term. You can find the full article here: http://spot.livejournal.com/308370.html
In particular, I don't understand the author's stance on bundling dependencies with your project. These are:
== Bundling ==
Your source only comes with other code projects that it depends on [ +20 points of FAIL ]
Why is this a problem, especially given point 3, that you have modified your projects dependencies to fit your project's needs, doesn't it therefore make even greater sense that your code should be distributed with its dependencies?
If your source code cannot be built without first building the bundled code bits [ +10 points of FAIL ]
Doesn't this necessarily have to be the case for software built against 3rd party libs? Your code needs that other code to be compiled into its library before the linker can work?
If you have modified those other bundled code bits [ +40 points of FAIL ]
If this is necessary for your project, then it naturally follows that you've bundled said code with yours. If you want to customize a build of some lib,say WxWidgets, you'll have to edit that projects build scripts to bulid the library that you want. Subsequently, you'll have to publish those changes to people who wish to build your code, so why not use a high level make script with the params already written in, and distribute that? Furthermore, (especially in a windows env) if your code base is dependent on a particular version of a lib (that you also need to custom compile for your project) wouldn't it be easier to give the user the code yourself (because in this case, it is unlikely that the user will already have the correct version installed)?
So how would you respond to these comments, and what points may I be failing to take into consideration? Would you agree or disagree with the author's take (or mine), and why?
Edited for clarification.
Your source only comes with other code projects that it depends on.
My project requires project X.
However, since my project depends on secret inner mysteries of X, or a previous release of X, then my project includes a copy of X. Specifically release n.m of X. And no other.
Try to install the latest and greatest X and see what breaks in my project. Since upgrading X broke my project, forget my project. They will not struggle with something that spontaneously breaks after an update. They will find a better open source component.
Hence a FAIL score.
If your source code cannot be built without first building the bundled code bits.
My project doesn't rely on the API to X. It relies on deep, inner linking to specific parts of X, bypassing the API.
If my project on depended on the API to X, then -- for some languages like C or C++ -- my project could compile with only the C or C++ headers, not the binaries.
For Java this is less true, since there is not independent, non-binary header. And for dynamic languages (like Python) this makes no technical sense.
However, even Java and Python have ways to separate interface from implementation. If I rely on implementation (not interface), then I've still created the same essential problem.
If my project depends on C or C++ binaries, and they build things out of order, or upgrade another component without rebuilding mine, things may go badly for them. They may see weirdness, breakage, "instability". My product appears broken. They won't (and can't) debug it. They're done. They'll find something more stable.
Hence a FAIL score.
If you have modified those other bundled code bits.
I have two choices when I modify X.
Get it accepted as part of X.
Fix my program to work with unmodified X.
If my project depends on a modified X, no one can install X simply, correctly and independently. They can't upgrade X, they can't maintain X. They probably can't apply bug fixes or security patches to X.
I've essentially made their job impossible by modifying X.
Hence the FAIL score.
Subsequently, you'll have to publish those changes to people who wish to build your code.
Actually, they'll hate me for that. They don't want to know about the mysterious changes to X. They want to build X according to the rules, then build my stuff according to the rules. They don't want to read, think or be sure that the mystery update patch kit was applied correctly.
Rather than joke around with that, they'll download a competing package. FAIL.
if your code base is dependent on a particular version of a lib (that you also need to custom compile for your project)
That's really shabby. If I depend on a version with custom compiles, they're done looking at my package. They'll find something without version-specific inner mysteries and custom compiles before they'll struggle. FAIL.