Dependency's default features are always enabled

[dbarkar]

Describe the bug
I'm creating a port that uses ffmpeg with excplicitly defined features:

"features": {
    "ffmpeg": {
      "description": "Use FFMPEG to play WMA and AAC audio formats.",
      "dependencies": [
        {
          "name": "ffmpeg",
          "default-features": false,
          "features": [
            "avcodec",
            "avformat",
            "swresample"
          ]
        }
      ]
  }

But when I use this port in my app, ffmpeg is still compiled with default features:

The following packages will be built and installed:
  * ffmpeg[avcodec,avdevice,avfilter,avformat,core,swresample,swscale]:x64-windows-static -> 5.1.2#6

If this is not a bug, are there workarounds? I need only small part of ffmpeg, I don't want the end users of my library to build the whole ffmpeg.

Environment

• OS: Windows
• Compiler: any

To Reproduce
Steps to reproduce the behavior:

1. Create any port
2. Add dependency with default features disabled
3. See that default features are enabled.

Expected behavior
Default features must be disabled if this is specified.

[Neumann-A]

If this is not a bug, are there workarounds? I need only small part of ffmpeg, I don't want the end users of my library to build the whole ffmpeg.

Needs full manifest to figure that out. If I only run a manifest with ffmpeg i get:

The following packages will be built and installed:
    ffmpeg[avcodec,avformat,core,swresample]:x64-windows-release -> 5.1.2#6

So you probably have another dependency pulling in the rest.

[dbarkar]

If I only run a manifest with ffmpeg i get

Did you add ffmpeg to your app (that works) or to a vcpkg's port (that doesn't work)?

[dg0yt]

Frequent misunderstanding.
The port manifest doesn't enforce minimal dependencies but can enable them.

It is the user who must decide, at the command line by adding core to the list of features for ffmpeg, and in manifest mode by adding "default-features": false to the ffmpeg depedency (in the user project manifest).

[dbarkar]

So if I'm building an app that uses library A that uses library B, I must add to my project's manifest specification for library B and specify features there?

[Neumann-A]

So if I'm building an app that uses library A that uses library B, I must add to my project's manifest specification for library B and specify features there?

If you want a minimal/specific set of features for library B then yes.

[dbarkar]

Thanks for the explanation.
That's not really obvious, I thought that library should care about its dependencies not the end user.
Maybe it's worth adding to a FAQ?

[moritz-h]

I also noticed this problem and it is really unintuitive and feels highly wrong in manifest mode. After also reading the discussion in #26664 my feeling is that perspectives/arguments from classical mode collide with the perspectives/arguments from manifest mode. That may have led to why the discussion in #26664 escalated into endless circles.

The argument for the current behaviour is

It is assumed that the default set of features is what most users want.

(Citing @dg0yt from #26664 (comment))

I would agree to this in classical mode but highly disagree in manifest mode.

In classical mode vcpkg could be seen as system wide package installer and, therefore, transitive dependencies and directly installed dependencies kind of get mixed up. So if I see a package is already installed (no matter where it comes from) I would expect it to "just work" which then of course means default-features should be there. Otherwise it would feel like an incomplete installed package. With that an opt-out possibility, as it currently is, is probably what a user expects. In classical mode also build times may not be that critical, because it is more or less "install once globally".

However, in manifest mode I think exactly the opposite is expected. I absolutely do not care about any feature of a transitive dependency. If I would need to interact with that port or any feature of that port directly, it would be a direct dependency of my project. You argue that I have the possibility to opt out, but that would mean I have to duplicate all transitive dependencies to be a direct dependency, just to be able to disable unnecessary default features. This also means I have to check on every version update of a dependency if transitive dependencies changed in any way, i.e. new added, some removed or changed. That feels very wrong.

As solution it may be worth to think about if it is possible to define a different behaviour how to handle default features for classical and manifest mode. On the other hand, I cloud understand if things should be consistent between classical and manifest mode. In that case, maybe it would be possible to add a global option "only-install-minimal-set-of-depdencies-even-if-it-means-default-features-are-disabled" to the vcpkg.json, where I can define this behaviour for my whole project and all transitive dependencies at once.

[moritz-h]

Ok, just saw #31298. That is already the same idea. Would be resolved with that.

[github-actions]

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 28 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.