"-C" flag results in inconsistent relative path handling #1879
Comments
DaanDeMeyer
added a commit
to DaanDeMeyer/mkosi
that referenced
this issue
Sep 7, 2023
DaanDeMeyer
added a commit
to DaanDeMeyer/mkosi
that referenced
this issue
Sep 7, 2023
DaanDeMeyer
added a commit
to DaanDeMeyer/mkosi
that referenced
this issue
Sep 7, 2023
behrmann
pushed a commit
that referenced
this issue
Sep 7, 2023
gdiscry
added a commit
to gdiscry/mkosi
that referenced
this issue
Sep 25, 2023
Common utilities (e.g., make and tar) that have a `-C`/`--directory` option immediately change the working directory when that option is parsed, with the following properties: - the option is order sensitive and only applies to the following options - the option can be used multiple times and each is interpreted relative to the previous one In addition, mkosi uses an empty path for `-C`/`--directory` to indicate that the configuration files in the current directory should be ignored. At first, mkosi would call `os.chdir()` after parsing the command-line arguments, so the following options with relative paths would resolve relative to the initial working directory and not the new one. This issue was reported in systemd#1879. The fix in systemd#1880 reversed that approach. A first (and lighter) pass on the command-line arguments would get the last `-C`/`--directory` and call `os.chdir()`. Afterwards, all the command-line arguments were fully parsed so that the relative paths would resolve to that directory. Neither approach implements the properties above. Only the last value is used and applies to none/all of the command-line arguments. By calling `os.chdir()` as the options are parsed, both properties are respected and the arguments can be parsed in a single-pass. The resulting directory is still tracked in `args.directory` but as a `Path` object defaulting to `Path.cwd()`, with `None` indicating that the configuration files should be ignored. Furthermore, it's now possible to call `mkosi -C <dir> -C ''` to work in a given directory (for the output and workspace) while also ignoring the configuration files present in that directory.
DaanDeMeyer
pushed a commit
that referenced
this issue
Sep 25, 2023
Common utilities (e.g., make and tar) that have a `-C`/`--directory` option immediately change the working directory when that option is parsed, with the following properties: - the option is order sensitive and only applies to the following options - the option can be used multiple times and each is interpreted relative to the previous one In addition, mkosi uses an empty path for `-C`/`--directory` to indicate that the configuration files in the current directory should be ignored. At first, mkosi would call `os.chdir()` after parsing the command-line arguments, so the following options with relative paths would resolve relative to the initial working directory and not the new one. This issue was reported in #1879. The fix in #1880 reversed that approach. A first (and lighter) pass on the command-line arguments would get the last `-C`/`--directory` and call `os.chdir()`. Afterwards, all the command-line arguments were fully parsed so that the relative paths would resolve to that directory. Neither approach implements the properties above. Only the last value is used and applies to none/all of the command-line arguments. By calling `os.chdir()` as the options are parsed, both properties are respected and the arguments can be parsed in a single-pass. The resulting directory is still tracked in `args.directory` but as a `Path` object defaulting to `Path.cwd()`, with `None` indicating that the configuration files should be ignored. Furthermore, it's now possible to call `mkosi -C <dir> -C ''` to work in a given directory (for the output and workspace) while also ignoring the configuration files present in that directory.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using the
-Cflag, most flags that take paths resolve relative paths early (before performing theos.chdir).However, when using the
--packageflag and providing a local package (like./foo.rpm), the path is relative to the directory afteros.chdir.I see that this might be difficult to get consistent (especially since the
--packageexpression is just forwarded to the package manager as a str), but I wonder if it makes sense to make all paths relative to the result ofos.chdirfor consistency.The text was updated successfully, but these errors were encountered: