[lantastic]

Conan (https://conan.io/) tries to tackle the package management for C/C++.

[epage]

While Conan still has some room to grow, I love the approach they take to package management for C++.

Too many C++ tools couple package management and build which increases their adoption cost and makes it more work to package third part packages. Conan takes the approach of managing dependencies and then giving your build system of choice the information it needs to access those dependencies via conan plugins. I think I had read that the author of Conan was involved in biicode and that the third party packaging problem is what inspired him to create Conan.

Some other cool things about conan

- Can be used for more than C++

- SCM independent

- Artifact caching

- Options allow clients to customize your package (creates distinct artifact)

- Scopes allow developers to modify your build (like conditional build steps so doesn't create a distinct artifact)

Some things I think can be improved

- Needs to separate out dependency lock file like Cargo or Poet

- Build tools need to be packaged in Conan for tracability / reproducibility

- Plugins are in Python which is heavy for deployment and has a large compatibility surface

- Easy to hit limits of declarative dependency files, being forced into implementing them in Python (see above)

- Project templates are hard coded.

[pfultz2]

> Too many C++ tools couple package management and build

Conan does this too. If I follow the instructions to integrate cmake with conan, I would write something like this:

    include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
    conan_basic_setup(TARGETS)

    add_executable(timer timer.cpp)
    target_link_libraries(timer CONAN_PKG::Poco)

Which now couples my build with conan. If the user would like to pull down the dependencies without conan(ie using apt-get or manually installing them), the cmake build script will not work.

Package managers like cget[1] or conda[2] does not couple the build with the package manager. Cget is also serverless which is nice as it can install dependencies from anywhere(even directly from github with `cget install jgm/cmark`), however, you need to setup your own server hosting if you want to install binaries.

[1]:http://cget.readthedocs.io/en/latest/

[2]:https://conda.io/docs/intro.html

[slezyr]

> Which now couples my build with conan. If the user would like to pull down the dependencies without conan(ie using apt-get or manually installing them), the cmake build script will not work.

http://docs.conan.io/en/latest/integrations/cmake/find_packa...

[pjmlp]

I dislike it is written in Python instead of C++.

No need to force me to install Python just to run a build tool.

[pfultz2]

The nice things about cget is that even though it uses python(which is mainly for easy distribution), the cget protocol only has a dependency on cmake. So cmake modulues like cmake-get[1] can install cget recipes directly in cmake without needing python installed.

[1]:https://github.com/pfultz2/cmake-get

[Samathy]

Python is a great solution to the problem as well as being installed on most Linux distros by default. Chances are devs would need for their other dev tools anyway even not on a Linux machine.

[pjmlp]

A build tool should be written in the same language as it is targeted for, no need for third party dependencies.

Many of us only install what we actually need, or what the IT department allows on our images.

I certainly don't want to open a IT ticket to get Python, just to be able to compile random package X.

[ioquatix]

I maintain and use http://teapot.nz for development. It's made my life so much better - it's designed for developers.

[lantastic]

Nice, I will definitely try it out!

[ioquatix]

Thanks, I'd love any and all feedback. I use it almost daily and my goal is to make it as awesome as possible!