The time I had to put towards development this month was primarily spent updating libpkmn and its dependencies so that it can be built again. As such, it’s probably worth taking some time to expand a little on dependencies and staying up-to-date in general.

pkmn follows the philosophy of attempting to rely on an absolute minimum number of external (non-pkmn) dependencies at runtime (usually zero). Minimizing dependencies is a pragmatic choice – it offers more control, avoids versioning hell, simplifies installation for downstream users, and results in less maintenance due to churn around updates. Often the core ~100-300 lines one needs/wants from a dependency can be more simply copied into the project and maintained along the rest of the project’s code. There are notable instances where one might consider taking on a dependency – circumstances where the functionality offered by the dependency is large and more orthogonal to one’s project, or circumstances where updates to the dependency are driven by external factors (e.g., a date library that needs to stay on up-to-date with changes to time zones arising due to politics).

Dependencies that only exist at compile-time (in particular, development tools) are somewhat easier to stomach, primarily because they are effectively nonexistent as far as downstream users are concerned. However, the drawbacks of dependencies still apply, in particular with respect to keeping them up-to-date. Ostensibly, newer versions of dependencies should provide bug fixes (most importantly security fixes) and potentially new, useful features. In reality, modern open source software does not seem to value stability and updates frequently break existing patterns.

One solution is to rarely update dependencies, though this comes with several drawbacks:

  1. The work to update from version A to version Z almost always includes all of the same changes that are required to go from A to B, B to CY to Z. However, figuring out the whole set of changes to go from A to Z is often less clear than the smaller sets of changes that are required to go between each intermediate version.
  2. It is generally more difficult for users to find old versions of dependencies compared to the latest versions, meaning that keeping a project up-to-date with the versions most convenient to users improves the new user experience.
  3. While rarer, sometimes dependency versions will include an important fix, and simply always staying up-to-date means it’s somewhat less important to thoroughly scrutinize which versions are critical to update to.

Finally, pkmn tries to use the latest versions of its dependencies to test out changes and provide feedback. Filing good bug reports on nightly builds is a great way to contribute to the open source community and helps ensure regressions get caught and addressed.