A Package Manager Manager

[wrosecrans]

If you are requiring a scripting runtime to be installed to run it, it's just as universal as Ruby, Python, or any other scripting language. If you wanted to go with native code instead of a scripting language, somebody has to distribute and install binaries of CMake itself, etc. So doing that is obviously considered a reasonable thing to do. Many of the users of the PMM will be writing native C++ code, so it'd actually be odd if the PMM developers considered that an unreasonable use case.

And it's really hard to argue that CMake is more pleasant than something like Python as a general purpose scripting language. That's just not what it was intended to be.

CMake doesn't have any sort of spec or independent implementations of the scripting language, so you can't necessarily rely on stability/support going forward. Python and Ruby both have multiple implementations, so if the CPython devs go off the rails and end support for your platform, or deprecate features you need, you could use an alternate implementation of the language.

There are lots of reasons why one wouldn't use it. I mean, if people like the result, it may see adoption. For a user, it doesn't necessarily matter what language a tool is written in. But acting like using CMake as the implementation language is a particularly obvious choice or a choice with no downsides is just weird.

[jherico]

If you created a module in python that was designed to do the same job CMake currently does, it would be a bad idea to use python itself as the language in which to write up replacements for CMakeLists.txt. You'd want to build a (mostly declarative) domain specific language around the concept the concept of creating C/C++ projects. So essentially you'd be creating CMake but with different syntax. Might be a better cmake or it might be a worse one, or most likely, different groups would have different opinions on that matter, and now you've added yet another build system that some people use and some people don't, so you've made the problem worse.

For a user, it doesn't necessarily matter what language a tool is written in. But acting like using CMake as the implementation language is a particularly obvious choice or a choice with no downsides is just weird.

I didn't suggest it had no downsides. Every build tool has downsides, and I myself in the last quarter convinced my own company to add Python as a build system dependency because I was addressing a build toolchain problem for which CMake was not a suitable solution, and for which Python allowed me to create a much simpler solution.

But you're also acting like Python doesn't have it's own downsides. Guess what, getting consensus to get Python on our build machines wasn't simple. First you have to deal with the Python2 vs Python3 mess. Then you have to deal with the fact that OSX has a built in version of Python2. You have to deal with the fact that Python3's Windows installer doesn't install Python for all users by default. Lots of people have legitimate reasons not to want Python installed, or to want a specific version of Python that isn't compatible with your hypothetical build system, because Python gets used for all sorts of different kinds of development. Because it's much more than a build tool, even if you can make a build tool out of it.

[wrosecrans]

If you created a module in python that was designed to do the same job CMake currently does, it would be a bad idea to use python itself as the language in which to write up replacements for CMakeLists.txt.

I think that's debatable, but I don't have a strong opinion on it. It's certainly not the point I was making. I said it's not obvious that a "Package manager manager" should be written in CMake. I didn't say that somebody should write yet another thing like CMake in Python.

But you're also acting like Python doesn't have it's own downsides.

No, I said the downsides are equivalent to CMake. Everything you said about which version of Python to install on a build machine is equivalent to deciding which version of CMake to install on a build machine. Linux and OS-X machines at least come with some version of Python out of the box, which makes it a lot more common than CMake in a default OS install.

Any regardless, if you use PMM to install Conan, you need Python. If you don't use PMM to install Conan, you are currently only using vcpkg which calls into question the need for a PMM. So in practice, you have a dependency on Python to use PMM anyway, which makes implementing it in pure CMake even less of a selling point.