📝Interface is second-class for package managers

When developers code against some library, it is interface they are relying on (both explicit and Implicit interface).

However, most package managers operate on package names, versions, and version constraints, not interface. The interface is second-class and is approximated by version numbers—Version numbers version package interface as a whole.

However, this does not cover all cases and has some shortcomings:

• There can be compatible dependencies even though they use different name/version (think of forking a dependency and fixing a bug there)—Version number communicates version of the interface and of its implementation

• A major version bump does not imply incompatibility

Some package managers allow overriding packages ignoring all constraints (e.g., pulling a package from a github fork, renaming packages, or overriding a version). This is a manual intervention required to fix the above shortcomings.

See also

• It is interesting to imagine how first-class interfaces in the package manager could look like: Packages could declare their dependencies’ interface instead of version constraint.

Backlinks

• 📝 § Package management and versioning
• 📝 Dependencies’ version constraints require additional maintenance work
• 📝 Packages could declare their dependencies’ interface instead of version constraint
• 📝 Package managers are dependency injection mechanisms