Consistently support specifying lockfiles when required names are not imposed by an external package manager

[arewm]

I am trying to prefetch a generic artifact with a given lockfile: https://github.com/konflux-ci/bazel-builder/blob/main/bazel6-ubi9/generic_lockfile.yaml

When I tried to specify the lockfile within the path as I can do with pip, I encountered an error.

2024-12-02 17:42:20,524 ERROR PackageRejected: Supplied generic lockfile path 'generic_lockfile.yaml' is not absolute, refusing to continue.
Error: PackageRejected: Supplied generic lockfile path 'generic_lockfile.yaml' is not absolute, refusing to continue.
  Make sure the supplied path to the generic lockfile is absolute.

I do not know the absolute path for this file as it is dependent upon the execution environment in which I am running cachi2.

If a lockfile naming convention is not imposed by an external package manager, Cachi2 should allow users to modify the name with relative (and potentially absolute if required) paths. This includes package managers like generic and pip.

[eskultety]

TL;DR: you don't need any workaround, the name of the file is incorrect, should be artifacts.lock.yaml.

Long version:
Looking at the sample repo, the lockfile is already present in the application top-level directory, so no path is needed and the lockfile is going to be recognized automatically. The problem here is the name of the file. That sample repository you have was created before official support for the generic backend was rolled out, but did not catch up - the default name of the lockfile is artifacts.lock.yaml and not generic_lockfile.yaml.

The generic package manager should support relative paths to the lockfiles within the context of the path parameter. This is consistent with other package manager support in Cachi2.

What other package managers that this is consistent with are you referring to? I'm asking because pip is the only other pkg mgr backend we have that lets you pass requirements files as relative paths, we don't support this with Yarn (v1/v2), Bundler, NPM, or Go, so either they're all inconsistent or these 2 are legitimately special in a way, but still inconsistent in a different way - one allowing relative paths only with the other mandating absolute paths :).

That said, while hosting the manifest files at a different relative location wrt/ to the application inside the repository may not be aligned with good/recommended practices encouraged by other well known and established pkg mgr ecosystems we support, I agree that once we support accepting a path, we need to be able to deal with both absolute and relative paths.

@arewm can you generalize the issue subject & description such that this is more about being consistent in input path handling by the project in general (listing pip and generic as the examples that are inconsistent) rather than being specific to a particular backend example?

[arewm]

TL;DR: you don't need any workaround, the name of the file is incorrect, should be artifacts.lock.yaml.

Right, I resolved the issue on my end by renaming the file. I'll nitpick that a workaround was necessary because my intended flow wasn't supported ... that workaround was just renaming the file. I didn't want to do that because the file name is not anything that is imposed by any other tooling that I was using (i.e. a package manager). I encountered this issue when updating the version of Cachi2 used as it looks like the file name used to be happily accepted.

I was just thinking of pip as you said. I believe that this is because there is no requirement for lockfile naming imposed upon the dependency fetching tooling. For pip, any file name will work as you just pass that file to the install command.