[feature] Profiles: pass-through the filename which has included current file

[leha-bot]

What is your suggestion?

Consider the generic config "detect-vars" (copied from docs https://docs.conan.io/2/reference/config_files/profiles.html#profile-rendering) :

{% set os, arch, compiler, compiler_version = profile_name.split('-') %}
[settings]
os={{ os }}
arch={{ arch }}
compiler={{ compiler }}
compiler.version={{ compiler_version }}

The another profile (e.g., Linux-arm64-clang-19) includes this profile:

include(detect-vars)

I want to forward the "Linux-arm64-clang-19" to the "detect-vars" logic some way, I thought that we may add import context for this case. I also understand that there would be another, more elegant solutions to forward some parameters (e.g. we could make a python function, but it didn't work for me).

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @leha-bot

Thanks for your suggestion.

I am not sure this feature wouldn't be problematic. With the current design the include(otherprofile) works more or less with the open/closed SOLID principle, the included profile behavior is not modified, but the current profile, the one doing the include() can overwrite and complete (kind of extend) the included profile.

Having such a base_profile_filename variable injected could be problematic in different cases:

• It would crash if the profile is used directly without being included (even for simple operations like a conan profile show command, which should work)
• It could check if base_profile_filename is None to act accordingly, but still that would be some complexity.
• What about transitive includes? Why only passing the direct including profile, and not other downstream ones?

It might be possible that too much is being done with the profiles. Could you elaborate a bit more on the use case? At the end of the day a lot of organizations work fine with a bunch of simple text defined profiles that represents the platforms they support and work with, and even if there can be some combinatorics, it is not that hundreds of files are needed.

If it is more a thing of code structure, have you tried the imports jinja functionality, and then wrapping the functionality in the included profile in a jinja {% macro myfunctionality(myargs) %}, which is called in the including profile (which has the profile name as arg)?