build_requires not working with alternative remote

Environment details

• Operating System+version: Windows 11
• Compiler+version: Microsoft Visual Studio 2022 (17.5.4)
• Conan version: 2.0.4
• Python version: 3.10.5

Unable to build package with dependency when trying to use an alternative remote.

Steps to reproduce

When trying to use a different remote with conan create the dependencies are not working.

Example code:

class MyLib(ConanFile):
    def build_requirements(self):
        self.build_requires("otherlib/1.0.0@companyuser/stable")

    def generate(self):
        self.package_folder = self.dependencies["otherlib"].package_folder

Example use of conan create:

conan create --user=companyuser --channel=stable --verrsion=1.0.0 -r=test .

Example of error:
ERROR: mylib/1.0.0@companyuser/stable: Error in generate() method, line 31
self.package_folder = self.dependencies["otherlib"].package_folder
KeyError: "'otherlib' not found in the dependency set"

I have also tried self.build_requires("otherlib/1.0.0") and have similar problems.

Logs

No response

I added following code to check dependencies:

def generate(self):
        for require, dependency in self.dependencies.items():
            self.output.info("Dependency is direct={}: {}".format(require.direct, dependency.ref))

results:
mylib/1.0.0@companyuser/stable: Dependency is direct=True: otherlib/1.0.0@companyuser/stable

I have also tried following without success:

    def requirements(self):
        self.build_requires("otherlib/1.0.0")

It seems using the following will fix the problem:

    def requirements(self):
        self.requires("otherlib/1.0.0@companyuser/stable")

[memsharded]

Hi @colingcresset

Thanks for your question.

If you are using tool_requires, then the correct approach to get it would be:

 def generate(self):
        package_folder = self.dependencies.build["otherlib"].package_folder

Please do not assign to self.package_folder, that is a read-only property, you don't want to change the current package folder to point to one of the dependencies package folder
See https://docs.conan.io/2/reference/conanfile/methods/generate.html#conan-conanfile-model-dependencies for more information about self.dependencies

Then, you want to be sure of using the right approach depending on the use:

• tool_requires is exclusively for "tools", like "cmake", executables and scripts you need for building from source. But not libraries or headers
• requires is for normal libraries dependencies, with libs and headers
• test_requires is for libraries/frameworks for testing, like gtest or catch

[SSE4]

I suppose the following should work:

 def generate(self):
        package_folder = self.dependencies["otherlib"].package_folder

in other words, plain self.dependencies should return tool_requires as well.
e.g. doc says:

Take into account that self.dependencies contains all the current dependencies, both direct and transitive.

so doc clearly states plain self.dependencies returns ALL the dependencies, and ALL obviously includes tool_requires.
then, it says:

require.build: boolean, True if it is a build_require in the build context, as cmake.

so, it clearly assumes iterating the dependencies with code from the example should result in build_requires in the list.
for helper doc says:

self.dependencies.host: Will filter out requires with build=True, leaving regular dependencies like zlib or poco.

it means, self.dependencies.host should be a subset of plain self.dependencies (that's how I understand "filtering" - keep some values from the original list, remove other values from the original list).

for the package_folder doc never says it's read-only, how one can guess that?

[memsharded]

in other words, plain self.dependencies should return tool_requires as well.

It contains tool_requires. Also with the .get(, build=True) access. But the [] is a shortcut for requires only, as it cannot specify traits. So everything is correct, just need to clarify about the [] access.

self.dependencies.host is a subset of self.dependencies, that is correct. The only issue is the getter of a specific dependency via []

[SSE4]

in other words, plain self.dependencies should return tool_requires as well.

It contains tool_requires. Also with the .get(, build=True) access. But the [] is a shortcut for requires only, as it cannot specify traits. So everything is correct, just need to clarify about the [] access.

self.dependencies.host is a subset of self.dependencies, that is correct. The only issue is the getter of a specific dependency via []

wow, that's interesting. super confusing behaviour of [] operator compare to the regular python dictionaries. let's clarify it crystal clear in docs.

[SSE4]

as a side not, is it possible to change code here to something like:

    def __getitem__(self, name):
        return self.get(name, build=None) or self.get(name, build=True)

so it may return both build and host dependencies?

it's something very special and surprising that [] operator on dictionary-like object cannot address all the elements.
I suppose it introduces a lot of confusion for users that .items() vs [] operate on different amount of elements.

I solved my own build problem by using:

self.otherlib_rootpath = self.dependencies["otherlib/1.0.0@companyuser/stable"].package_folder

I tried the following, which all failed with the same error as initially reported.

self.otherlib_rootpath = self.dependencies.build["otherlib"].package_folder
self.otherlib_rootpath = self.dependencies.build["otherlib/1.0.0"].package_folder
self.otherlib_rootpath = self.dependencies.build["otherlib/1.0.0@companyuser/stable"].package_folder

[memsharded]

Please don't use self.public_variable. That is restricted for Conan. You should use self._xxx. And in most cases using object attributes is not recommended, local variables like myrootpath are strongly encouraged.

Please read: https://docs.conan.io/2/reference/conanfile.html

Can you clarify if otherlib is finally a tool_require or a require? Beware of the difference among those commented above.

otherlib is a require, it's not a tool.
I will update to use _, which I usually do.

For your information, otherlib is actually libvpx and the library trying to use it on our test remote is ffmpeg.
We build and host the libraries on our own jfrog artifactory server.

[memsharded]

If it is a requires it should work with self.dependencies["otherlib"] without issues, unless there is some ambiguity in the graph, because of multiple dependencies to otherlib.

I can confirm that self.dependencies["otherlib"] is working within generate method.