Specify group of the component as doctag or section. #7336
Assignees
Labels
d-intermediate
Difficulty: some prior knowledge required
p-high
Should be completed in the next sprint
Milestone
Comments
Closed
farmaazon
added
d-intermediate
|
Adam Obuchowicz reports a new STANDUP for the last Friday (2023-07-21): Progress: Finished implementation and created a PR, applied review comments. It should be finished by 2023-07-24. Next Day: Next day I will be working on the #7313 task. Fix QA issues if any and take next task: Local scope filtering - or something else if there will be some pressing bug to fix. |
mwu-tow
pushed a commit
that referenced
this issue
Jul 24, 2023
Fixes #7336 in a quick way. Next to the old way of defining groups, the library can just add `GROUP` tag to some entities, and it will be added to the group specified in tag's description. The group name may be qualified (with project name, like `Standard.Base.Input/Output`) or just name - in the latter case, IDE will assume a group defined in the same library as the entity. Also moved some entities from "export" list in package.yaml to GROUP tag to give an example. I didn't move all of those, as I assume the library team will reorganize those groups anyway. ### Important Notes @jdunkerley @radeusgd @GregoryTravis When you will start specifying groups in tags, remember that: * The groups still belongs to a concrete project; if some entity outside a project wants to be added to its group, the "qualified" name should be specified. See `Table.new` example in this PR. * If the group name does not reflect any group in package.yaml **the tag is ignored**. * A single entity may be only in a single group. If it's specified in both package.yaml and in tag, the tag takes precedence. --------- Co-authored-by: Ilya Bogdanov <[email protected]>
Frizi
pushed a commit
that referenced
this issue
Jul 25, 2023
Fixes #7336 in a quick way. Next to the old way of defining groups, the library can just add `GROUP` tag to some entities, and it will be added to the group specified in tag's description. The group name may be qualified (with project name, like `Standard.Base.Input/Output`) or just name - in the latter case, IDE will assume a group defined in the same library as the entity. Also moved some entities from "export" list in package.yaml to GROUP tag to give an example. I didn't move all of those, as I assume the library team will reorganize those groups anyway. @jdunkerley @radeusgd @GregoryTravis When you will start specifying groups in tags, remember that: * The groups still belongs to a concrete project; if some entity outside a project wants to be added to its group, the "qualified" name should be specified. See `Table.new` example in this PR. * If the group name does not reflect any group in package.yaml **the tag is ignored**. * A single entity may be only in a single group. If it's specified in both package.yaml and in tag, the tag takes precedence. --------- Co-authored-by: Ilya Bogdanov <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To make defining component groups easier, the entry's group should be specified in its docstring. This is a first step of implementing https://github.com/orgs/enso-org/discussions/7120.
The group list should be still in the package.yaml, and the "export" fields there may be honored.
The text was updated successfully, but these errors were encountered: