[cmccabe]

Go's package manager does have version control. It looks for specially named branches (different ones depending on the version of go you have). The upstream authors can provide a different version of the software for different releases of Go.

If you want to lock down the versions of all the software you're deploying in your organization, that's easy to do too. Just "git clone" all of the libraries you use to some internal server (and/or github repos), and change the URLs to point to that server. You control when everything gets updated.

Golang builds static binaries anyway. So if you test a binary and it works, you just copy it to all the servers you care about and you're done. If you're in a small and informal shop, maybe you don't need to mirror every repository. Due to the nature of git, if the upstream repo ever gets deleted, you can fall back on a local copy of it anyway.

This is all very much in contrast to languages like Java where keeping around the proper version of every jar and carefully deploying that version (and only that version!) on each server is big deal (and despite OSGI, still very much an unsolved problem.)

[grey-area]

The go import tool does version go std lib packages, but I think the worry is more about external packages - later when the go ecosystem matures, and I'm relying on lots of packages from different sources (say for a web app), with interdependencies, and I must update them regularly for security updates, but don't necessarily want the latest master for all, I have no way to specify versions without rolling my own personal package management, downloading the packages and changing urls etc. If I'm in an org and sharing this with others I'd basically end up reinventing a package proxy internally in order to control what software versions are used to build.

This is a small flaw in the go packaging system (and it is a flaw) which I'm sure they'll fix, either with a convention to always use branches for versions (which I guess is doable, but only if it becomes widespread), or by changing import to take an argument for the version. So something like:

    import "github.com/gorilla/mux/1.0.3"

or

    import "github.com/gorilla/mux", ~> "1.0.3" 

which would let you specify any minor updates say and possibly other permutations, and thus might be more flexible. I believe a few things have been suggested on the list but I haven't followed the conversation, not sure what the outcome was - perhaps just that it needs further thought.

At present the first solution is possible, BUT it needs to become a convention which everyone follows in order to be useful (involving named branches or tags at the repo). The other advantage of this is that it states requirements fully in the package concerned - otherwise all we know is that this code requires github.com/gorilla/mux, not which version or when it was last tested/imported, whether it will work with the latest release or not, etc. But then it would let you run into conflicts by accidentally importing two versions of the same package with different paths.

The current convention of no version certainly puts more onus on the package maintainers to maintain backwards compatibility, or on users to maintain their own library of packages which they periodically update, and I see the arguments for it.

Of course none of this matters if you're just one person using packages to build an app at one moment in time, but if you yourself supply packages/apps to others, or want to setup members of an org over time with the same set of packages in the same state, and rely on other packages to compile yours, it can become more complex.

Other package managers tend to have a central point to adjust package dependencies, and make sure packages are always available forever at the same uri, so it'll be interesting to see how go manages this when go packages become more complex and widely used, start to be removed by maintainers, and start to have complex chains of dependencies on specific versions, or whether the much simpler go system in the end leads to a saner situation and puts the onus for this problem back on end users.

[tferris]

Great having one bringing a balanced view on Go and showing that Go is still not ready for production when used with external libs. A refreshing take in this overhyped thread.

[grey-area]

I'm not sure I'd agree that it is not ready for production, but there are some kinks (relatively minor I feel) which will become more apparent when it is used more widely than it is currently in production. Just as Ruby (for example) has gone through a trial of fire since becoming popular because of Rails, and has been much improved because of it.

[cmccabe]

Java and C++ never developed package management at all, but have been used in production for years. Golang is already ahead of those languages here.

[cmccabe]

it'll be interesting to see how go manages this when go packages become more complex and widely used, start to be removed by maintainers, and start to have complex chains of dependencies on specific versions

"Complex chains of dependencies on specific versions" is an anti-pattern, common in the Java world. I am glad that Golang doesn't support or encourage this anti-pattern.

If someone deletes your favorite package, then you can just re-upload it from your cache and let people know about the new URL-- assuming that the code is open source.

If you want to make a backwards-incompatible change in your library, then just create a new version and call it something (slightly) different. There's no reason to complicate things.

[grey-area]

"Complex chains of dependencies on specific versions" is an anti-pattern, common in the Java world.

I do have some sympathy for this radical simplicity which Go aims for, but at times it comes at a cost, and at times a little bit of complexity has to be added to deal with the real world (only very rarely and after much thought though). I'm torn between admiring that they don't rush into new features and impatience with a few small things they've refused to add so far.

If someone deletes your favorite package, then you can just re-upload it from your cache and let people know about the new URL-- assuming that the code is open source.

Well yes, but then you're de-facto maintainer of that package, you might not have permission to do that, etc - this point though I feel is less important than versioning, it's more an argument for central package control, which has pros and cons. I'd be happy if Go never does that and agree that it can be worked around but will be interested to see if people judge it necessary eventually. There's nothing to stop people setting up a central package resource, and nothing really needs to be added to go to support it.

If you want to make a backwards-incompatible change in your library, then just create a new version and call it something (slightly) different. There's no reason to complicate things.

This is not an acceptable solution, it would lead to situations like:

    import 'github.com/user/yaml_parser'
    import 'github.com/user/new_yaml_parser'
    import 'github.com/user/really_new_yaml_parser'
    import 'github.com/user/toms_new_yaml_parser'

What a mess, particular for new users trying to decide which package is best or canonical. Why not just use versions?

I wouldn't be so quick to defend the status quo - Go is a young language with plenty of maturation still to do, they could easily add versions to packages if it proves necessary - I suspect in the long term it will, because large ecosystems do involve chains of dependencies (I'm not talking about java here, but perl, python, ruby, java, C++, etc all of these languages version libraries in some way), and developers of packages make mistakes which they need to fix, sometimes by deprecating or removing compatibility, but their users don't want to deal with those mistakes, sometimes for years, and the users of their users certainly don't. Choosing a new name and orphaning all your users is not an acceptable solution.

I'd prefer if package maintainers could just do this:

    import 'github.com/user/yaml_parser'
    import 'github.com/user/yaml_parser/1.0'
    import 'github.com/user/yaml_parser/1.0.1'

etc and left the master as the plain name with version tags as longer names. It'd be nice if go supported this by supporting arbitrary branches or tags on github etc but I don't think it does at present, happy to find out I'm wrong.

[cmccabe]

Well yes, but then you're de-facto maintainer of that package, you might not have permission to do that, etc - this point though I feel is less important than versioning, it's more an argument for central package control, which has pros and cons

If you're using a library from github (or wherever) that isn't open source, and someone takes it offline, that's a legal problem, not a technological one. If you are using an open source library, then just re-upload it (or find someone who will). I don't see why the language has to do anything.

What a mess, particular for new users trying to decide which package is best or canonical. Why not just use versions?

You know what a mess is? A mess is:

* In a Maven build, A depends on version 1 of C, A depends on B, B depends on version 2 of C. Result: Java crashes at runtime.

* People using ancient (potentially insecure) versions of Java packages for years because they're afraid of the previous problem.

* "deprecated" functions that continue to be used for years, spewing warnings each time they're referenced.

* a time-consuming bureaucratic process to get your library into some "blessed" central repository.

Go doesn't "support" these messes, and I see no reason why it should.

Perhaps Go's dependency management system will change. I can't tell the future. But so far, I haven't seen any good arguments in favor of changing it. All of the problems you think you're solving with versions could be solved by either maintaining backwards compatibility, or choosing a new package name when you feel you have to break it.