[feature] look for .conanrc in USERPROFILE / ~ about conan HOT 5 CLOSED

Hi @peakschris

I am not sure if I get this one either.

The main problem is that it seems you are trying to use a "local" mechanism, that is the ".conanrc", that is 100% intended to be location-specific and local "per-user-folder" mechanism to implement some global configuration.

I know that this can be set globally with CONAN_USER_HOME, but it is non-trivial to automatically set this environment variable in configuration scripts and have it apply to both current and future shells.

This seems counter intuitive, having to create a file in a specific location so the application can read it to define the equivalent of an env-var looks like overkill to me. How is that simpler than directly creating a CONAN_HOME env-var in the system? Creating env-vars in systems is kind of pretty standard procedure. There are tons of apps that require a XXX_HOME env-var in the first place (defaulting to something like <userhome>/.xxx if not defined), I mean this is not specific to Conan.

In Windows, that it seems to be your platform it would be just setx CONAN_HOME <yourpath>, and that will set it for all shells. Maybe I am missing something?

from conan.

What I'm trying to do is to use conan to automatically install some binary packages such as git, python, node and other dev tools onto user's machines. I had thought that we could leverage conan's automations to create pipelines to build these things from source, cache them in our internal artifactory, and automate consumption onto user machines. Since these are global tools, they need to be installed to a global location, regardless of where the user runs the 'install' or 'update' tools from.

Once installed, I was creating symlinks from a known location on path into the appropriate package so that they could be run outside context of conan.

Using envvars is OK, but it's tricky to cover all the cases. setx sets the variable for future shells, but not the current one. bashrc works for bash, but not csh. Setting the envvar from python into the shell that will be active once the python script finishes is impossible.

Maybe conan is over-engineering this problem; maybe I should automate the packaging and push to artifactory and write a regular tool to fetch and extract zipfiles...

I'd be keen to hear your thoughts,

from conan.

What I'm trying to do is to use conan to automatically install some binary packages such as git, python, node and other dev tools onto user's machines. I had thought that we could leverage conan's automations to create pipelines to build these things from source, cache them in our internal artifactory, and automate consumption onto user machines. Since these are global tools, they need to be installed to a global location, regardless of where the user runs the 'install' or 'update' tools from.

But that might be a different angle than what we have been discussed before.
If you want to install them to a global location, isn't this a more regular "system" installation? Have you considered using something like a Conan deployer to install those things in the global location that you want? If the tools are kind of global, it wouldn't be nice for example if some user does conan remove "*" -c to clean their caches from "libraries", but then all the symlinks pointing to the cache are broken. Looks like the issue might be using a "local" and temporary storage, a "cache" of packages, as a global thing?

Once installed, I was creating symlinks from a known location on path into the appropriate package so that they could be run outside context of conan.

This kind of task might also be nicely automated in a Conan custom command extension.

Maybe conan is over-engineering this problem; maybe I should automate the packaging and push to artifactory and write a regular tool to fetch and extract zipfiles...

Not really, there are a bunch of aspects that still need to be managed, like versioning, updates, different binaries for different platforms, etc. It is way more doable with just tools than general C++ library packages, but still it can get a bit messy to be done manually if it is more than just a very few tools.

I am having a look to letting the recursive look for .conanrc file let reach the root of the filesystem, maybe it is possible to relax that, but still it could be the deployer approach would fit better?

from conan.

Proposing #16514, no guarantees, but lets check with the team.

from conan.

#16514 was merged, it will be in next 2.5.

Note however the comments above, it sounds there would be better approaches like deployers, custom commands, etc, rather than having this .conanrc in the filesystem root.

from conan.