Conan: [bug] Retrieving packages fails when first remote is not available

[ericriff]

The company where I work has its own artifactory server to host conan recipes/packages. We have it configured to be first in line, before conan-center.

$ conan remote list
conan-XXX: https://artifacts.XXX.com/api/conan/XXX-conan [Verify SSL: True]
conan-center: https://conan.bintray.com [Verify SSL: True]

Since we're working from home we need to access it through a VPN. If the VPN is down or if I'm not connected to it I would expect a warning from conan saying that my remote is unreachable and then continue searching for my requirements in the next remote in the list (in this caseconan-center) but instead conan gives an error and ask me to disable the faulty remote. Is this expected behavior?

Environment Details (include every applicable attribute)

• Operating System+version: Ubuntu 16.04
• Compiler+version: -
• Conan version: 1.21, 1.26
• Python version: 3.5.2

Logs (Executed commands with output) (Include/Attach if Applicable)

ERROR: Failed requirement 'lib/version@user/channel' from 'conanfile.py (ASD/1.0.0)'
ERROR: HTTPSConnectionPool(host='artifactory.XXX.com', port=443): Max retries exceeded with url: /artifactory/api/conan/XXX-conan/v1/ping (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f7e817d79e8>: Failed to establish a new connection: [Errno -2] Name or service not known',))

Unable to connect to conan-XXX=https://artifactory.XXX.com/artifactory/api/conan/XXX-conan
1. Make sure the remote is reachable or,
2. Disable it by using conan remote disable,
Then try again.
CMake Error at cmake/conan.cmake:403 (message):
  Conan install failed='1'

[jgsogo]

Yes, it is expected, and it was one of the motivations to add the disabled flag to the remotes (https://github.com/conan-io/conan/pull/5623). From our POV it is very important for the user to know exactly where the binaries they are using come from.

[ericriff]

Of course it is important to know where the binaries are coming from, that why we use our own remote and the packages we upload there have our own customuser/channel, that way even though we also have conan-center configured as a remote we can make sure that we're always pulling from our server.
We have two intended uses:

• During normal operation we have a list of requirements that end with customuser/stable, that way we always pull from out server.
• For quick testing or for personal projects we don't specify customuser/stable, we leave it blank or use conan/stable. By doing this conan firstly checks on the company server, do not find the packages there and then it tries with the official conan-center remote. If I'm not connected to my company VPN this breaks since instead of saying "oh this remote is down let me check on the next one" it just stops there.

Regardless, it is a minor inconvenience. If this is intended behavior I can disable the remote when I need to work outside the VPN.

I just find this behavior unintuitive.

Thanks for your time!

[jgsogo]

Hi, yes, it happens to me exactly the same for my personal projects and other remotes I add to Conan from time to time while trying different issues. What I do now is to have two different working environments, each one with a different Conan home, so they have different settings, different cache (I don't want to remove accidentally all the packages),... it is really easy to switch from one to the other using Python virtual environments.

[ericriff]

Got it. I'm closing this then.
Thank you very much for your time Javier!