Skip to content
This repository has been archived by the owner on Aug 15, 2024. It is now read-only.

How should we render features? #26

Closed
epage opened this issue Nov 16, 2023 · 1 comment · Fixed by #140
Closed

How should we render features? #26

epage opened this issue Nov 16, 2023 · 1 comment · Fixed by #140

Comments

@epage
Copy link
Collaborator

epage commented Nov 16, 2023

Currently, its:

features:
    name = [activation1, activation2, ...]

We could render this as a tree:

features:
  parent1
    child1
  parent2
    child1*

If we track activations, we could do a hybrid where explicit activations (see rust-lang/cargo#10681) are always roots and inactive features are processed like a normal tree

features:
  default
    default-dep1
    default-dep2
  other
  default-dep2*
  disabled1
  disabled2    

The question then is how to handle activations

  • Currently, default is the only thing activated
  • For cargo add: Show features that were explicitly enabled rust-lang/cargo#10681 , we'd need to choose a package (from parent directory?) to identify activations from the dependency entry
  • Alternatively, we could check the feature resolution and just show whatever is default activated for the workspace (ie what cargo-metadata would treat as activated)
@epage
Copy link
Collaborator Author

epage commented Nov 16, 2023

If we leverage activations, either kind, we could then mark a dependency as optional or required based on that.

@epage epage mentioned this issue Jan 3, 2024
8 tasks
epage added a commit to epage/cargo-information that referenced this issue Apr 1, 2024
epage added a commit to epage/cargo-information that referenced this issue Apr 5, 2024
epage added a commit to epage/cargo-information that referenced this issue Apr 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants