[question] How to build a tool requirement (application) without dependencies?

[fschoenm]

What is your question?

Hi, we have a tool that we want to package as a build requirement. It is available for Linux and Windows but I'm not really sure how to handle its requirements.

If I build the tool self.info.clear() in the package_id() function, it looks like this:

  my_tool
    my_tool/1.2.4@trs/stable
      revisions
        f32a5c93be09e5580addbb2e20881830 (2025-09-04 10:03:27 UTC)
          packages
            da39a3ee5e6b4b0d3255bfef95601890afd80709
              info

So now the os and arch are missing and it won't work to download the correct package for the platform I'm running on.

If I just remove build_type and compiler it looks like this:

  my_tool
    my_tool/1.2.4@trs/stable
      revisions
        e52cee289a43b509db2245fe852034de (2025-09-04 10:09:02 UTC)
          packages
            1394ccb8a7af3b8f676acb63a733d2134157e0c6
              info
                settings
                  arch: x86_64
                  os: Linux
                  os.glibc: 2.35
                requires
                  cxxopts/3.2.0#8026d4f53938b476b36288e5d006bcfb:da39a3ee5e6b4b0d3255bfef95601890afd80709
                  rapidjson/cci

Now it requires very specific dependencies that it (sometimes?) brings to the consumers of the tool.

Shouldn't an application package have no dependencies at all as it's only used as a tool at runtime? Is there a correct way to declare that? Or shouldn't conan maybe automatically remove dependencies from a conan package if you create an application package? Unfortunately I didn't really find the documentation helpful in that regard.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @fschoenm

Thanks for your question.

The package_id encodes the binary identity of a package binary with respect to different variable inputs, including dependencies information.
The effect of dependencies versions (and revisions, and even package_id depending on the linkage) is documented in https://docs.conan.io/2/reference/binary_model/dependencies.html.

In the "executable" linking a "static library" case, that effect on the package_id is critical to ensure the correctness and being on the safe side. If the information of the static libraries is removed from the pacakge_id, that means that even if the libraries get a critical bug fix, a security fix or whatever, the executable will still be running with the old version of the library, as it will not require a re-build from source.
This is why by default, the package_id takes it into account.
If you want to remove the effect of dependencies in the package_id of an executable, then you can do:

def package_id(self):
    del self.info.settings.build_type
    del self.info.settings.compiler
    self.info.requires.clear()

I see the requires.clear() might not be documented, and the documented approach is self.info.requires["mydep"].unrelated_mode(). I think we can document the self.info.requires.clear(), no problem with that.

Note that when doing self.info.requires.clear(), it is practically equivalent to define the vendor=True (at the end of the day, an executable statically linking libraries is a kind of vendoring), and it is the responsibility of the user to trigger a new build of the executable when it is desired to update it.