The "dependency Cutout" Workflow Pattern

Postedabout 2 months agoActiveabout 2 months ago

ingve

18 points

5 comments

blog.glyph.imTechstory

calmpositive

Debate

20/100

Software DevelopmentDependency ManagementWorkflow Patterns

Key topics

Software Development

Dependency Management

Workflow Patterns

The 'Dependency Cutout' workflow pattern discusses managing dependencies when a bug is found in a third-party library, with commenters sharing their approaches to handling such situations.

Snapshot generated from the HN discussion

Discussion Activity

Light discussion

First comment

Peak period

6-7h

Avg / period

1.3

Key moments

01Story posted
Nov 11, 2025 at 2:34 AM EST
about 2 months ago
Step 01
02First comment
Nov 11, 2025 at 6:33 AM EST
4h after posting
Step 02
03Peak activity
2 comments in 6-7h
Hottest window of the conversation
Step 03
04Latest activity
Nov 11, 2025 at 9:00 AM EST
about 2 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (5 comments)

Showing 5 comments

a_t48

about 2 months ago

1 reply

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

about 2 months ago

Does Python ecosystem have a patch-package equivalent?

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

JackSlateur

about 2 months ago

1 reply

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

about 2 months 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.

TekMol

about 2 months 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.

View full discussion on Hacker News

ID: 45884951Type: storyLast synced: 11/20/2025, 1:39:00 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN