5 ms·

This can be solved with other tools and community choices. For example, introducing automated systems which update dependencies to more recent versions, run au

This can be solved with other tools and community choices. For example, introducing automated systems which update dependencies to more recent versions, run automated tests (you already have CI set up, right?), and notify authors (including a PR; why not?) when versions can be bumped automatically. This sort of system A) doesn't involve a SAT solver and B) gets things up to date all the time. It's also roughly analogous to the principles that `go get` has already forced into the norm in the community: things should build and work against master in the dependencies; if they don't, you've got problems. At the same time, since precise dependency versions are tracked, changes can be absorbed at a controlled rate. What a trade!

greysteil 8y ago
This is exactly what we do with Dependabot. We have support for dep right now (along with other languages) and will be adding modules support in the next few days.
- jacques_chester 8y ago
  I am required by law to beg you to write a Concourse resource that spits out streams of candidate upgrades. I've wanted someone to do this for years (and been too lazy to try it myself).
jacques_chester 8y ago
> This sort of system A) doesn't involve a SAT solver and B) gets things up to date all the time. I've argued for this in various forms for years. Regardless of how the dependency version is calculated, having that version chosen outside the context of version control is asking for trouble. The reason that maximal version selection existed in the first place was that manually updating dependencies has been seen as too hard, so it gets punted to the tool. The net result is that the code in production can't necessarily be associated with a particular dependency. Of course there's a cottage industry for doing this automatically, as their should be. In the case where proper CI and automation exists, I feel like minimal selection has a slight edge in that it is less likely to click unexpectedly upwards. But in practice, the practice of automation makes the overall policy of version selection close to irrelevant. Automate automate automate. Never leave this stuff to chance.
felixfbecker 8y ago
This would still mean that (the deeper the dependency tree) updates take longer to trickle down to your project, and to spread across the whole ecosystem. Not everyone will have these tools set up, and they will still cause a delay since it's a waterfall - one maintainer merges the PR days after it gets raised, then they release a new version maybe a week or month later, then PRs for that package get raised, and so on. As the writer of an application I like the power of short-cutting that path if needed for an important update of a transitive dependency by simply telling my package manager to update the lockfile, vs having to wait for the update to trickle through the chain of dependencies. This may not be a problem in Go, where projects don't have that many dependencies and dependency trees are usually very flat, i.e. dependencies don't often have subdependencies¹. But in the JS ecosystem an average application has thousands of dependencies, many levels deep (as it's super common for libraries to have many subdependencies), so the effect on the ecosystem would be huge. And if there are more old versions around, that creates more maintenance effort for maintainers (you cannot avoid this with policies no matter how hard you try, proved empirically by having been an open source maintainer of many projects). ¹As to why this is, I think it is partly because Go dependency management has been so bad - you can't really depend on other packages in your library if there is no standard way to declare them. Better and more standardized dependency management will likely also make people rely on dependencies more (especially in libraries, so the tree will become deeper). But it's also some culture in Go I've observed that I've heard being described as "copy+paste oriented programming". Go is more verbose than other languages and people don't have a problem with duplicating code that much. And the Go standard library is enough for most use cases - on the other side, native JS APIs are notoriously bad (especially historically with browser differences etc), so relying on libraries for everything is completely natural (you're weird if you don't).
- heavenlyhash 8y ago
  > updates take longer to trickle down to your project Not necessarily. Who said that we're honoring constraints every single library declared for its transitive dependencies? We could. But perhaps we should be careful not to assume all systems have to be built this way. > in Go ... dependency trees are usually very flat ; in the JS ecosystem ... many levels deep Right. So if we made the choice by fiat to simply disregard version constraints proposed by libraries for their transitive dependencies, and determine our own version selections purely by testing satisfaction of interfaces and tests, this would work out very differently in these two ecosystems due to those coefficients. In one of them, it's quite tenable in practice.

greysteil 8y ago

This is exactly what we do with Dependabot. We have support for dep right now (along with other languages) and will be adding modules support in the next few days.

jacques_chester 8y ago
I am required by law to beg you to write a Concourse resource that spits out streams of candidate upgrades. I've wanted someone to do this for years (and been too lazy to try it myself).

jacques_chester 8y ago

> This sort of system A) doesn't involve a SAT solver and B) gets things up to date all the time. I've argued for this in various forms for years. Regardless of how the dependency version is calculated, having that version chosen outside the context of version control is asking for trouble. The reason that maximal version selection existed in the first place was that manually updating dependencies has been seen as too hard, so it gets punted to the tool. The net result is that the code in production can't necessarily be associated with a particular dependency. Of course there's a cottage industry for doing this automatically, as their should be. In the case where proper CI and automation exists, I feel like minimal selection has a slight edge in that it is less likely to click unexpectedly upwards. But in practice, the practice of automation makes the overall policy of version selection close to irrelevant. Automate automate automate. Never leave this stuff to chance.

felixfbecker 8y ago

This would still mean that (the deeper the dependency tree) updates take longer to trickle down to your project, and to spread across the whole ecosystem. Not everyone will have these tools set up, and they will still cause a delay since it's a waterfall - one maintainer merges the PR days after it gets raised, then they release a new version maybe a week or month later, then PRs for that package get raised, and so on. As the writer of an application I like the power of short-cutting that path if needed for an important update of a transitive dependency by simply telling my package manager to update the lockfile, vs having to wait for the update to trickle through the chain of dependencies. This may not be a problem in Go, where projects don't have that many dependencies and dependency trees are usually very flat, i.e. dependencies don't often have subdependencies¹. But in the JS ecosystem an average application has thousands of dependencies, many levels deep (as it's super common for libraries to have many subdependencies), so the effect on the ecosystem would be huge. And if there are more old versions around, that creates more maintenance effort for maintainers (you cannot avoid this with policies no matter how hard you try, proved empirically by having been an open source maintainer of many projects). ¹As to why this is, I think it is partly because Go dependency management has been so bad - you can't really depend on other packages in your library if there is no standard way to declare them. Better and more standardized dependency management will likely also make people rely on dependencies more (especially in libraries, so the tree will become deeper). But it's also some culture in Go I've observed that I've heard being described as "copy+paste oriented programming". Go is more verbose than other languages and people don't have a problem with duplicating code that much. And the Go standard library is enough for most use cases - on the other side, native JS APIs are notoriously bad (especially historically with browser differences etc), so relying on libraries for everything is completely natural (you're weird if you don't).

heavenlyhash 8y ago
> updates take longer to trickle down to your project Not necessarily. Who said that we're honoring constraints every single library declared for its transitive dependencies? We could. But perhaps we should be careful not to assume all systems have to be built this way. > in Go ... dependency trees are usually very flat ; in the JS ecosystem ... many levels deep Right. So if we made the choice by fiat to simply disregard version constraints proposed by libraries for their transitive dependencies, and determine our own version selections purely by testing satisfaction of interfaces and tests, this would work out very differently in these two ecosystems due to those coefficients. In one of them, it's quite tenable in practice.