Dependency source version override

Help
1

I’m seeing a recurring pattern that some programs which require an older version of a dependency use a pattern like:

    jinja2 = super.jinja2.overridePythonAttrs (oldAttrs: rec {
      version = "2.11.3";
      src = oldAttrs.src.override {
        inherit version;
        sha256 = "a6d58433de0ae800347cab1fa3043cebbabe8baa9d29e668f1c768cb87a333c6";
      };
    });

Essentially still including the derivation for the most recent version in Nixpkgs, but then replacing the source of that derivation with the old version. The given approach seems to have an issue if the derivation changes in a way that is incompatible with the old source version. Also, this does not need to happen immediately. Since we always use the dependency version currently in Nixpkgs and replacing the sources, such a failure could happen in the future as well.

In contrast, keeping several versions of a dependency in Nixpkgs or completely vendoring the old dependency (e.g. by copying the whole derivation along the package requiring the old version) seems to be rarely done and frowned upon, even though it seems to be cleaner to me.

Is this “updated derivation breaks building with old source” just happening so rarely in practice, that this is still considered the better solution?

1 Like
2

Interesting observation!

Not sure how to answer your exact question, as I never got in the situation you described - so, tentatively, yes; maybe we’re to early in history for this to happen a significant number of times.

In my world either the base nixpkgs is pinned and that risk is pushed far into the future until a major update round, where stuff is expected to break anyway. Or otherwise I pick the old package version directly from an old version of nixpkgs, which is useful if the current one indeed does not build with an overridden source. In the second case your issue will not occur, since that old version is pinned forever until one wants to update the package in question.