CLI Design Discussion #84
Comments
|
@dcbaker @tylerjw @bretbrownjr I'm planning to start implementing some actual features but I feel it could be beneficial to have a brief discussion on what kind of interface, on a high level, that we would want to work towards |
|
I like this idea! |
|
I like this idea too. To go further we might eventually consider doing the |
|
I am happy to participate. Let me know how I can help. |
|
I imagine something like #70 would be crucial to making this happen. Based on that we could also talk about what we consider the first release of cps-config, maybe an interesting level of compatibility with pkg-config for all libraries available on ubuntu? |
lunacd
added a commit
to lunacd/cps-config
that referenced
this issue
Jun 23, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in cps-org#84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and cps-org#84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in cps-org#70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
lunacd
added a commit
to lunacd/cps-config
that referenced
this issue
Jun 26, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in cps-org#84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and cps-org#84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in cps-org#70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
lunacd
added a commit
to lunacd/cps-config
that referenced
this issue
Jun 26, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in cps-org#84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and cps-org#84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in cps-org#70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
lunacd
added a commit
to lunacd/cps-config
that referenced
this issue
Jun 26, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in cps-org#84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and cps-org#84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in cps-org#70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
bretbrownjr
pushed a commit
that referenced
this issue
Jul 8, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in #84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and #84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in #70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
|
Closing as this has already been implemented and merged |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current State
Currently all options are implemented at the top level, no matter they are from
pkgconf,pkg-configor specific to CPS. This could mean a chaotic command line interface as we implement more and more features. This could also lead to a hard situation where we had to break compatibility withpkgconforpkg-configif we want to add CPS-specific capabilities to ones of the options provided by them.Proposal
Provide compatibility through subcommands, i.e.
cps-config pkgconfshould behave in the same waypkgconfbehaves, and the same goes forcps-config pkg-config. Everything else outside of those two subcommands are purely CPS-specific territory.Benefits
cps-configas a drop-in replacement forpkgconfandpkg-config. We could even aim for a situation where people can aliaspkg-configtocps-config pkg-configand expect things to still work.cps-configfall back to the other tools when used in "compatibility mode" but CPS files are not available.The text was updated successfully, but these errors were encountered: