Show help in custom mix task

I understand that the @moduledoc text is what gets shown when you type in mix help your.task:
https://hexdocs.pm/mix/Mix.Task.html

Is there a way to show that information manually? For example, if my task has some required arguments or options, it’s possible to show an error using something like Mix.shell().error("Invalid input.), but I think it would be nicer in some cases to print out the usage info (just like you might encounter when you misuse a linux utility on the command line).

Thanks!

1 Like

You can just IO.puts @moduledoc.

Digging around in the source code for Mix.Tasks.Help, I can see that functions for this are not easily exposed… for some reason, I’m having trouble calling the functions in IO.ANSI.Docs, e.g.

warning: IO.ANSI.Docs.print_markdown/2 is undefined or private.

What’s going on there?

Yeah, that’s what I’m doing so far, but it would be nicer to take advantage of the formatting.

Mix.Task.run("help", ["name.of.your.task"])
5 Likes

Also do note that IO.ANSI.Docs is @moduledoc false which means it is an internal implementation detail of Elixir and you should not be calling it from your code.

1 Like

Not sure which sources you are digging, but at least on 1.10.2 I wasn’t able to find that function.

And as already has been said, the module is considered “private” and can change without notice.

I thought @moduledoc false only indicated that documentation pages would not be generated. I do that on my own quickie projects where documentation isn’t necessary. It does not prevent me from calling the public functions in the module, however, so I am genuinely confused as to why I can’t call those functions.

@moduledoc false and @doc false are conventions for internally used functions that need to be exposed because they are used through the project, but are also not part of the public interface of the library.

The reason why you can’t call the function, is because the source code you looked at does probably not match the elixir version you have installed.

This is the reason why the module is marked “internal”, this gives the core team the flexibility to change it as necessary without needing to think about backwards compatibility.

2 Likes

Yeah, I’m looking at the latest master branch of the Elixir source… that must be different than the 1.10.1 code that I am actually running…