Dependency groups

The goal of this feature is to make it easier for users to extract dependencies for a particular usage or platform.

Inside the manifest, we should allow the user to tag dependencies as belonging to particular groups.

It might look like this:

[[dependency]]
package = "github.com/abc/def"
version = "*"
groups = [ "dev" ]

[[dependency]]
package = "github.com/abc/ijk"
version = "*"
groups = [ "macos" ]

[[dependency]]
package = "github.com/abc/lmno"
version = "*"
groups = [ "dev", "linux" ]

By default, a dependency would not belong to any groups.

We would then provide a macro in buckaroo_macros.bzl that allows the user to extract all dependencies for a given group:

load('//:buckaroo_macros.bzl', 'buckaroo_deps_from_group')

cxx_binary(
  name = 'app', 
  srcs = [
    'main.cpp', 
  ],
  platform_deps = [
    ('macos.*', buckaroo_deps_from_group('macos')),
  ], 
)

Open questions:

• What if the same package is in more than one dependency? Merge the groups?
• What is a valid group? Alphanumeric?

This is how we should support development and platform dependencies.

[njlr]

Given that the build scripts are written in Python (well, a Python variant called Skylark), a filter function is definitely possible. We can also have named arguments as you suggest (dev = True).

I think this could work well.

However, this leaves the question of custom groups. I think that this feature is very important, because we cannot anticipate all of the kinds of dependency that people might have.

We could also consider doing both! I’m not sure if the complexity will be worth it though.

[njlr]

Hi @iwatakeshi, thanks for the response!

Our initial idea was exactly as you describe, with os and dev as built-in concepts. We came up with two issues with this approach.

1. What do the macros look like when the user extracts the dependency?

With the “groups” approach, it looks like this:

macos_deps = buckaroo_deps_group([ 'macos' ])
macos_dev_deps = buckaroo_deps_group([ 'macos', 'dev' ])

But with the “os + dev” approach it (might) look like this:

macos_deps = buckaroo_deps_os('macos')
macos_dev_deps = buckaroo_deps_os_dev('macos') # Feels wrong!

I think the first way looks nicer. What do you think?

2. How do we support other kinds of group?

There might be more types of dependency, not just platform-specific or development-specific.

With the “groups” approach, the user can just define a new group:

[[dependency]]
package = "github.com/abc/lmno"
version = "*"
groups = [ "custom" ]

and use it like this:

custom_deps = buckaroo_deps_group([ 'custom' ])

I’m not sure how this could work with the “os + dev” approach. Any ideas?

None of this is implemented yet, so we would appreciate your thoughts!