What is the most practical way to express a dependency on a library for which we have a local git repository with some changes?

The usecase is that I'm having a really hard time testing a fix submitted with Xmobar 0.47.4¹.

I think the reason is that my .cabal file

executable xmobar
  build-depends: base
               , xmobar

is resulting in picking up 0.47.3, I think because that's the highest tag in the repo at the moment. Indeed,

if I append >= 0.47.3 to the last line above, cabal building works,
but if I append > 0.47.3, then cabal build fails because no version satisfies the constraint.

Now, I could obviously ask the author "can you please push the tag too?" (assuming that is enough for cabal build to find that new version), but I would like to take this difficulty as an opportunity to learn more about Cabal.

Can I express a dependency on a specific commit in an online repository?

This would allow me to use latest changes that have no tag attached, or that are not on the main branch.
Even better, can I express "the library is not online, but it's at /home/me/where/I/downloaded/the/repo

This, even better, would allow me to easily test local changes to somebody else's repo.

(¹) When using xmobar as a library and with a cabal project around it to allow seamless integration with xmonad (i.e. recompile one recompiles the other, changing either .hs config is picked up when recompiling, and so on; see here for more details). If I ditch all my setup and leave around only my ~/.config/xmobar/xmobar.hs and cabal install from the local copy of xmobar's repo with the most recent commit checked out, I can see the fix.

Solution

The .cabal file is not the right place for specifying such information: it is associated with a state of the code repository, and shouldn't rely on the presence of any local checkout of other stuff.

Instead, you should put the path to the local install in a cabal.project file, namely (in the same directory as your own .cabal file):

packages: . /home/me/where/I/downloaded/the/repo/Xmobar

Then, when you run any cabal command it will know to use the local version of Xmobar instead of any version currently on Hackage. You can then use the > 0.47.3 constraint in the .cabal file, and only

If only you are working on this project currently, you can simply commit only the > 0.47.3 dependency to your own Git and keep the local version of Xmobar and the cabal.project file un-added. It will then be un-compileable for others, but become compileable as soon as Xmobar pushes a new version to Hackage.

Alternatively, you can include your forked Xmobar as a Git submodule into your repo, and add the cabal.project file referring to it. Then anybody can check out both your repo and the patched submodule, to build them together.