2 ms·

The "Dependency Cutout" Workflow Pattern

19 points by ingve 1y ago

a_t48 1y 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 1y ago
  Does Python ecosystem have a patch-package equivalent? https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package
TekMol 1y 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 1y 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 1y 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.

19 points by ingve 1y 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 1y ago
Does Python ecosystem have a patch-package equivalent? https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package

TekMol 1y 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 1y 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 1y 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.