3 ms·

Correct, it will get the newest version that is actually tested against your dependencies, which is by design. Why would you want to pull a version that is new

Correct, it will get the newest version that is actually tested against your dependencies, which is by design. Why would you want to pull a version that is newer than the author of the library you depend on has actually tested with? You can of course force this in vgo, but having the default use the versions specified by the authors makes a whole lot more sense than just using the newest.

mfer 9y ago
> Why would you want to pull a version that is newer than the author of the library you depend on has actually tested with? 1. To install a security update or bug fix update you need in a transitive dependency that the author of the dependency you're using hasn't updated to. 2. To use the same workflows across all my dependency management tools (npm, cargo, composer, bundler, and the rest of the lot follow the same patters and vgo goes against the patterns used by the others) There are two reasons.
- stouset 9y ago
  3. To apply bugfixes that affect you, but weren't exposed by your direct dependency's tests.
- nicpottier 9y ago
  You can do 1), you just have make that an explicit dependency of your own. It just won't grab newest by default for sub-dependencies. So yes, you can pull the latest. 2) seems like a bit of a silly reason, if we all wanted to make everything work the same all the time we wouldn't make much progress or try anything new. Whether vgo's approach is correct or not we don't know yet, but saying that it isn't familiar isn't a good enough reason to not try it out. To me, vgo matches what we already do in our python projects with a lot of dependencies. Pin everything in a freeze and upgrade on a schedule when we need to. We have seen far too many failures doing it any other way. (IE, using the "latest" of everything, which often either breaks semantic versioning and actually breaks or has subtle bugs that didn't exist before)
  - Groxx 9y ago
    Using something like pip-compile, or literally `pip freeze > requirements.txt`?
    - nicpottier 9y ago
      The latter yes.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]

mfer 9y ago

> Why would you want to pull a version that is newer than the author of the library you depend on has actually tested with? 1. To install a security update or bug fix update you need in a transitive dependency that the author of the dependency you're using hasn't updated to. 2. To use the same workflows across all my dependency management tools (npm, cargo, composer, bundler, and the rest of the lot follow the same patters and vgo goes against the patterns used by the others) There are two reasons.

stouset 9y ago
3. To apply bugfixes that affect you, but weren't exposed by your direct dependency's tests.
nicpottier 9y ago
You can do 1), you just have make that an explicit dependency of your own. It just won't grab newest by default for sub-dependencies. So yes, you can pull the latest. 2) seems like a bit of a silly reason, if we all wanted to make everything work the same all the time we wouldn't make much progress or try anything new. Whether vgo's approach is correct or not we don't know yet, but saying that it isn't familiar isn't a good enough reason to not try it out. To me, vgo matches what we already do in our python projects with a lot of dependencies. Pin everything in a freeze and upgrade on a schedule when we need to. We have seen far too many failures doing it any other way. (IE, using the "latest" of everything, which often either breaks semantic versioning and actually breaks or has subtle bugs that didn't exist before)
- Groxx 9y ago
  Using something like pip-compile, or literally `pip freeze > requirements.txt`?
  - nicpottier 9y ago
    The latter yes.

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]