Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go += Package Versioning

research.swtch.com

Post reply on HN
Print view View original

151–160 of 213 posts

Re: Go += Package Versioning

#151

Post by mook »

shkkmo wrote: post #92

I think that the choice to use "prefer minimum version by default" going to confuse a lot of new developers used to the industry standard being the opposite. If you are going against the industry default, there should be a strong reasons. I don't think reasons provided really justify this. > First, the meaning of “newest allowed version” can change due to external events, namely new versions being published. Maybe to…

If you want to check that you're building with the sources you think you're building, you probably don't want to be using `go get` anyway; the internet is kinda lossy, and that repo you wanted to pull probably doesn't exist anymore. I would probably use the proxy / redirect support to feed it the known-good sources you archived (a la maven / srpm / etc.).

As an example, jteeuwen/go-bindata was deleted this month and somebody made a new repo in its place... hopefully with the same contents.

Re: Go += Package Versioning

#152

Post by gkya »

Highly suggest to read the demo at https://research.swtch.com/vgo-tour, which really clarifies everything. I do not write Go, but I did write some bits in it in the past, and now think that this will be a very useful addition to the Go toolchain. When I looked at Go for the first time I really disliked the simple but sort-of castrated go-build, and didn't really follow the developments since then, but this seems to solve quite a bit of problems. I especially like how you can shadow a certain dependency with a given package at a given path, and how it facilitates vendoring. Hope this becomes included in go soon.

Re: Go += Package Versioning

#153

Post by munificent »

joncalhoun wrote: post #146
munificent wrote: post #84

Earlier quoted context omitted.

> Using the min version appears to eschew the need for lock files. This only works if the system also prevents you from publishing a version of a package with a lower number than any previously-published version of that package. So, for example, after you've shipped foo 1.3.0, if a critical security issue is found in foo 1.2.0, you can't ship foo 1.2.1. Instead, all of your users have to deal with revving all the way…

You CAN ship v1.2.1 after v1.3.0 is live. I have tested this with the vgo prototype and it works fine (see github.com/joncalhoun/vgo_main): $ vgo list -m -u MODULE VERSION LATEST github.com/joncalhoun/vgo_main - - github.com/joncalhoun/vgo_demo v1.0.1 (2018-02-20 18:26) v1.1.0 (2018-02-20 18:25) Notice that v1.0.1 was released AFTER v1.1.0 What the minimum version is doing is giving our code a way to automatically re…

What happens if:

1. I depend on foo with constraint ">1.5.0". The current minimum version of foo that meets that is 1.7.0.

2. Later, foo 1.6.0 is published.

3. I run go get.

If I understand the proposal correctly, that go get will now spontaneously downgrade me to foo 1.6.0. That defies the claim that builds are always reproducible.

Re: Go += Package Versioning

#154

Post by munificent »

binarycrusader wrote: post #57
uluyol wrote: post #46

Earlier quoted context omitted.

Actually, I think the SAT solver is avoided by making the only version constraints of the form Using the min version appears to eschew the need for lock files. Want to upgrade? Bump your min version.

One potential problem with dependency resolution that focuses solely on minimal or maximal-bound resolution is that it usually ignores the untested version combination problems. That is, a given version that satisfies a version bound may not have necessarily been tested with all of the different combinations of versions of components it is used with. It will be interesting to see how minimal version selection interac…

As far as I know, that problem is effectively unsolvable. For most real-world-sized dependency graphs, the set of all valid combinations of dependency versions is heat-death-of-the-universe huge.

Re: Go += Package Versioning

#155

Post by sitkack »

munificent wrote: post #33

I'm going to comment mostly on the parts of the proposal that I think are wrong, but don't take this to be an overall negative response. I'm excited to see smart folks working on this, and package management is a really hard problem. There are no silver bullets to code reuse. Context for those who don't know: I along with Natalie Weizenbaum wrote pub[1], the package manager used for Dart. > Instead of concluding from…

> Dart does not let you have two versions of the same package in your application

Not as direct imports, but Rust allows transitive deps to get the version they specify.

Re: Go += Package Versioning

#156

Post by sitkack »

munificent wrote: post #131
dkarl wrote: post #124

Earlier quoted context omitted.

For what it's worth, Dart does not let you have two versions of the same package in your application, even different major versions. This restriction does cause real pain, but it doesn't appear to be insurmountable. Most of the pain seems to be in the performance issues over-constrained dependencies caused in our old version solver and not in the user's code itself. In almost all cases, I think there is a single vers…

> I think this makes a strong case for not releasing major version upgrades that use the same package names. The very idea of two incompatible things having the same name should set off alarm bells. Instead of trying to make that work, we should be avoiding it. If you do that, I think you'll find in practice that one of two things happens (or more likely, both , in a confusing mixture): 1. People start releasing pack…

The major version goes into the name, marldown2, but the version numbers should be monotonic, so when when viewed on a number line they are in-order. This also allows the programmer to import both, and have a smooth transition between the deps.

Re: Go += Package Versioning

#157

Post by acdha »

xrstf wrote: post #129

A lot of this seems to hinge on "go get" being the best way to get Go source code. Most discussions I've read so far come down to "well, this might be cool, but it would break go get, so we cannot ever do it". I for one could live without go get alltogether. In 99% of cases it boils down to a simple git clone anyway, which could (should?) be done by the package manager anyway. Maybe it's time to re-evaluate the exist…

I find it bizarre how unnecessarily hard that’s been made to avoid a slight amount of extra typing. The github imports work with the most basic options but I’ve seen people waste a lot of time on internal servers, SSH vs. HTTPS, tagging, etc. where it’d have been cleaner, easier and forward-compatible if you just gave it a URL and it shelled out to run “git clone ”.

Re: Go += Package Versioning

#158

Post by Zamicol »

abvdasker wrote: post #83
baq wrote: post #61

Earlier quoted context omitted.

Lock files are best of both worlds: you specify the latest at check in time and then freeze whatever was picked. No need to reinvent the world.

Yeah it's crazy that there's still so much controversy around this topic considering Node and Ruby have had amazing dependency management for over half a decade at this point. Dependency management in those languages is pretty much a solved problem and the fact that go isn't there yet drives me nuts since I have to work with it every day for my job.

Node breaks on me all the time.

Re: Go += Package Versioning

#159

Post by slrz »

stormbeta wrote: post #25
warent wrote: post #10

Earlier quoted context omitted.

I've been programming in Go for a couple of years now and found that this need to use "hacks ... to avoid it" is totally naive and irrational. Agreed, GOPATH is awkward--at first. Because it's different from what most programmers are used to. But once it's adopted it actually makes a lot of sense, and looking back it seems bizarre to ever have such a strong desire to avoid it at all costs--and the costs are high. The…

gofmt, sure. Consistency in style is great. But GOPATH was a mistake in the same way Go's hitherto lack of versioning was: it deliberately breaks easy isolation between projects / dependency management. This mindset only works if you control most of the ecosystem (such as with a monorepo), but it's a irritating mess otherwise.

But you do control all the source code within your GOPATH! It's right there on your file system.

There's also a mechanism to take control of the same code even when it's outside your GOPATH. Github calls this mechanism a "pull request".

Re: Go += Package Versioning

#160

Post by clinta »

Sir_Cmpwn wrote: post #5

>End of GOPATH Yes yes yes yes finally! This has been the #1 reason I've avoided Go for years and even my recent forays back into the language were only after I figured out some hacks that I could use to avoid it.

GOPATH was weird to get used to at first, but I gave in and I actually store all my projects, even non-go projects, in the same folder hierarchy now. It has made me much more organized. In fact here's a zsh function I have for cloning new projects into that structure. It makes my home directory much less of a mess.

  gclone() {
  		dir=$(echo $1 | sed 's/^http\(s*\):\/\///g' | sed 's/^git@//g' | sed 's/\.git$//g' | sed 's/:/\//g' )
  		git clone $1  "$HOME/src/$dir"
  		cd "$HOME/src/$dir"
  }
Post reply on HN