- Fork LibBar on Github, apply patch
- In docker stage build-bar:
- RUN git clone gh.com/my_org/bar
- WORKDIR bar/build
- RUN cmake .. -DCMAKE_BUILD_TYPE=Release (old habits die hard, need to remember to use -B)
- RUN make -j
- in main docker stage: --mount from=bar,src=bar/build,target=/tmp/bar make install
...and that's it. A little bit of wastage if I had to install over the top of some apt install but oh well. If I contributed back to upstream, or they fix independently, gravy - remove the extra build. This doesn't work as well for python or js, of course, and doesn't "solve" pulling in upstream regularly, but I usually don't need to. Benefits of not usually working on internet facing software, I suppose.
The python case is thankfully usually not terrible nowadays (clone, `uv build`, push to artifact registry), modulo needing to pass whatever flag to uv to let it take into account both my private registry and public pypi at the same time.
I guess it's a technicality because the original option #2 is permanent, while the proposed solution is theoretically temporary (IME this approach will end up being permanent too based on how many companies operate). I actually think more companies should do this pre-emptively; it's very little extra work on the happy path (i.e. 1:1 with upstream) and you're ready to go when you need to deviate or fix and gives you better isolated supply management for your dependencies.
I am using Git submodules for dependencies. My approach to a situation like this:
And keep using my fork until upstream accepted my pull request. Then I switch the url of the dependency back.For me it usually looks like:
...and that's it. A little bit of wastage if I had to install over the top of some apt install but oh well. If I contributed back to upstream, or they fix independently, gravy - remove the extra build. This doesn't work as well for python or js, of course, and doesn't "solve" pulling in upstream regularly, but I usually don't need to. Benefits of not usually working on internet facing software, I suppose.The python case is thankfully usually not terrible nowadays (clone, `uv build`, push to artifact registry), modulo needing to pass whatever flag to uv to let it take into account both my private registry and public pypi at the same time.
Does Python ecosystem have a patch-package equivalent?
https://www.npmjs.com/package/patch-package
tldr: create a fork, fix the fork, use the fork. When upstream is fixed, remove your fork.
It thought that this was option #2 but apparently no
I guess it's a technicality because the original option #2 is permanent, while the proposed solution is theoretically temporary (IME this approach will end up being permanent too based on how many companies operate). I actually think more companies should do this pre-emptively; it's very little extra work on the happy path (i.e. 1:1 with upstream) and you're ready to go when you need to deviate or fix and gives you better isolated supply management for your dependencies.