The "Dependency Cutout" Workflow Pattern

https://blog.glyph.im/2025/11/dependency-cutout-workflow-pattern.html

19•ingve•2mo ago

Comments

a_t48•2mo ago

For me it usually looks like:

    - 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.

aitchnyu•2mo ago

Does Python ecosystem have a patch-package equivalent?

https://www.npmjs.com/package/patch-package

TekMol•2mo ago

I am using Git submodules for dependencies. My approach to a situation like this:

    1: Clone gh.com/someone/LibBar to gh.com/me/LibBar
    2: Fix the bug
    3: Send pull request to someone
    5: git submodule set-url lib/LibBar https://gh.com/me/LibBar.git
       git submodule sync lib/LibBar
       git submodule update --init --remote --recursive lib/LibBar
       cd lib/LibBar/; git checkout main; cd ../..
       git add .; git commit -m "Use my own version of lib/LibBar"

And keep using my fork until upstream accepted my pull request. Then I switch the url of the dependency back.

JackSlateur•2mo ago

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

skeeter2020•2mo ago

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.