search

dlang / dub

Package and build management system for D
MIT License
676 stars 227 forks source link

Dub should error on inconsistent dub.selection.json file #1389

Open jacob-carlborg opened 6 years ago

jacob-carlborg commented 6 years ago

I highly recommend that Dub should produce an error if the dub.selection.json file is not in sync with the dub.sdl/dub.json file. Currently I think that dub build will automatically update the dub.selection.json file, causing change files in a Git repository. See this discussion for the confusion it creates [1].

[1] https://dlang.slack.com/archives/C59UPP30D/p1519047496000385

s-ludwig commented 6 years ago

Just printing a warning would be a bit more in line with the behavior when the versions in dub.selections.json do not match dub.sdl. In addition to the warning, it would then of course not write the updated dub.selections.json back to disk to avoid the issue here.

jacob-carlborg commented 6 years ago

I guess a warning would be acceptable, as long as it doesn't automatically pull in any new dependencies. I would prefer it to be an error though. Perhaps it's a bit difficult to produce an error now when the current behavior has existed for quite a while. Ideally an existing projects would generate a warning and any new projects would generate an error. Not sure if that's possible.

CyberShadow commented 6 years ago

Currently I think that dub build will automatically update the dub.selection.json file, causing change files in a Git repository.

As we figured out, that wasn't the case - we were patching the makefile to explicitly run dub upgrade.

A warning when there are missing dependencies in dub.selections.json probably won't hurt, though.

jacob-carlborg commented 6 years ago

As we figured out, that wasn't the case - we were patching the makefile to explicitly run dub upgrade.

Aha, I missed that.

SimonN commented 6 years ago

I agree that dub.selections.json violating dub.sdl should be an error, not a warning.

dub's design is that dub.sdl defines loose restrictions on dependencies, then dub.selections.json picks specific dependencies. The program should enforce its own rules: Doing the wrong thing should be hard. (If you want to deviate from the rules, edit both files.)

I develop an application, thus, dub.selections.json should be committed. But I've learned that only today -- for the past 1-2 years, I've thought that dub.selection.json is a mere build artifact, and whenever I've updated versions in dub.sdl, I've troubleshot people's failing builds by telling them to delete dub.selections.json.

This was certainly an antipattern on my side (wrong dub ecosystem usage) and I'm eager to fix my antipatterns as I learn more. But still, a mismatch error would have lessened the impact.

dub prints a lot even when things go well (dependency x.y.z is up to date), thus people like to ignore dub output (even if it has a warning) once colorful compiler errors bury the dub output.