You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 3, 2018. It is now read-only.
When adding a new dependency, it's useful to be able to trick the static analyzer by adding a couple of packages as 'sources', even if only just temporarily. This lets a project get reconciled into the graph, included in the lock and downloaded into vendor at the time when the user issues a command like glide get. This allows the user to start importing and working from that package immediately, rather than needing to re-run another command after having actually introduced import statements for the named package.
To be concrete - without this kind of control, the workflow is awkward:
User runs <tool> get github.com/foo/bar
tool adds appropriate constraint to manifest
vsolver quietly ignores the constraint on the first run because the project (presumably) doesn't actually import github.com/foo/bar yet
User makes some changes in their editor, tries to add something that imports github.com/foo/bar
Maybe their autocomplete fails
Or worse, maybe their autocomplete, or goimports, picks up a copy of that dep from $GOPATH, which may not be the version they actually specified
Either way, user "wtfs" at some point, until they re-run a solve with that import path in the source code
With this control, it's much better:
User runs <tool> get github.com/foo/bar
tool adds appropriate constraint to manifest
tool injects github.com/foo/bar via this new param as a required package
vsolver runs the solve and includes that package+project
or maybe fails b/c the package doesn't exist, but that's also good to know
User goes on their merry way
The only issue here is that, if another solve is run BEFORE adding an import, there's no reasonable way for a tool to know to add those forced arguments again - not without keeping some icky, icky state somewhere. Perhaps that, though, is a reasonable cost.
The text was updated successfully, but these errors were encountered:
When adding a new dependency, it's useful to be able to trick the static analyzer by adding a couple of packages as 'sources', even if only just temporarily. This lets a project get reconciled into the graph, included in the lock and downloaded into
vendor
at the time when the user issues a command likeglide get
. This allows the user to start importing and working from that package immediately, rather than needing to re-run another command after having actually introduced import statements for the named package.To be concrete - without this kind of control, the workflow is awkward:
<tool> get github.com/foo/bar
vsolver
quietly ignores the constraint on the first run because the project (presumably) doesn't actually importgithub.com/foo/bar
yetgithub.com/foo/bar
goimports
, picks up a copy of that dep from$GOPATH
, which may not be the version they actually specifiedWith this control, it's much better:
<tool> get github.com/foo/bar
github.com/foo/bar
via this new param as a required packagevsolver
runs the solve and includes that package+projectThe only issue here is that, if another solve is run BEFORE adding an import, there's no reasonable way for a tool to know to add those forced arguments again - not without keeping some icky, icky state somewhere. Perhaps that, though, is a reasonable cost.
The text was updated successfully, but these errors were encountered: