proposal: Better dependency management #41510
Labels
FrozenDueToAge
Proposal
WaitingForInfo
Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Even after the introduction of Go modules, the dependency management is complex and not so developer friendly. For beginners it takes a good amount of time to understand what's going on behind the scene.
Some of this may be because of lack of well written documentation about dependency management.
There are some confusing syntax, for example
github.com/myorganzation/mypackage/pkg
This url results in 404 in browsers but somehow go resolves it, so it seems like depending on hosting providers such as GitHub, BitBucket etc go have different mechanisms of resolving the URL.
Which is somewhat described in here
Upgrading to major version with a suffix like
vX
Though i am not sure about this but i didn't find any way by which i can tell that this indirect dependency x is from the dependency y, just by looking into
go.sum
orgo.mod
files.Error messages not being so helpful
If i try to
go get
a package in a directory which is not a module i get an error message which is not so helpful for beginnersGophers please do let me know your thoughts about this, also request you to think about these issues from a beginners perspective especially if someone is coming from JavaScript or Python background.
I feel like there is a steep learning curve for go dependency management, which can be made easy with little changes in go and it's documentation.
Edit: Adding some suggestion to deal with the problems I mentioned above
Some high level suggestion to deal with the current problems
Problem 1: The current way of downloading, using & maintaining a package
I like the idea of not having a central registry like
npm
orpip
. However using repo URLs (that is also some modified URL) everywhere in the codebase to import the package doesn't seem to be the best way.Instead what we can do is use git URLs
git+ssh://git@github.com/myorganization/mypackage
(HTTPS url works too), only at one place, i.e. our dependency file (currentlygo.mod
)With this, we can also refer to a particular branch, tag or commit.
Now our dependency file (currently
go.mod
) will have a mapping of module name and its URL to create an alias for the module, for examplemypackage git+ssh://git@github.com/myorganization/mypackage
Everywhere in the code base a consumer will use the alias name instead of a URL to import the package, for example
import "mypackage"
Now how do we know where the module is located inside the repo ? Right now we add a
go.mod
file in every module root directory. With this change maybe we can add a single file in the repo root which will tell where the modules are located relative to the repo root. I guess this will give more flexibility to both the module developer and consumer.For updating version, we can either do it manually by changing the URL or maybe via some tool like
go update mypackage
Problem 2: Improving the error messages
This might be a simpler problem to solve compared to the above one. There is no specific solution to this. I think the best way is to run an audit to figure out point of failures while working with modules in go. And try to have as much meaningful error message as possible with some detailed log.
This is very high level solution proposal, happy to discuss more on it and also pros & cons, gotchas, bottlenecks etc.
The text was updated successfully, but these errors were encountered: