lib/path: allow CA paths in hasStorePathPrefix (#386774)

    # but this is not fully specified, so let's tie this too much to the currently implemented concept of store paths.

    # Similar reasoning applies to the validity of the name part.

    # We care more about discerning store path-ness on realistic values. Making it airtight would be fragile and slow.

    && match ".{32}-.+" (elemAt components storeDirLength) != null;

    && match ".{32}-.+" (elemAt components storeDirLength) != null

    # alternatively match content‐addressed derivations, which _currently_ do

    # not have a store directory prefix.

    # This is a workaround for https://github.com/NixOS/nix/issues/12361 which

    # was needed during the experimental phase of ca-derivations and should be

    # removed once the issue has been resolved.

    || match "[0-9a-z]{52}" (head components) != null;

in

# No rec! Add dependencies on this file at the top.

      expected = true;

    };

    # Test paths for content‐addressed derivations

    testHasStorePathPrefixExample7 = {

      expr = hasStorePathPrefix (/. + "/1121rp0gvr1qya7hvy925g5kjwg66acz6sn1ra1hca09f1z5dsab");

      expected = true;

    };

    testHasStorePathPrefixExample8 = {

      expr = hasStorePathPrefix (/. + "/1121rp0gvr1qya7hvy925g5kjwg66acz6sn1ra1hca09f1z5dsab/foo/bar");

      expected = true;

    };

    # Test examples from the lib.path.subpath.isValid documentation

    testSubpathIsValidExample1 = {

      expr = subpath.isValid null;