Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixup and improve book using_modules.md #1608

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open
34 changes: 24 additions & 10 deletions book/modules/using_modules.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ The example above uses the [Standard Library](../standard_library.md), a collect

## Installing Modules

Installing a module is simply a matter of placing its files in a directory. This might be done via `git clone` (or other version control system), a package manager such as `nupm`, or manually. The module's documentation should provide recommendations.
Installing a module is a matter of placing its files in a directory. This might be done via `git clone` (or other version control system), a package manager such as `nupm`, or manually. The module's documentation should provide recommendations.
Kissaki marked this conversation as resolved.
Show resolved Hide resolved

## Importing Modules

Expand All @@ -42,7 +42,7 @@ The module's documentation will usually tell you the recommended way to import i

The path to the module can be:

- An absolute or relative path to a directory containing a `mod.nu` file:
- An absolute path to a directory containing a `mod.nu` file:

::: details Example

Expand All @@ -69,25 +69,39 @@ The path to the module can be:
Note that the module name (its directory) can end in a `/` (or `\` on Windows), but as with most commands that take a paths (e.g., `cd`), this is completely optional.
:::

::: important Important! Importing modules from `$env.NU_LIB_PATH`
::: important Important! Importing modules from `$env.NU_LIB_DIRS`
When importing a module via a relative path, Nushell first searches from the current directory. If a matching module is not found at that location, Nushell then searches each directory in the `$env.NU_LIB_DIRS` list.

This allows you to install modules to a location that is easily accessible via a relative path regardless of the current directory.
:::

- An absolute or relative path to a Nushell module file. As above, Nushell will search the `$env.NU_LIB_DIRS` for a matching relative path.
- An absolute path to a Nushell module file:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did have "absolute" and "relative" split out originally, but I combined them since there is so much duplicated wording in the "split" version. While I think it's better combined, I can certainly see reasons for splitting relative/absolute into separate bullets as well. However, if we split them, then (a) We should move "relative" above "absolute" since it is the most common form. And (b) I would recommend not duplicating the entire "Important" block - Just reference it the second time, rather than repeating it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before the fixup, the first two was split and the second was combined. I think that asymmetry should be solved, one way or another.

I agree with order should be relative before absolute

I prefer self-sufficient explanations, without pointing to earlier sections. I would prefer duplication over pointing elsewhere, especially if it's not a anchor jump link

Given the noteworthy concerns, maybe it makes more sense to combine the two absolute and the two relative blocks? 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before the fixup, the first two was split and the second was combined
Given the noteworthy concerns, maybe it makes more sense to combine the two absolute and the two relative blocks?

Ah - I think I had a good reason for it, but I also agree with you on the symmetry. I'll take another look at it, but it might be a few hours.

Copy link
Contributor Author

@Kissaki Kissaki Nov 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with leaving it as it was. Personally, I like reference documentation. But this is a "book". So I'm reminding myself that the form is more of a read-in-order thing where reading order and block-cross-references can be expected. Unfortunately, there's no reference then though. :)

The list is also quite long. So reducing the number of items is a good idea if not necessary.


::: details Example

```nu
use ~/nushell/modules/std-rfc/bulk-rename.nu
# Or
```

:::

- A relative path to a Nushell module file:

::: details Example

```nu
cd ~/nushell/modules
use std-rfc/bulk-rename.nu
```

:::

::: important Important! Importing modules from `$env.NU_LIB_DIRS`
When importing a module via a relative path, Nushell first searches from the current directory. If a matching module is not found at that location, Nushell then searches each directory in the `$env.NU_LIB_DIRS` list.

This allows you to install modules to a location that is easily accessible via a relative path regardless of the current directory.
:::

- A virtual directory:

::: details Example
Expand All @@ -100,7 +114,7 @@ The path to the module can be:

:::

- Less commonly, the name of a module already created with the [`module`](/commands/docs/module.md) command. While it is possible to use this command to create a module at the commandline, this isn't common or useful. Instead, this form is primarily used by module authors to define a submodule. See [Creating Modules - Submodules](./creating_modules.md#submodules).
- Less commonly, the name of a module is created with the [`module`](/commands/docs/module.md) command. While it is possible to use this command to create a module at the commandline, this isn't common or useful. Instead, this form is primarily used by module authors to define a submodule. See [Creating Modules - Submodules](./creating_modules.md#submodules).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This results in a grammatically incorrect sentence flow. Keep in mind that the sentence leading into this list is "The path to a module can be", so the sentence has now gone from:

The path to a module can be ... Less commonly, the name of a module already created with the module command.

to:

The path to a module can be ... the name of a module is created with the module command.

However, I agree the original can be improved a bit. How about:

Suggested change
- Less commonly, the name of a module is created with the [`module`](/commands/docs/module.md) command. While it is possible to use this command to create a module at the commandline, this isn't common or useful. Instead, this form is primarily used by module authors to define a submodule. See [Creating Modules - Submodules](./creating_modules.md#submodules).
- Less commonly, the name of a module that was previously created with the [`module`](/commands/docs/module.md) command. While it is possible to use this command to create a module at the commandline, this isn't common or useful. Instead, this form is primarily used by module authors to define a submodule. See [Creating Modules - Submodules](./creating_modules.md#submodules).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, you mean to say the list intro "The path to the module can be:" is continued in this sentence?

That's 74 code lines, or four list items each with code block and two warning notice blocks above here. I don't think that can still be considered "sentence flow". A list that is not a list of one-liners should have self-sufficient bullet points / bullet point sections.

I certainly see why I didn't realize what the sentence was referring to / that there's a pre-text to it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see how the other points use that sentence flow so it wouldn't make sense to do that differently here. But I don't think how it was was clear with how distant the whole thing is.

Copy link
Contributor Author

@Kissaki Kissaki Nov 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your suggestion clarifies it quite well. But maybe now I'm just aware of the context. Dunno. It seems like it should have the same issue for me, but it doesn't when I read it now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lol - I get it. Yes, "sentence flow" may not be as accurate a description as "consistent bullet styles" (which I'm also okay sometimes deviating from when necessary). Feel free to commit the suggestion if you'd like. Or spend the night on it and see how it looks in the morning ;-).

Copy link
Contributor Author

@Kissaki Kissaki Nov 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the list item should begin in the same form as the others.

Suggested change
- Less commonly, the name of a module is created with the [`module`](/commands/docs/module.md) command. While it is possible to use this command to create a module at the commandline, this isn't common or useful. Instead, this form is primarily used by module authors to define a submodule. See [Creating Modules - Submodules](./creating_modules.md#submodules).
- An already defined module: The [`module` command](/commands/docs/module.md) can define a module. It is primarily used by module authors to define a submodule. See [Creating Modules - Submodules](./creating_modules.md#submodules). It is not usually used to define "normal" modules.

Dunno about the last sentence. "normal" module? root level? "main modules"? "Not usually used", "not commonly used", "we recommend against using it to …"?

Suggested change
- Less commonly, the name of a module is created with the [`module`](/commands/docs/module.md) command. While it is possible to use this command to create a module at the commandline, this isn't common or useful. Instead, this form is primarily used by module authors to define a submodule. See [Creating Modules - Submodules](./creating_modules.md#submodules).
- An already defined module: The [`module` command](/commands/docs/module.md) can define a module. We recommend against using it to define modules. It is primarily used by module authors to define a submodule. See [Creating Modules - Submodules](./creating_modules.md#submodules).

What do you think?


### Module Definitions

Expand Down Expand Up @@ -193,7 +207,7 @@ assert true
# => Assertion passes

hide assert
assert equal 1 1
assert equal 1 2
Kissaki marked this conversation as resolved.
Show resolved Hide resolved
# => Error:
# => help: A command with that name exists in module `assert`. Try importing it with `use`

Expand All @@ -208,7 +222,7 @@ Just as you can `use` a subset of the module's definitions, you can also `hide`
```nu
use std/assert
hide assert main
assert equal 1 1
assert equal 1 2
Kissaki marked this conversation as resolved.
Show resolved Hide resolved
# => assertion passes

assert true
Expand All @@ -217,11 +231,11 @@ assert true
```

::: tip
`main` is covered in more detail in [Creating Modules](./creating_modules.md#main-exports), but for end-users, `main` simply means "the command named the same as the module." In this case the `assert` module exports a `main` command that "masquerades" as the `assert` command. Hiding `main` has the effect of hiding the `assert` command, but not its subcommands.
`main` is covered in more detail in [Creating Modules](./creating_modules.md#main-exports), but for end-users, `main` means "the command named the same as the module." In this case the `assert` module exports a `main` command that "masquerades" as the `assert` command. Hiding `main` has the effect of hiding the `assert` command, but not its subcommands.
Kissaki marked this conversation as resolved.
Show resolved Hide resolved
:::

## See Also

- To make a module always be available without having to `use` it in each Nushell session, simply add its import (`use`) to your startup configuration. See the [Configuration](../configuration.md) Chapter to learn how.
- To make a module always be available without having to `use` it in each Nushell session, add its import (`use`) to your startup configuration. See the [Configuration](../configuration.md) Chapter to learn how.

- Modules can also be used as part of an [Overlay](../overlays.md).