many: force-repo-dir instead of force-data-dir

[supakeen]

Previously I deprecated data-dir and renamed it to force-data-dir to have consistent naming for options that overwrite internal state instead of appending to it (arguments that start with force- are overwrites, arguments that start with extra- are merges).

With force-data-dir we require a repositories sub directory. After some discussion we came to the idea to instead of enforcing a directory layout on the user we want to be able to point directly at a directory of repositories.

This commit deprecates force-data-dir and introduces force-repo-dir. Both write to the same internal variable.

We also allow repository files to live either in a repositories subdirectory to keep backwards compatibility for any of the arguments or to live directly at the top level of the passed directory.

We show a deprecation warning if a repositories sub directory exists and inform users that the repositories subdirectory will not be wanted in the future and how to resolve the emitted warning.

This option will be used together with the future introduction of force-defs-dir to handle definitions (and its extra-defs-dir counter part) unifying all options into a consistent naming scheme.

[supakeen]

Since we had some previous discussion about not growing too many arguments; this will (eventually, we need to decide a timeline) be the only argument left over. data-dir and force-data-dir are deprecated.

This also more importantly unifies the naming of arguments to be force-* for anything fully overriding builtins, and extra- for anything merging with builtins.

This also reintroduces the ability to load repositories directly from the root of the passed force-repo-dir; in the future the only option as enforcing this subdirectory layout on users is something we probably don't want to do.

We'll need to establish a timeframe for this.

[thozza]

I accidentally approved the PR, while there are still comments that I wanted to be addressed. Although I can't remove the approval, also don't want to formally request changes. Since the branch has conflicts, it can't be merged as is anyway, so this is all good from my PoV. Sorry for the noise.

[lzap]

Very long warning, three lines on 80x25 terminal, this will be quite effective. :D

I am wondering why you used backtics and single quotes is that some kind of standard or convention in CLI? I would probably use %q for both to save keystrokes.

[supakeen]

Very long warning, three lines on 80x25 terminal, this will be quite effective. :D

I am wondering why you used backtics and single quotes is that some kind of standard or convention in CLI? I would probably use %q for both to save keystrokes.

I think it's partial markdown and partial representation of strings (in Python).

[achilleas-k]

Throwing a tiny spanner in the works here after all this time but:

The description of every --force-... option begins with Override .... Wouldn't --override-... be a better name for the options? Character count is one reason to go with force, I suppose, but I also don't know if force is a good term here. It doesn't align with the general use of --force / -f as a clarg in my mind.

[supakeen]

Throwing a tiny spanner in the works here after all this time but:

The description of every --force-... option begins with Override .... Wouldn't --override-... be a better name for the options? Character count is one reason to go with force, I suppose, but I also don't know if force is a good term here. It doesn't align with the general use of --force / -f as a clarg in my mind.

I don't know, force is what we've used and is being used by the koji plugin/other places at the moment so I'm not super enticed to rename it to override everywhere without having a bit more of a compatibility timeline in place :) To me it's a clear term but I can see that names are difficult (force- and extra-).

[thozza]

Thanks, LGTM