mirror of
https://github.com/aljazceru/Tutorial-Codebase-Knowledge.git
synced 2025-12-19 07:24:20 +01:00
update nav
This commit is contained in:
@@ -1,3 +1,10 @@
|
||||
---
|
||||
layout: default
|
||||
title: "Command & Group"
|
||||
parent: "Click"
|
||||
nav_order: 1
|
||||
---
|
||||
|
||||
# Chapter 1: Commands and Groups: The Building Blocks
|
||||
|
||||
Welcome to your first step in learning Click! Imagine you want to create your own command-line tool, maybe something like `git` or `docker`. How do you tell your program what to do when someone types `git commit` or `docker build`? That's where **Commands** and **Groups** come in. They are the fundamental building blocks for any Click application.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
layout: default
|
||||
title: "Decorators"
|
||||
parent: "Click"
|
||||
nav_order: 2
|
||||
---
|
||||
|
||||
# Chapter 2: Decorators: Magic Wands for Your Functions
|
||||
|
||||
In [Chapter 1: Commands and Groups](01_command___group.md), we learned how to create basic command-line actions (`Command`) and group them together (`Group`). You might have noticed those strange `@click.command()` and `@click.group()` lines above our functions. What are they, and why do we use them?
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
layout: default
|
||||
title: "Parameter (Option & Argument)"
|
||||
parent: "Click"
|
||||
nav_order: 3
|
||||
---
|
||||
|
||||
# Chapter 3: Parameter (Option / Argument) - Giving Your Commands Input
|
||||
|
||||
In the last chapter, [Decorators](02_decorators.md), we saw how decorators like `@click.command()` and `@click.option()` act like magic wands, transforming our Python functions into CLI commands and adding features like command-line options.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
layout: default
|
||||
title: "ParamType"
|
||||
parent: "Click"
|
||||
nav_order: 4
|
||||
---
|
||||
|
||||
# Chapter 4: ParamType - Checking and Converting Inputs
|
||||
|
||||
In [Chapter 3: Parameter (Option / Argument)](03_parameter__option___argument_.md), we learned how to define inputs for our commands using `@click.option` and `@click.argument`. Our `greet` command could take a `--name` option, and our `copy` command took `SRC` and `DST` arguments.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
layout: default
|
||||
title: "Context"
|
||||
parent: "Click"
|
||||
nav_order: 5
|
||||
---
|
||||
|
||||
# Chapter 5: Context - The Command's Nervous System
|
||||
|
||||
In the last chapter, [ParamType](04_paramtype.md), we saw how Click helps validate and convert user input into the right Python types, making our commands more robust. We used types like `click.INT` and `click.Path` to ensure data correctness.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
layout: default
|
||||
title: "Term UI (Terminal User Interface)"
|
||||
parent: "Click"
|
||||
nav_order: 6
|
||||
---
|
||||
|
||||
# Chapter 6: Term UI (Terminal User Interface)
|
||||
|
||||
Welcome back! In [Chapter 5: Context](05_context.md), we learned how Click uses the `Context` object (`ctx`) to manage the state of a command while it's running, allowing us to share information and call other commands.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
layout: default
|
||||
title: "Click Exceptions"
|
||||
parent: "Click"
|
||||
nav_order: 7
|
||||
---
|
||||
|
||||
# Chapter 7: Click Exceptions - Handling Errors Gracefully
|
||||
|
||||
In the last chapter, [Chapter 6: Term UI (Terminal User Interface)](06_term_ui__terminal_user_interface_.md), we explored how to make our command-line tools interactive and visually appealing using functions like `click.prompt`, `click.confirm`, and `click.secho`. We learned how to communicate effectively *with* the user.
|
||||
@@ -153,7 +160,7 @@ What exactly happens when a Click exception is raised, either by Click itself or
|
||||
* The formatted message is printed to `stderr` using `click.echo()`, respecting color settings from the context.
|
||||
5. **Exit:** After showing the message, Click calls `sys.exit()` with the exception's `exit_code` (usually `1` for general errors, `2` for usage errors). This terminates the program and signals the error status to the calling shell or script.
|
||||
|
||||
Here’s a simplified sequence diagram for the `BadParameter` case when a user provides invalid input that fails type conversion:
|
||||
Here's a simplified sequence diagram for the `BadParameter` case when a user provides invalid input that fails type conversion:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
||||
@@ -35,17 +35,3 @@ flowchart TD
|
||||
A4 -- "Injects via @pass_context" --> A0
|
||||
```
|
||||
|
||||
## Chapters
|
||||
|
||||
1. [Command / Group](01_command___group.md)
|
||||
2. [Decorators](02_decorators.md)
|
||||
3. [Parameter (Option / Argument)](03_parameter__option___argument_.md)
|
||||
4. [ParamType](04_paramtype.md)
|
||||
5. [Context](05_context.md)
|
||||
6. [Term UI (Terminal User Interface)](06_term_ui__terminal_user_interface_.md)
|
||||
7. [Click Exceptions](07_click_exceptions.md)
|
||||
|
||||
|
||||
---
|
||||
|
||||
Generated by [AI Codebase Knowledge Builder](https://github.com/The-Pocket/Tutorial-Codebase-Knowledge)
|
||||
Reference in New Issue
Block a user