Add ability to filter tasks by namespace on `--list` and set a default filter · Issue #2089 · go-task/task · GitHub
Skip to content

Add ability to filter tasks by namespace on --list and set a default filter #2089

Open
feature
Open
Add ability to filter tasks by namespace on --list and set a default filter#2089
feature
Labels
area: uiChanges related to the UI of Task.

Description

@morganhein
morganhein
opened on Feb 25, 2025

Description

Howdy Task!

I know namespaces exist, and I use them heavily, but it's not enough for my use case.

I use Task heavily in a monorepo. It now contains tasks for:

  1. developer interactions/bootstrapping
  2. pre-commit hook targets/entries
  3. github ci action steps
  4. dockerfile container creation

This has been really great for having re-usable, composable steps that are also user-discoverable.

However even with things namespaced, the user experience for 1 is not great when all the other tasks exist. If I lean into usin Task further, I can imagine 100+ tasks, and that's just useless when listing as a developer.

So for me, being able to set "categories" of visibility (on top of namespaces), being able to default that only a specific namespace gets displayed, or something, would be great.

What i'm proposing is something like:

default_visibility: development
tasks:
  up:
    desc: Starts up the docker compose environment for development
    visiblity_group: development
    cmds:
      - docker compose -f docker/docker-compose.yaml up -d

  down:
    desc: Stops the docker compose environment for development
    visiblity_group: development
    cmds:
      - docker compose -f docker/docker-compose.yaml down

  mocks:
    desc: Generate mocks for the firehose service
    visbility_group: ci
    cmds:
      - moq -out ./config_manager_mock.go ./ ConfigManager

Then, when listing, allow me to do something like task --group development or something.

For me, the real ask here is somehow hiding groups of tasks by default. I want Task to be the root/first place to look for all Tasks, regardless if it's a CI task or commonly used dev task. All tasks should be easily runnable by a user, without having to know which group/taskfile/etc it exists in. However for those that are just learning/discovering the code base, a simple task --list or analogous should present the user with the least amount of options possible, ideally with tasks that are more tailored to their experience.

Using namespaces, this still spits out a list that overfills the terminal, and overwhelms the user.

Another way might be able to default a certain namespace as the only one visible?

so a task --list would, by default, only show the dev: namespace, or something?

Either way, thanks for the awesome tool!

Activity

  1. task-bot
    added
    state: needs triageWaiting to be triaged by a maintainer.
    on Feb 25, 2025
  2. andreynering
    added
    area: uiChanges related to the UI of Task.
    and removed
    state: needs triageWaiting to be triaged by a maintainer.
    on Feb 25, 2025

  3. andreynering commented on Feb 25, 2025

    @andreynering
    andreynering
    on Feb 25, 2025
    Member

    Hi @morganhein,

    I can see why this would be useful.

    Instead of introducing a new concept, I'd consider having some sort of filtering by namespace, with a setting to set the default. What do you think about it?

    task --list 'dev:*'
    version: '3'

default_filter: 'dev:*,docker:*'

  4. morganhein commented on Feb 25, 2025

    @morganhein
    morganhein
    on Feb 25, 2025
    Author

    Yes, this would work as well. Anything to allow for visibility management of tasks in the default and power-user case would be great! Cheers!

  5. andreynering
    changed the title [-]Add a visibility category on top of namespaces[/-] [+]Add ability to filter tasks by namespace on `--list` and set a default filter[/+] on Feb 25, 2025

  6. morganhein commented on Feb 25, 2025

    @morganhein
    morganhein
    on Feb 25, 2025
    Author

    Andrey,

    I've been thinking about this proposal more, and wanted to share some additional considerations. This is just a thought exercise to explore alternatives. Maybe I should've thought this out completely beforehand, so that's on me. Either way here's a few thoughts:

    Regarding your proposal about not introducing a new concept - I think if we consider this from both the technical and user perspectives, things do change a bit. While technically we're not creating something like "groups" that affect visibility in the codebase, from a user perspective, this does change how namespaces function conceptually.

    Historically, namespaces served primarily as logical groups that affected display ordering (based on that logical group) during listing operations. With this change, namespaces would also function as "visibility groups" - essentially giving them dual purposes. This means users would likely need to prefix namespaces with their visibility category.

    Consider these two examples:

    Current Logical Grouping:

    build:builder:local:
  desc: Builds the go-builder-local image, with deps in the image.
  cmds:
    - |
      export ref=$(mage GetBuilderHash)
      echo "Building morganhein/go-builder-local:${ref}"
      docker build --no-cache --progress=plain -t morganhein/builder-local:${ref}  .

build:builder:
  desc: Builds the go-builder image, with deps in the image.
  cmds:
    - |
      export ref=$(mage GetBuilderHash)
      echo "Building morganhein/go-builder:${ref}"
      docker build --no-cache --progress=plain -t morganhein/builder:${ref}  .

    Proposed Visibility Grouping:

    dev:build:builder:
  desc: Builds the go-builder-local image, with deps in the image.
  cmds:
    - |
      export ref=$(mage GetBuilderHash)
      echo "Building morganhein/go-builder-local:${ref}"
      docker build --no-cache --progress=plain -t morganhein/builder-local:${ref}  .

ci:build:builder:
  desc: Builds the go-builder image, with deps in the image.
  cmds:
    - |
      export ref=$(mage GetBuilderHash)
      echo "Building morganhein/go-builder:${ref}"
      docker build --no-cache --progress=plain -t morganhein/builder:${ref}  .

    This visibility-first approach has several implications:

    1. When using task --sort alphanumeric (let's say in the default listing scenario), tasks would display with repetitive namespace prefixes, which might feel redundant during typing. Users might wonder why they need to type these prefixes if all they see by default is "dev:" tasks.

    2. With task --list-all --sort alphanumeric, categorization would prioritize visibility prefixes over logical groupings, potentially obscuring relationships between related tasks. This is a big one for me, I very quickly lose the ability to quickly grok all the "build" tasks across all "visibility groups".

    3. A potential workaround would be to remove the --sort alphanumeric option and instead arrange task entries in the Taskfile in the preferred display order, and assume when listing to always just use task. What this says to me though is that once I use a "visibility prefix", I lose the ability to sort things by logical group, because the output can no longer provide that to me. It also means that those editing the file need to understand how order affects the output, and it becomes a "hidden concept" that is only useful if it's enforced.

    4. Another scenario which I would like to support is having a task be part of several "visibility groups". For example, let's imagine a scenario where I want to group both "onboarding" tasks, and "regular dev" tasks. Some of those tasks intersect. It would be great to be able to have in a readme, that a user should type task --list --vis=onboarding for example, and it show all the tasks specific to that user. And then normal task --list or task --list vis=dev could have some, or all, or none, of the tasks from the onboarding visibility group. I could replicate this with many duplicate Task entries, but I hope you agree that does not sound like a great management experience.

    Thanks for considering!

  7. pd93 commented on Feb 26, 2025

    @pd93
    pd93
    on Feb 26, 2025
    Member

    Really not a fan of adding things like this to the Taskfile schema. It feels more like configuration than anything to do with the actual tasks. I've actually had an overhaul of the output system in the back of my head for a while now. I believe that this should address the majority of your problems or easily be extended to do so.

  8. morganhein commented on Feb 26, 2025

    @morganhein
    morganhein
    on Feb 26, 2025
    Author

    The tags property you are proposing for the schema in your redesign looks like it handles this use case? If tags are usable as a way to filter visibility when listing, that would solve this problem as well.

  9. pd93
    added the
    feature
    issue type on Mar 13, 2025
  10. pd93
    added a parent issue on Mar 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: uiChanges related to the UI of Task.

    Type

    feature

    Fields

    No fields configured for feature.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions