3 ms·

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 fi

by uluyol 9y ago

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.

binarycrusader 9y ago
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 interacts with that particular challenge. For a build system it may matter much less than an operating system.
- munificent 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
  - binarycrusader 9y ago
    The way the system I worked on "solved it" was to provide another layer of constraints called "incorporations" that effectively constrained the allowed versions used to resolve dependencies to a version that was delivered for a given OS build. Administrators could selectively disable those constraints for some packages, at which point resolution was solely based on the "standard" dependencies. But by default, dependencies would "resolve as expected". The "incorporate" dependencies are described here: https://docs.oracle.com/cd/E26502_01/html/E21383/dependtypes.html#gluna https://docs.oracle.com/cd/E26502_01/html/E21383/dependtypes...
munificent 9y ago
> 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 up to foo 1.3.1 where you're allow to publish a fix. It's not clear to me why they're trying so hard to avoid lockfiles. Lockfiles are great.
- ithkuil 9y ago
  If your module requires at least version 1.3.0 of a dependency (i.e. 1.3.0 is the minimum version that satisfies the constraint) then it doesn't matter if a new version appears upstream. 1.3.0 is always the minimum version that satisfies >=1.30. That is, unless version 1.3.0 disappears from upstream. If there is only one constraint against a dependency, then it behaves exactly as version locking. The "maximum of the minimums" rule kicks in when the same dependency appears more than once in the dependency graph, because the constrains might be different. vgo won't fail and say "incompatible versions". It will just resolve to the biggest of the lower limits. It's up to the build and test system to judge if the combination works.
- joncalhoun 9y ago
  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 resolve upgrades if they are necessary. Eg if module X requires module Z w/ a version >= 1.0.1, while module Y requires Z with a version >= 1.1.0 we clearly CANNOt use v1.0.1, as it won't satisfy the requirements of Y, but we CAN use v1.1.0 because it satisfies both. The "minimum" stuff basically means that even if a version 1.3.2 of Z is available, our code will still use v1.1.0 because this is the minimal version to satisfy our needs. You can still upgrade Z with vgo, or if you upgrade a module X and it now needs a newer version of Z vgo will automatically upgrade in that case (but to the minimal version that X needs), but random upgrades to new versions don't just occur between builds.

by uluyol 9y ago

binarycrusader 9y ago

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 interacts with that particular challenge. For a build system it may matter much less than an operating system.

munificent 9y ago
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.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- binarycrusader 9y ago
  The way the system I worked on "solved it" was to provide another layer of constraints called "incorporations" that effectively constrained the allowed versions used to resolve dependencies to a version that was delivered for a given OS build. Administrators could selectively disable those constraints for some packages, at which point resolution was solely based on the "standard" dependencies. But by default, dependencies would "resolve as expected". The "incorporate" dependencies are described here: https://docs.oracle.com/cd/E26502_01/html/E21383/dependtypes.html#gluna https://docs.oracle.com/cd/E26502_01/html/E21383/dependtypes...

munificent 9y ago

> 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 up to foo 1.3.1 where you're allow to publish a fix. It's not clear to me why they're trying so hard to avoid lockfiles. Lockfiles are great.

ithkuil 9y ago
If your module requires at least version 1.3.0 of a dependency (i.e. 1.3.0 is the minimum version that satisfies the constraint) then it doesn't matter if a new version appears upstream. 1.3.0 is always the minimum version that satisfies >=1.30. That is, unless version 1.3.0 disappears from upstream. If there is only one constraint against a dependency, then it behaves exactly as version locking. The "maximum of the minimums" rule kicks in when the same dependency appears more than once in the dependency graph, because the constrains might be different. vgo won't fail and say "incompatible versions". It will just resolve to the biggest of the lower limits. It's up to the build and test system to judge if the combination works.
joncalhoun 9y ago
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 resolve upgrades if they are necessary. Eg if module X requires module Z w/ a version >= 1.0.1, while module Y requires Z with a version >= 1.1.0 we clearly CANNOt use v1.0.1, as it won't satisfy the requirements of Y, but we CAN use v1.1.0 because it satisfies both. The "minimum" stuff basically means that even if a version 1.3.2 of Z is available, our code will still use v1.1.0 because this is the minimal version to satisfy our needs. You can still upgrade Z with vgo, or if you upgrade a module X and it now needs a newer version of Z vgo will automatically upgrade in that case (but to the minimal version that X needs), but random upgrades to new versions don't just occur between builds.