Skip to content

[FR]: Extending Starlark extension capabilities #53

Description

@antspy

What is the current behavior?

Hi,

I am wondering if there were any plans to extend the interface available to us for starlak extensions.

Describe the feature

TL;DR

The following features would be useful (at least to me :) ):

  • In addition to file.path, would be nice to have a file.owning_target which points to the target to which this file belongs to (if any).
  • Would be nice to be able to iterate on ctx.targets instead of only on ctx.sources
  • It would be nice to be able to determine over which targets we run over (e.g. if I call configure in src/abc/BUILD and need to analyse src/def/BUILD, I should be able to do that)

My problem is that I am implementing some custom linting rules. These depend on having a marker file (an empty .marker file) in a directory, implying that something must be true for all files in that directory or any subdirectories.

This works fine for vscode / eslint (as they run in the source tree), but aspect lint runs in the bazel-bin directory, so we need to make sure the .marker files are also there, otherwise the linting would be useless (aspect lint would never find the .marker files).

So one would need to

  1. Add a filegroup rule for the .marker file.
  2. Make sure that every target in that directory or subdirectory has a dependency on the filegroup.

Asking people to do this manually would defy the point of having a linting rule, so the only solution I found is to add custom plugin for aspect generate that automatically does 1 and 2.

Doing 1 is trivial, but 2 is hard. We can only iterate over files (for file in ctx.sources:), and then for every file
we would need to

  1. Understand to which target it belongs to
  2. See if there is a market target in any directory above (including several levels above)
  3. If so, add a dependency to that marker target

IIUC this is not possible at the moment. I am aware it's probably not going to be possible for a while, but if you are looking for ways to extend the API, this could be a way to go :)

But if I am mistaken and you think there's a way to achieve this, please let me know, that would be cool!

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions