Skip to content
C.W.K.
Stream
Lesson 01 of 04 · published

The Obvious Answer, and Why Not

~12 min · packaging, distribution, trade-offs, decision

Level 0Loose Parts
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

What a Package Is Actually For

Publish the shared layer, pin a version in each consumer, upgrade on your own schedule. This is not a bad answer — it is the correct answer to a real problem, and it is worth naming that problem precisely before declining it. A package sells isolation across time and space:

  • Across space — consumers you do not control, on machines you cannot reach, possibly in organizations you have never met.
  • Across time — a consumer that must keep working while the shared code moves on, and needs a known-good revision to stand on until it is ready.

Both are enormously valuable when you have them. The question is whether you have them.

What This Family Actually Is

A handful of private repositories, all owned by one person, all checked out on the same machine, all running as loopback siblings that talk to each other over localhost, and all deployed in the same window. There are no external consumers. There is no consumer who upgrades on a different schedule. There is no version skew to protect against — and, crucially, version skew is the thing this repository exists to eliminate. The whole point of giving the shared layer one owner was that two copies must never disagree.

Against that, a package buys nothing and charges for several things: a publish step inserted into every change, a version number that has to be reasoned about and bumped, a lockfile that can be stale, an install ceremony for anyone setting up a fresh checkout, and the possibility — now made legitimate by the version pin — of two consumers deliberately running different code. The last one is the sharpest. A package does not just permit skew; it makes skew a supported feature.

Buy isolation only when you have something to isolate from. Versioning, pinning, and semantic-version discipline exist to protect a consumer from a producer who is out of reach. When the producer is you, the consumer is you, the machine is the same machine, and the deploy is one window, that protection has no counterparty. You are paying a real premium against a risk that structurally cannot occur.

The Honest Caveat

Every sentence above depends on the size and shape of this family. At a company, with several teams, separate deploy pipelines, and consumers who genuinely cannot all be updated at once, the analysis inverts and a package becomes correct — not as a matter of taste, but because the isolation is suddenly real.

Which is exactly why this is a decision and not a doctrine. The next lessons cover how the copies are actually delivered and checked, and the last one covers the discipline that keeps this honest: writing down, at the moment of choosing, what would have to become true for the choice to be wrong.

Code

The same shared module, delivered three ways·text
PACKAGE                          GIT SUBMODULE            VENDORED COPY
-------                          -------------            -------------
kit v1.4.2 on a registry         kit repo pinned at a     kit file copied into
                                 commit inside each       each consumer's tree
                                 consumer

consumer A: kit==1.4.2           consumer A: @ a1b2c3     consumer A: kit_pippa.py
consumer B: kit==1.3.0  <- skew  consumer B: @ 9f8e7d     consumer B: kit_pippa.py
                        is a                <- skew is                 <- skew is
                        FEATURE                 a FEATURE                 a BUG,
                                                                          and a test
                                                                          fails on it

to change shared code:           to change shared code:   to change shared code:
  edit -> test -> version          edit -> commit ->        edit -> test ->
  -> publish -> bump each          bump each consumer's     run deploy script
  consumer -> reinstall            pointer -> init/update   -> commit each consumer

fresh checkout works?            fresh checkout works?    fresh checkout works?
  only after install               only after submodule     YES, immediately
                                   init                     (the files are there)

change visible in consumer       change visible in        change visible in
diff?  NO (version number)       diff?  NO (a sha)        diff?  YES (the code)

External links

Exercise

For one shared library you currently consume as a package, answer three questions in writing: who are the consumers you cannot reach, which consumer is on a different version right now, and what would break if every consumer were forced onto the same revision today. If all three answers are 'none' and 'nothing', you are paying for isolation you do not have a counterparty for.
Hint
The third question is the load-bearing one. If forcing everyone onto one revision would break something, the version pin is doing real work and you should keep it. If it would not, the pin is documentation of a fear rather than protection against a risk.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.