conan: `conan install` seemingly hangs, in fact is silently installing with no console output

Conan 1.15.0, Mac OS X 10.14.4 18E226

After terminating a conan install .. with Ctrl-C, I ran the command again, and it appeared to hang. Wanting to collect more info, I terminated it again, and then ran conan install with CONAN_TRACE_FILE set and discovered that it actually didn’t hang, but is silently installing a bunch of dependencies. The only output I saw while this was happening was this:

$ export CONAN_TRACE_FILE=~/conan.log && conan install -p debug ..
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=apple-clang
compiler.cppstd=17
compiler.libcxx=libc++
compiler.version=10.0
os=Macos
os_build=Macos
[options]
[build_requires]
[env]

After the install has completed, which took a good 5 minutes, I finally saw the rest of the output:

conanfile.py: Installing package
Requirements
    FakeIt/2.0.5@gasuketsu/stable from 'conan-center' - Cache
    boost_algorithm/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_array/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_assert/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_atomic/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_bind/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_chrono/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_concept_check/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    ...
    fmt/5.3.0@bincrafters/stable:2e81740c9856cbfd57822c38999d3b19830708f6 - Cache
    lzma/5.2.4@bincrafters/stable:63363709da4dc3d9b6dcddd47681b79ef69bb2e7 - Missing
    zlib/1.2.11@conan/stable:63363709da4dc3d9b6dcddd47681b79ef69bb2e7 - Missing
    zstd/1.3.5@bincrafters/stable:63363709da4dc3d9b6dcddd47681b79ef69bb2e7 - Missing

FakeIt/2.0.5@gasuketsu/stable: Already installed!
boost_config/1.69.0@bincrafters/stable: Already installed!
boost_predef/1.69.0@bincrafters/stable: Already installed!
boost_preprocessor/1.69.0@bincrafters/stable: Already installed!
bzip2/1.0.6@conan/stable: Already installed!
doctest/2.3.1@bincrafters/stable: Already installed!
fmt/5.3.0@bincrafters/stable: Already installed!
lzma/5.2.4@bincrafters/stable: WARN: Can't find a 'lzma/5.2.4@bincrafters/stable' package for the specified settings, options and dependencies:
- Settings: arch=x86_64, build_type=Debug, compiler=apple-clang, compiler.cppstd=17, compiler.version=10.0, os=Macos
- Options: fPIC=True, shared=False
- Dependencies:
- Package ID: 63363709da4dc3d9b6dcddd47681b79ef69bb2e7

ERROR: Missing prebuilt package for 'lzma/5.2.4@bincrafters/stable'
Try to build it from sources with "--build lzma"
Or read "http://docs.conan.io/en/latest/faq/troubleshooting.html#error-missing-prebuilt-package"

Not sure what’s going on here, but thought I’d report it in case someone else runs into this.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 18 (15 by maintainers)

Most upvoted comments

Never for so long (you reported up to 5 minutes), but with huge graphs installing is a very time-consuming operation. After building the graph we check for available binaries given the package_id for each recipe+profile and it involves querying your remotes (if those binaries are not found in the cache). Once they are in the cache, then there is no need to query the remotes and things go really fast (that’s the reason why it appeared to you again when you change to the release build).

Using those modular boost time explode, those are ~100 libraries and we are checking for each binary package. According to your trace, each check takes more than 3 seconds (three API calls related to conaninfo.txt file) and those sum up your 5 minutes.

The main problem here is each API call taking 1 second at least, I don’t know if it is always the same or bintray was having a problem at that time. But I’ve just tried it and I get more or less the same results.

I hope this is not an issue related to Mac or any particular OS/Terminal.

Actions to take:

  • We are working on parallelizing binary downloads, we can extend that effort to these calls inside the graph.
  • Let someone of Bintray know about this, it is a real problem and I agree that one second per petition is too much.

OTR.- On my personal projects, I prefer to use the monolithic boost package but of course this is not a solution because the graph can be huge just because it has many libraries.