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

[morganhein]

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!

[andreynering]

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:*'

[morganhein]

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!

[morganhein]

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!

[pd93]

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.

[morganhein]

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.