What does it for ?

ConanEx is using conan as underlying tool. ConanEx is a command line wrapper around conan with additional features.

Consider the following workflow:

wget https://github.com/google/flatbuffers/archive/refs/tags/v22.10.26.zip
unzip v22.10.26.zip -d flatbuffers_22_10_26
conan create --name=flatbuffers --version=22.10.26 flatbuffers_22_10_26/
conan create --name=ctre --version=3.6 ../../../../compile-time-regular-expressions/

Such workflow has a following drawbacks:

1. Not all dependencies are specified in conanfile.txt
2. It adds a boilerplate commands to execute each time when environment should be deployed

Lets also describe conancenter drawbacks:

1. Centralized repository (do not allow decentralized behaviour)
2. Hard to add conanfile.py receipt to conan-center-index. It takes too long to pass review with all unwritten conan-center-index rules for conanfile.py

Lets also describe a current conanfile.txt drawbacks:

1. conanfile.txt does not allow specifying dependencies to other package sources like git, remote zip archive and etc. It makes it less decentralized as claimed

Let's consider what ConanEx brings to conanfile.txt syntax. Consider the following conanfile.txt:

[requires]
poco/1.9.4
flatbuffers/22.10.26 {
    zip = 'https://github.com/google/flatbuffers/archive/refs/tags/v22.10.26.zip',
    sha256 = 'B97C7C017B05F20B17939FEBD413C75201F5B704C8DE49ADB0B35A70D50478CD'
}
ctre/3.6 { remote = "conancenter" }
# Examples:
# flatbuffers/2.0.0 {
#     git = https://github.com/google/flatbuffers,
#     tag = v2.0.0
# }
# flatbuffers/2.0.0 { zip = "https://github.com/google/flatbuffers/archive/refs/tags/v2.0.0.tar.gz" }
# flatbuffers/2.0.0 { conan = "https://raw.githubusercontent.com/google/flatbuffers/master/conanfile.py" }
# CTRE/3.6 { git = "https://github.com/hanickadot/compile-time-regular-expressions" }
# CTRE/3.6 { path = "../../../../compile-time-regular-expressions" }

[options]
flatbuffers/*:shared=True
poco/*:shared=True

As you can see in this file we have 5 additional ways to install package

Lets describe them:

1. git allow to download package using Git and run conanfile.py located in root directory
2. zip (url/file_path) allow installing package from archive, unpack it and run conanfile.py located in root directory. There are the following formats that supported: zip, tar.gz, tar.bz2
3. conan (url/file_path) if you receipt is completely independent, then you could specify url/path to it to create package. Independent means that receipt could download source files by itself.
4. path allow to install package from folder
5. remote specify separate remote for this particular package

url/file_path supports the hash calculation with options: md5, sha256 and sha512

To install conanex:

python3 -m pip install conanex

To use conanex use it the same way you use conan:

conanex install <path_to_conanfile.txt> -pr=<path_to_profile>

If you are using cmake integration, just copy cmake/conan_provider.cmake to your project and add to CMake option -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=./conan_provider.cmake. Then you could use find_package to find dependency package and use it:

find_package(cpptrace REQUIRED)

...

target_link_libraries(TestProject PUBLIC cpptrace::cpptrace)

1. Improved conanex install command to fill like package manager command. Instead of:

conanex install --requires=poco/1.13.3 --requires=flatbuffers/22.10.26 --requires=ctre/3.6 --build=missing --output-folder=/dev/null 
conanex install --requires=poco/1.13.3 --tool-requires=cmake/3.23.5 --tool-requires=ninja/1.11.0 --build=missing --output-folder=/dev/null 

Use like this:

conanex install poco/1.9.4 flatbuffers/22.10.26 ctre/3.6
conanex install poco/1.9.4 --tools cmake/3.23.5 ninja/1.11.0
conanex install --tools cmake/3.23.5 ninja/1.11.0 -- poco/1.9.4

This feels like alternative to apt-get on Ubuntu, brew on MacOS and choco on Windows, but cross-platform.

1. Implement ConanExFile to support in conanfile.py install of external dependencies