cabal build does not rebuild source-repository deps that changed upstream

[andreasabel]

I observed the following:

1. In cabal.project, depend on an upstream git repo, with tag omitted (so, depend on the master branch).
2. Call cabal build. I my case this failed because an upstream type error.
3. Push a commit to upstream master (that fixes the type error).
4. Call cabal build again. It fails with the same error.

So, it seems that cabal's caching logic does not take upstream changes into account if the tag didn't change.
Modifying the cabal.project file with putting in tag: <commithash> then triggered the rebuild (and succeeded).

[Mikolaj]

Does it mean the semantics is "take the specified tag; if not specified, take the last used commit hash; if not present, set the last used commit hash to the master branch HEAD hash at this very moment"? And you'd prefer to cut out the middle part and have "if not specified, behave as if it's the first use"? That seems simpler, so perhaps there are use cases when it's convenient to stick to the last used tag, even if not specified? Should we have an option that picks on of the two behaviours?

[andreasabel]

Yes, exactly.
I think if you want to pin to a specific commit, you should give hash in the tag field. This is what I would expect.
If the tag is something that resolved dynamically, like HEAD or a git tag, then it should be resolved each time that I run cabal build.

I observed that going from no tag to tag: HEAD triggered a pull in the repo. But I would have expected that this is a no-op, and pull always happens for such dynamic tags.

[fgaz]

I think it's better to keep the already fetched commit by default, or no-op cabal build would become incredibly slow. It could be configurable though, and/or we could add a timeout field

I'm not sure adding support for "dynamic tags" is a good idea since they are vcs-specific

[andreasabel]

Maybe then there should be command (in analogy to cabal update) that updates the source-repositories.
Currently, you have to do tricks, like touching the tag field. In case of tag: HEAD, one can alternate between having this tag and deleting it...

[fgaz]

I think the best way is to just use the commit sha, so it's also reproducible

[andreasabel]

I think the best way is to just use the commit sha, so it's also reproducible

Well this is what you want in some use cases. But this would be the analogue of "freeze", pinning your dependencies to an exact version (stack allows to pin even the revision).

In other cases you might want to follow the upstream developments. If I omit the tag or set it to HEAD, this is definitely my intention.

[jneira]

hmm, sure you all know but for completeness, cabal clean will force a checkout of all remote repo source packages.
Maybe adding targets to clean (there is an issue about) would help to make the workaround a little bit more convenient.

[jneira]

Maybe then there should be command (in analogy to cabal update) that updates the source-repositories.

no new commands please, we should removing them instead adding them :-P
maybe a flag to cabal update?

[andreasabel]

Maybe a flag to cabal build? Cabal update is about the package repo, is it?

[jneira]

yeah, a build (and other commands?) flag would be better
completing again another workaround could be a script which visits all remote source repos inside disthnewstyle and call the appropriate git command to update them

[andreasabel]

call the appropriate git command to update them

If I remember correctly, this was not enough to trigger a rebuild. Cabal still used its build artefacts that were no longer in sync with the HEAD of the repo.