Workiva / dpx

Apache License 2.0
1 stars 0 forks source link

Should dpx install latest if no version constraint is given? #11

Open evanweible-wf opened 5 months ago

evanweible-wf commented 5 months ago

If you specify a version constraint when running a package executable, dpx will first check to see if you have a version of that package already globally activated that satisfies that version constraint:

dpx dependency_validator@^4.0.0

This makes the process faster by avoiding unnecessary network requests.

But, if you're omitting the version constraint for brevity, like this:

dpx dependency_validator

Then any version of that package, if already activated, will technically satisfy the omitted version constraint. That may be fine, but it may lead to confusing behavior if you were expecting to be able to use an option or some behavior that was only recently released.

Would a better default be to always try to install the latest version of a package if no version constraint is specified?

greglittlefield-wf commented 1 month ago

@evanweible-wf If we decide to stick with the current behavior, having a way to explicitly use the latest would be nice.

For example, something like:

dpx dependency_validator@latest
matthewnitschke-wk commented 1 month ago

From what I can tell, this is a known issue in the npx world of things: https://stackoverflow.com/a/74855146, but they do support the @latest specification that greg mentioned

Parity with npx probably makes the most sense, but if we wanted to get fancy with it, some iterative checking could be interesting

Eg: only for the first execution per day, check version of the script being used. Otherwise just execute what's in the cache. Kind of like how homebrew does it, but during execution of a specific command