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

131–140 of 213 posts

Re: Go += Package Versioning

#131

Post by munificent »

dkarl wrote: post #124
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…

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 packages whose names include version numbers. "markdown2", etc. Then you get really confusing hallways conversations like, "Yeah, you need to use markdown2 1.0.0."

2. People start coming up with weird confusing names for the next major version of packages because the current nice name is taken. Then you get confusing conversations like, "Oh, yeah, you need to upgrade from flippitywidget to spongiform. It's almost exactly the same, but they removed that one deprecated method." Also don't forget to rename all of your imports.

Re: Go += Package Versioning

#132

Post by munificent »

joncalhoun wrote: post #114
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…

You (and likely everyone else) should look at the tour as well before commenting, as I think many people are misunderstanding some of the subtler points. > If I'm starting a brand new from scratch Ruby on Rails application today, in 2017, there is no reason it should default to having me use Rails 1.0 from 2005. In the tour it states, "We've seen that when a new module must be added to a build to resolve a new import…

> In the tour it states, "We've seen that when a new module must be added to a build to resolve a new import, vgo takes the latest one." which means that the newest Rails would be used and set in your `go.mod` file.

That works for adding a new dependency. But, as I understand it, if I decide to upgrade my dependency on foo by changing its already-present version in my app's module file, this does not upgrade any of the transitive dependencies that foo has. Instead, it selects the lowest versions of all of those transitive dependencies even though my goal with foo itself is to increase its version.

So now I have to reason about sometimes it picks the latest version and sometimes it doesn't, depending on the kind of change I'm making.

Re: Go += Package Versioning

#133

Post by stock_toaster »

I feel like the Go devs optimized implementation simplicity early on (likely a sensible choice given Google's "one giant repo" workflow), and that has resulted in some not-insignificant ecosystem complexity later (for others not using "one giant repo" workflows).

It will be interesting to see how this plays out in the longer term.

Re: Go += Package Versioning

#134

Post by makapuf »

wtetzner wrote: post #91
lsaferite wrote: post #85

Earlier quoted context omitted.

Use 'git bisect' or some similar tool to walk back and find the point where the lock file change triggered the bug?

If you have a lock file, there's no problem. I was arguing about what happens when there isn't a lock file. I may have inferred something that wasn't in the original comment, by reading too many of the other comments on this page.

Sort but given that we're relying on git mostly, what are the advantages of lock files over submodules/subtrees ?

Re: Go += Package Versioning

#135

Post by stickfigure »

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 and Ruby have had amazing dependency management for over half a decade at this point.

Eh?

NPM didn't have package-lock.json until v5, released in 2017. Before then there was the optional shrinkwrap that nobody used, so builds were totally unreproducible.

Ruby at least had Gemfile.lock from early days. Unfortunately there have been so many compatibility problems with different versions of Ruby itself that someone needed to invent rvm, rbenv, and chruby. Getting every dependency to behave in the same Ruby version was sometimes an odyssey. Still, at least builds are reproducible... as long as you're running on the same OS/CPU arch (uh oh native code!)

Ruby is actually pretty alright given the constraints, but Node/NPM is the canonical example of how NOT to do dependency management, and they're still trying to figure out here in 2018.

Re: Go += Package Versioning

#136

Post by icholy »

platz wrote: post #111

> A build of a module by itself will always use the specific versions of required dependencies listed in the go.mod file. As part of a larger build, it will only use a newer version if something else in the build requires it. This seems fraught

I think you need a noun to go with that adjective.

Re: Go += Package Versioning

#137

Post by dkarl »

XorNot wrote: post #130
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'm not really enthused by efforts to bring in the same packaging constructs as other languages, which all have the effect of making time-to-compile after git clone longer. Frankly I think we tend to conflate two separate but related tasks in these discussions: communicating updates, and distributing dependencies. vendor/ folders are a totally fine distribution system - optimal even. Time-to-compile is 0 because you…

According to the article, the solution I suggest has been proposed in the Go community, and I don't know of any language where it has actually been adopted, so Go might be the first. I just know that Java has been forced to work around its absence.

As for the tasks that need to be solved here, the primary one I see is reconciling the needs of different libraries. What do you do when you depend on library A and library B and they need two incompatible versions of library C? As I see it, there's no clean way to answer that question if A and B expect the two incompatible versions to be present with the same name.

Re: Go += Package Versioning

#138

Post by merb »

dkarl wrote: post #124
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…

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…

> In the absence of this principle, the Java ecosystem has developed a compensatory mechanism of packaging "shadowed" versions of their dependencies alongside their own code.

well that is okish..

however... looking at the xml stuff.. that is probably bad. basically a lot of packages repackage xerces2 or the java.xml apis. besides that jaxp with streaming is present in java since 1.6+. But nobody removes this stuff.

Re: Go += Package Versioning

#140

Post by platz »

icholy wrote: post #136
platz wrote: post #111

> A build of a module by itself will always use the specific versions of required dependencies listed in the go.mod file. As part of a larger build, it will only use a newer version if something else in the build requires it. This seems fraught

I think you need a noun to go with that adjective.

With danger
Post reply on HN