[feature] [2.0] Make conan use conanonical config/cache/etc files.

• I’ve read the CONTRIBUTING guide.

Tl;dr

What I’m suggesting

Stop using HOME/.conan for everything and instead use the canonical folders. So on linux settings.yml would go in HOME/.config/conan since it’s configuration and the data folder would go in HOME/.cache/conan since it can easily be regenerated.

The python project appdirs gives an easy way to find the right folders for everything in a cross platform way.

Why is this important

• People who know the OS will understand what each folder/file does better.
• The OS and other tools will be able to better handle Conan
• Sysadmins will be able to better handle Conan
• Making backups will be more straight forward
• Its cool to do things the Right Way

Potential problems

• People who don’t know there OSs customs might find this more confusing difficult.
• Even if a user knows the OS customs they might be confused for a while about the change.
• Conan shouldn’t use global folders like /usr/local/share if Conan was installed locally. I don’t think appdirs can detect a local installation though.
• Conan can automatically migrate all the files it knows about but if the user put their own files into .conan then Conan doesn’t know whether those are config, cache, data etc. In those cases the migration will have to be finished by the user by hand.

---

Longer form

What I’m suggesting

Currently in Linux Conan has folder called .conan directly under the home folder. This is the old school linux way of doing things. Nowadays linux encourages the the use of .config, .cache and other such folders. This keeps the home folders clean and adds semantic information to the config files.

The .config is where configuration needs to stay. So when I’m backing up my computer I know I need to backup .config. Neovim uses the .config to store the vimrc, for example. The .cache folder is for stuff that can be regenerated. When my computers getting low on storage I can nuke .cache without worry. Pip uses .cache folder to cache wheels and other packages it pulls from PyPi and pypoetry uses it for virtual environments.

Conans folder structure looks like this right now.

HOME
└── .conan
   ├──  artifacts.properties
   ├── cacert.pem
   ├── conan.conf
   ├── data
   │   ├── <pkg name>
   │   │   └── <version>
   │   └── <other pkg>
   │       └── <version>
   ├── hooks
   │   └── attribute_checker.py
   ├── profiles
   │   └── default
   ├── remotes.json
   ├── settings.yml
   └── version.txt

On linux it should probably look something like this

HOME
├── .config
│   └── conan
│       ├──  artifacts.properties
│       ├── cacert.pem
│       ├── conan.conf
│       ├── hooks
│       │   └── attribute_checker.py
│       ├── profiles
│       │   └── default
│       ├── remotes.json
│       ├── settings.yml
│       └── version.txt
└── .cache
    └── conan
        ├── data
        ├── <pkg name>
        │   └── <version>
        └── <other pkg>
            └── <version>

On windows there’s the AppData and I don’t even know what Mac uses. Luckily there’s a handy python library called appdirs the takes care of finding the OS specific locations.

I haven’t dug into the conan source code but I feeling that this change would touch many files but each individual change will likely be pretty straight forward (if it’s put into Conan 2.0 as a breaking change).

Why this helps

When I was trying to understand Conan a lot of things were mysterious to me. It took me a good couple hours before I realized I could just delete the data folder without consequence. Using the canonical folders is in some ways another form of documentation. When something is in .config it tells the user “this is per user configuration, if you need to configure conan for your user the files to do so are in here somewhere”. When I see that I have a .conan in the home directory I am told “all the data for conan is here probably.”

Tools and people trust this configuration for system administration, backups, etc. My backup scripts go into .config and backup the folders of all the programs I care about. I don’t know what’s in there or how it works half the time but I know it’s configuration. My script ignores everything in .cache because I know it can all be regenerated and I want my backups slim. Every time a program drops their stuff in the home directory I have to actually learn about the program, folder by folder, and in some cases file by file, and decide what’s important to keep (*cough* firefox *cough*). Using the standard system administration easier.

[cheog]

@memsharded Thank you for taking the time to respond to this in full. I appreciate it a lot.

[memsharded]

A couple of notes about this:

• We have favored homogeneous layout for all OS. It simplifies the code, the maintenance, the support and the documentation. Things are always in <userhome>/.conan in all platforms. This can also simplify CI scripts of users dealing with multiple platforms.
• Having everything in 1 location allows to change the root folder, via 1 single env-var CONAN_USER_HOME, which is very common for CI setups. If the folders are separate, now the first point complexity keep compounding.

While I understand the Linux specific layout could have advantages, the fact is that other OS doesn’t have such strong convention, and that results that in practice a ton of tools do not follow that convention, as well described in https://twitter.com/codeinred/status/1445275055626199040?s=20. At the moment I tend to think (as always, it is a trade off) that even if slightly more convenient for Linux users, it would be overall better to keep it because of the above reasons.