Feedback on `cps-query`

[bretbrownjr]

Overview

I'd like to start development on a proof-of-concept tool for interacting with CPS JSON files. I think cps-query is a good name for the tool, but I'm open to better ideas.

Background

There is widespread interest in this project, and with it some amount of desire to help out or try it out in some way. I expect there will be some waiting involved until CMake provides a practically useful implementation, so I would like to see some open source friendly way to use CPS data in interesting ways. I think a cps-query tool could be the simplest useful tool possible. I think it could function as a minimal viable product of sorts.

I expect if the cps-query tool gets significant community engagement, we'll also see interesting iteration and advancement on CPS itself. For instance, I think interface manifests could be justified and added fairly soon if a cps-query validated that declared interfaces actually existed in expected locations.

Similarly, I could see cps-query being a initial test bed for exploring support for Software Bills of Materials, which would also require enhancements to CPS itself.

Scope

For inspiration, the pkgconf program provides a superset of the behavior of pkg-config. Many are quality-of-life features. Top-level use cases that stand out as useful for a cps-query tool include (probably not in order):

• --list-all: list all known packages
• --list-package-names: list all known package names
• --simulate: simulate walking the calculated dependency graph
• --exists: check whether or not a module exists
• --uninstalled: check whether or not an uninstalled module will be used
• --no-provides: do not use 'provides' rules to resolve dependencies
• --maximum-traverse-depth: maximum allowed depth for dependency graph
• --cflags: print required CFLAGS to stdout
• --libs: print required linker flags to stdout
• --digraph: print entire dependency graph in graphviz 'dot' format
• --solution: print dependency graph solution in a simple format
• --path: show the exact filenames for any matching .pc files

Of course, there are other features to consider for manipulating paths, overriding CPS metadata, version manipulation, ignoring conflicts, validating JSON files comply with CPS, validating the dependency graph is acyclic, and so on.

Note that some of these behaviors, properly-spelled, could set up cps-query to be a drop-in replacement for pkg-config on POSIX systems, with a few large assumptions about foobar.pc having analogous foo.cps files and/or cps-query having sufficient ability to understand foobar.pc files directly. I expect some sort of CLI tool will be required for projects that want to help manage dependencies in simple ways, possibly including simple build systems like Makefiles and tools like Compiler Explorer.

Needs

Mechanically, I think we mostly need a new repo in cps-org. Practically, we'll also need a certain amount of interest and contribution from others to make that project viable.

Next Steps

I will be discussing this idea interactively at the next C++ Ecosystem Evolution meeting, especially because establishing interest and consensus is a good fit for interactive discussions. I'm also posting the idea here to invite everyone else to consider the idea and consider contributing.

Anyone interested in participating in a cps-query project, please reach out or even comment on this issue.

[dcbaker]

I have been working on such a tool, I'd be happy to talk about it at the next C++EE meeting :)

[bretbrownjr]

@dcbaker I'm barely started. If you have anything useful to demo, some thoughtful design docs, or a development roadmap (what's v0.1? what's v1.0?), that would be great. Right now, I'm looking for critical mass to make another repo and give people a place to roll up their sleeves with PRs and such.

[dcbaker]

@bretbrownjr I have enough to do some basic lookup and print various kinds of flags. It’s all very “move fast and break things”, but I definitely have enough to demo

[dcbaker]

https://github.com/dcbaker/cps-config

[dcbaker]

I've opened issue for most of the above points on the cps-config repo. The ones I didn't:

• --no-provides: pkgconf has an extension that allows you to add Provides: zlib to a pkg-config file, which is useful for re-implementations. CPS currently doesn't have an equivalent feature.
• --uninstalled: pkg-config allows a zlib-uninstalled.pc to be generated and put into the build directory at build time, which is meant to allow build systems invoking other build systems to find their outputs at build time. We could implement this, but it would mean committing to a similar system

[bretbrownjr]

I think that's fair. Let's focus on implementing the current design and getting to an MVP.

[mwoehlke]

--uninstalled: pkg-config allows a zlib-uninstalled.pc to be generated and put into the build directory at build time, which is meant to allow build systems invoking other build systems to find their outputs at build time. We could implement this, but it would mean committing to a similar system.

You can already generate e.g. zlib.cps in zlib's build tree that refers to said build tree. (In order to consume this, however, you'll almost certainly need to tell the tool to look in that specific directory.)

I'm not sure what "check whether or not an uninstalled module will be used" is intended to mean. I'll also note that an "uninstalled" package can be almost indistinguishable from an installed package, and there are even edge cases such as /opt; if I happen to use /opt/zlib as my build tree, and it happens to have the layout of an install tree, is that "installed" or not?

[bretbrownjr]

If nobody is currently proposing an "uninstalled" feature, I think we can leave it alone.

Otherwise, seems like it deserves a separate thread to discuss.

[bretbrownjr]

For clarity and posterity, I'm summarize what we discussed on this topic in the C++ Ecosystem Evolution meeting yesterday.

We have agreement to invest in cps-config going forward. We'll move cps-config to cps-org to make it easier to share and productively collaborate on.

We also agreed that we're OK adding functionality to cps-config that aren't currently in the feature list for pkg-config but would be helpful in bootstrapping a CPS ecosystem and/or would be useful for developers, package maintainers, and system maintainers now and in the future.

[dcbaker]

I think with cps-config in the cps org, we're good to close this issue and move any additional concerns to that repo?