Conan: Check alternate locations for profiles, like source control checkouts

[sourcedelica]

Profiles is a great feature but they are not very DRY. If you have a large team and you want everyone to use the same profile for a particular package then each developer will have to create the profile in their own ~/.conan. That's a pain and over time individual profile files will get out of sync as things change in the project.

It would be great if there was a way to include profile files in the same source tree as the conanfile. That way they can be version controlled and DRY.

[lasote]

@sourcedelica but every team member have the same settings for the same package? Same OS? same compiler? same compiler version?

[memsharded]

The problem is a chicken and egg one. Profiles are just a shortcut for settings, environment variables, etc. So profiles actually define which packages are being used, because in many cases it is common to have conditional dependencies based on the settings, for example.

IMHO, if we are talking about some bits of information, that is being shared in a team of developers, that has to be versioned, easily modified and contributed back, keep the team in sync... we are talking about plain git :)

Has a first approach I would suggest:

• Create a git repo with the profiles.
• Make users clone it in their ./conan/profiles directory

Conan might be used to create a package with the profiles info, and add some functionality that will copy them in the conan install command. But, as I see it, I don't understand a package recipe without a supporting git repo, the info would already be in git, and the extra work to create the conanfile, package, upload, install the profiles seems overkill for something that a git clone would solve.

[sourcedelica]

Right - the package recipe would be in git along with the source code. This is a way to avoid having to keep many developers in sync. I am looking at using Conan for managing an internal development project with hundreds of packages. We keep everything in source control: makefiles, conan recipes, source code, etc. We want to use Conan to build common packages and not have to build the whole source tree from scratch.

Luis - yes, everyone has the same compiler settings, compiler version, OS, etc. We do it that way so everyone builds the same thing and we don't get "worked on my machine" problems. That ties into our use of Conan. Since everyone is using the same settings, we can have a shared set of packages used by all applications.

The workaround to clone part of the git repo into .conan/profiles is doable in the worst case, but since we already have everything else in source control it would be good to have the profiles there too.

[sourcedelica]

I changed the title of this one since it was a little confusing. It doesn't have to be in the package directory, I was using that more of an example. We would probably have one or two main locations in source control where our profiles would live, and those profiles would be used across many packages. It's more the concept of being able to use the profiles in source control without having to copy them out to ~/.conan/profiles where they will get out of sync.

[memsharded]

Oh, yes, I think that would be feasible. Maybe add some configuration path to conan.conf pointing to a profiles storage, that can be different of the default .conan/profiles. Then, team mebers just configure it to point to the desired location, and that's it. Something like the following sounds good?

[storage]
# This is the default path, but you can write your own
path: ~/.conan/data
profiles: /home/myuser/myproject/path/to/profiles

[settings_defaults]
arch=x86_64
build_type=Release

As long as myuser keeps working and updating myproject from version control, they will have synced profiles.

[lasote]

Sounds good to me. If @sourcedelica likes it we can mark it as a "feature approved"

[sourcedelica]

Looks great, thanks!

[sourcedelica]

Hmm.. I spoke too soon. One other twist is that developers can be working with multiple checkouts/clones at the same time. That's why I was thinking about the package directory - a way of specifying the profile relative to the package directory. One idea - we can write a script that calls conan install --profilePath $locationInClone, where $locationInClone is something we can calculate based on our knowledge of the repo layout.

[lasote]

I see. What if we allow to specify names or paths to profile file in the "--profile" option?
We could do something like:

conan install --profile Myprofile <= Goes to .conan/profiles/*
conan install --profile ./Myprofile <= Reads ./Myprofile
conan install --profile /usr/shared/profiles/Myprofile <= Reads absolute path

What do you think @memsharded?

[memsharded]

Another idea: maybe profiles could be specified with relative or absolute path, so no extra argument is needed. Something like:

$ conan install --profile=/home/myuser/myprofiles/gcc49_dbg  # abs path
$ conan install --profile=gcc53_release # look in the default ./conan/profiles folder
$ conan install --profile=./project_profiles/gcc62_dbg # look in the relative path (relative to the conanfile?)

[lasote]

@memsharded SAME CONTENT SAME TIME. ahhahahah

[memsharded]

So I like the idea.
We could also support hierarchical git-like resolving:

1. First, look for the given name in the "conan_profiles" local project folder
2. If not found, try to resolve by local path in the local project folder
3. If absolute path, use it
4. Otherwise, try to look for the profile in the .conan/profiles conan user local cache

[lasote]

@memsharded I think it's better to keep it simple, We will be able to add more use cases later (they are compatible).

[sourcedelica]

Sounds good to me!

-- Eric

On Thu, Dec 1, 2016 at 4:48 AM, Luis [e-mail] wrote:

@memsharded https://github.com/memsharded I think it's better to keep
it simple, We will be able to add more use cases later (there are
compatible).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conan-io/conan/issues/714#issuecomment-264127697, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEBjBPDeWPU9XqmYKkqNVKdIvygDe50Sks5rDpgDgaJpZM4K_DRe
.

[memsharded]

Implemented and merged to develop by #736, will be available in 0.17.