A feature request from user could be summarized as:
conan config installAfter discussing it, the most common use case is that users would like to use those remotes, even if not logged-in, because anonymous read usage is common practice. So it doesn't seem a pattern that would be useful for other users.
Furthermore, it would be coupling the auth process with the remote enabling process, seems not the best way.
I think that the feature that could make sense and totally address this use case too is the one of enabling/disabling remotes:
conan remote disable <remote-name> or conan remote enable <remote-name>This is a feature I have missed myself a few times, like disabling conan-center or bincrafters for doing experiments, and later needing to look up the remote to be able to set-up it again, and also playing with --insert to get the same order it was before. Plus it seems not very complex to implement.
So you config install 20+ repositories and you would need to disable 18? I don't like it... I'm that case I think it is better to remove them or not install them.
Maybe allowing patterns for enable/disable is a bit more handy. You can disable * and enable two of them.
I think it is useful when I have artifactory configured, but I don't want to run it all the time. So to avoid any error when installing a package, I need to exclude it from my remote list, otherwise Conan will raise an error because it's impossible to reach Artifactory. Disabling it would be better.
Yes, for disabling multiple repos:
I think the first should be easier to implement
Most helpful comment
I think it is useful when I have artifactory configured, but I don't want to run it all the time. So to avoid any error when installing a package, I need to exclude it from my remote list, otherwise Conan will raise an error because it's impossible to reach Artifactory. Disabling it would be better.