I guess you already considered using a git subtree instead?

does that work with tools deps?

If tools.deps supports regular git checkouts then yes.

It seems that comes with its own set of trade-offs • Contributing code back upstream for the sub-projects is slightly more complicated. • The responsibility of not mixing super and sub-project code in commits lies with you.

It seems git subtrees are newer than submodules?

So the main decision factors are like: • Use subtree when you just want to copy code from an external repo once, or maybe with occasional pulls. • Use submodule when you want to make your relationship to the external repo really explicit, or if you intend to make changes to the submodule code from within the context of your repo and push to the external repo.

(copied from an article)

since the goal is to change the code in the sub-dependency, I think subtrees won't solve it, but it's good to know that it might work with tools-deps

Ah ok, I haven't used subtrees myself. I thought it was possible to push code back up to the original repo without too much trouble.

Yeah, one issue I'm also having is that the code changes to the subtree must be tested but this currently isn't possible without using either squint or cherry

I don't know too much about tools.deps but with Node and packages.json you can configure things to be run at different stages during install. If tools.deps had a facility like that you could run the git submodules init post install.

I think the same is true in Python's setup.py.

tools deps does have a thing like that, it's called prep-deps. yeah, that could also work, hadn't thought of that

https://clojure.org/guides/deps_and_cli#prep_libs

I guess you could "abuse" that to pull the git submodule, although I wonder how you would ensure the right version since this only runs on missing files