📝 Remove documentation pages that reference using Click directly (#1538)

Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>

Author: svlandeg

docs/features.md

@@ -71,14 +71,6 @@ Then it extends those ideas with features and bug fixes. For example, **Typer**
 
 ///
 
-## The power of Click
-
-<a href="https://click.palletsprojects.com" class="external-link" target="_blank">Click</a> is one of the most popular tools for building CLIs in Python.
-
-**Typer** is based on it, so you get all its benefits.
-
-But you can write simpler code with the benefits of modern Python.
-
 ## Tested
 
 * 100% <abbr title="The amount of code that is automatically tested">test coverage</abbr>.

docs/reference/context.md

@@ -1,11 +1,12 @@
 # Context
 
-When you create a Typer application it uses Click underneath.
-And every Click application has a special object called a [`Context`](https://click.palletsprojects.com/en/stable/api/#click.Context) that is normally hidden.
-But you can access the context by declaring a function parameter of type `typer.Context`.
+Every app has a special internal object that keeps track of state relevant to the script's execution.
+For some advanced use-cases, you may want to access it directly.
+This can be done by declaring a function parameter of type `typer.Context`.
+
+Similarly, you can also declare a function parameter with type `typer.CallbackParam` in case a callback could be used
+by several CLI parameters, and you need to figure out which one it was.
 
-The same way you can access the context by declaring a function parameter with its value,
-you can declare another function parameter with type `typer.CallbackParam` to get the specific Click [`Parameter`](https://click.palletsprojects.com/en/stable/api/#click.Parameter) object.
 
 ```python
 from typing import Annotated

docs/tutorial/arguments/envvar.md

@@ -116,11 +116,3 @@ Hello Mr. Wednesday
 ```
 
 </div>
-
-/// note | Technical Details
-
-In Click applications the env vars are hidden by default. 🙈
-
-In **Typer** these env vars are shown by default. 👀
-
-///

docs/tutorial/arguments/help.md

@@ -112,14 +112,6 @@ Options:
 
 </div>
 
-/// note | Technical Details
-
-In Click applications the default values are hidden by default. 🙈
-
-In **Typer** these default values are shown by default. 👀
-
-///
-
 ## Custom default string
 
 You can use the same `show_default` to pass a custom string (instead of a `bool`) to customize the default value to be shown in the help text:
@@ -266,28 +258,10 @@ But it won't show up in the main help text under the `Arguments` section.
 
 ///
 
-### Help text for *CLI arguments* in Click
-
-Click itself doesn't support adding help for *CLI arguments*, and it doesn't generate help for them as in the "`Arguments:`" sections in the examples above.
-
-Not supporting `help` in *CLI arguments* is an intentional <a href="https://click.palletsprojects.com/en/7.x/documentation/#documenting-arguments" class="external-link" target="_blank">design decision in Click</a>:
-
-> This is to follow the general convention of Unix tools of using arguments for only the most necessary things, and to document them in the command help text by referring to them by name.
+### Help text for *CLI arguments*
 
-So, in Click applications, you are expected to write all the documentation for *CLI arguments* by hand in the <abbr title="a multi-line string as the first expression inside a function (not assigned to any variable) used for documentation">docstring</abbr>.
-
----
-
-Nevertheless, **Typer supports `help` for *CLI arguments***. ✨ 🤷‍♂
-
-**Typer** doesn't follow that convention and instead supports `help` to make it easier to have consistent help texts with a consistent format for your CLI programs. 🎨
+**Typer supports `help` for *CLI arguments*** to make it easier to have consistent help texts with a consistent format for your CLI programs. 🎨
 
 This is also to help you create CLI programs that are ✨ awesome ✨ *by default*. With very little code.
 
-If you want to keep Click's convention in a **Typer** app, you can do it with the `hidden` parameter as described above.
-
-/// note | Technical Details
-
-To support `help` in *CLI arguments* **Typer** does a lot of internal work in its own sub-classes of Click's internal classes.
-
-///
+If you don't want the CLI Argument to be shown in help outputs, you can set the `hidden` parameter to `True`.

docs/tutorial/commands/callback.md

@@ -159,27 +159,3 @@ Creating user: Camila
 ```
 
 </div>
-
-## Click Group
-
-If you come from Click, this **Typer** callback is the equivalent of the function in a <a href="https://click.palletsprojects.com/en/7.x/quickstart/#nesting-commands" class="external-link" target="_blank">Click Group</a>.
-
-For example:
-
-```Python
-import click
-
-@click.group()
-def cli():
-    pass
-```
-
-The original function `cli` would be the equivalent of a Typer callback.
-
-/// note | Technical Details
-
-When using Click, it converts that `cli` variable to a Click `Group` object. And then the original function no longer exists in that variable.
-
-**Typer** doesn't do that, the callback function is not modified, only registered in the `typer.Typer` app. This is intentional, it's part of **Typer**'s design, to allow having editor auto completion and type checks.
-
-///

docs/tutorial/commands/context.md

@@ -1,6 +1,6 @@
 # Using the Context
 
-When you create a **Typer** application it uses Click underneath. And every Click application has a special object called a <a href="https://click.palletsprojects.com/en/8.1.x/commands/#nested-handling-and-contexts" class="external-link" target="_blank">"Context"</a> that is normally hidden.
+When you create a **Typer** application it always has a special, hidden object underneath called the "Context".
 
 But you can access the context by declaring a function parameter of type `typer.Context`.
 
@@ -99,8 +99,6 @@ Creating user: Camila
 
 You can pass configurations for the context when creating a command or callback.
 
-To read more about the available configurations check the docs for <a href="https://click.palletsprojects.com/en/7.x/api/#context" class="external-link" target="_blank">Click's `Context`</a>.
-
 For example, you could keep additional *CLI parameters* not declared in your CLI program with `ignore_unknown_options` and `allow_extra_args`.
 
 Then you can access those extra raw *CLI parameters* as a `list` of `str` in `ctx.args`:

docs/tutorial/commands/index.md

@@ -162,30 +162,10 @@ Commands:
 
 </div>
 
-## Click Group
-
-If you come from Click, a `typer.Typer` app with subcommands is more or less the equivalent of a <a href="https://click.palletsprojects.com/en/7.x/quickstart/#nesting-commands" class="external-link" target="_blank">Click Group</a>.
-
-/// note | Technical Details
-
-A `typer.Typer` app is *not* a Click Group, but it provides the equivalent functionality. And it creates a Click Group when calling it.
-
-It is not directly a Group because **Typer** doesn't modify the functions in your code to convert them to another type of object, it only registers them.
-
-///
-
 ## Decorator Technical Details
 
 When you use `@app.command()` the function under the decorator is registered in the **Typer** application and is then used later by the application.
 
 But Typer doesn't modify that function itself, the function is left as is.
 
 That means that if your function is simple enough that you could create it without using `typer.Option()` or `typer.Argument()`, you could use the same function for a **Typer** application and a **FastAPI** application putting both decorators on top, or similar tricks.
-
-/// note | Click Technical Details
-
-This behavior is a design difference with Click.
-
-In Click, when you add a `@click.command()` decorator it actually modifies the function underneath and replaces it with an object.
-
-///

docs/tutorial/exceptions.md

@@ -16,7 +16,7 @@ This code is broken because you can't sum a string and a number (`name + 3`).
 
 **Typer** will automatically use Rich to automatically show you nicely printed errors.
 
-It will **omit** all the parts of the traceback (the chain of things that called your function) that come from the internal parts in Typer and Click.
+It will **omit** all the parts of the traceback (the chain of things that called your function) that come from the internal parts in Typer.
 
 So, the error you see will be **much clearer** and simpler, to help you detect the problem in your code quickly:
 
@@ -112,7 +112,7 @@ But you should only enable it if you're not dealing with delicate information.
 
 ## Disable Short Output
 
-If you want to show the full exception, including the parts in Typer and Click, you can use the parameter `pretty_exceptions_short=False`:
+If you want to show the full exception, including the internal parts in Typer, you can use the parameter `pretty_exceptions_short=False`:
 
 {* docs_src/exceptions/tutorial003_py39.py hl[3] *}
 

docs/tutorial/multiple-values/options-with-multiple-values.md

@@ -48,14 +48,6 @@ coins = user[1]
 is_wizard = user[2]
 ```
 
-/// tip
-
-Notice that the default is a tuple with `(None, None, None)`.
-
-You cannot simply use `None` here as the default because <a href="https://github.com/pallets/click/issues/472" class="external-link" target="_blank">Click doesn't support it</a>.
-
-///
-
 ## Check it
 
 Now let's see how this works in the terminal:

docs/tutorial/options-autocompletion.md

@@ -124,9 +124,7 @@ So, in the end, we return a `list` of `tuples` of `str`:
 
 If you want to have help text for each item, make sure each item in the list is a `tuple`. Not a `list`.
 
-Click checks specifically for a `tuple` when extracting the help text.
-
-So in the end, the return will be a `list` (or other iterable) of `tuples` of 2 `str`.
+In the end, the return will be a `list` (or other iterable) of `tuples` of 2 `str`.
 
 ///
 
@@ -157,7 +155,7 @@ Sebastian  -- The type hints guy.
 
 Instead of creating and returning a list with values (`str` or `tuple`), we can use `yield` with each value that we want in the completion.
 
-That way our function will be a <a href="https://docs.python.org/3.8/glossary.html#index-19" class="external-link" target="_blank">generator</a> that **Typer** (actually Click) can iterate:
+That way our function will be a <a href="https://docs.python.org/3.8/glossary.html#index-19" class="external-link" target="_blank">generator</a> that **Typer** can iterate:
 
 {* docs_src/options_autocompletion/tutorial005_an_py39.py hl[12:15] *}
 
@@ -214,7 +212,7 @@ Hello Sebastian
 
 And the same way as before, we want to provide **completion** for those names. But we don't want to provide the **same names** for completion if they were already given in previous parameters.
 
-For that, we will access and use the "Context". When you create a **Typer** application it uses Click underneath. And every Click application has a special object called a <a href="https://click.palletsprojects.com/en/7.x/commands/#nested-handling-and-contexts" class="external-link" target="_blank">"Context"</a> that is normally hidden.
+For that, we will access and use the "Context". Every Typer application has a special object called a "Context" that is normally hidden.
 
 But you can access the context by declaring a function parameter of type `typer.Context`.
 
@@ -308,7 +306,7 @@ We get all the *CLI parameters* as a raw `list` of `str` by declaring a paramete
 
 /// tip
 
-Here we name the list of all the raw *CLI parameters* `args` because that's the convention with Click.
+Here we name the list of all the raw *CLI parameters* `args` because that's the usual convention.
 
 But it doesn't contain only *CLI arguments*, it has everything, including *CLI options* and values, as a raw `list` of `str`.
 
@@ -384,13 +382,3 @@ You can declare function parameters of these types:
 * `list[str]`: for the raw *CLI parameters*.
 
 It doesn't matter how you name them, in which order, or which ones of the 3 options you declare. It will all "**just work**" ✨
-
-## Comparison to Click functionality
-
-Note that Click 7 had a similar [`autocompletion` function](https://click.palletsprojects.com/en/7.x/bashcomplete/), but it worked slightly differently.
-
-It required the callback function to take exactly the 3 arguments `ctx`, `args` and `incomplete` in that exact order, instead of matching them dynamically based on types, as Typer does.
-
-Since Click 8, this functionality has been replaced by [`shell_complete`](https://click.palletsprojects.com/en/8.1.x/api/#click.ParamType.shell_complete), which still depends on the exact order of arguments for the callback function.
-
-However, Typer continues to use the `autocompletion` functionality as described on this page.