Home Explore Blog CI



nushell

5th chunk of `book/modules/creating_modules.md`
ac864db1b014a7cf3cb905988019c3f782dc4049b852eafa0000000100000c54
Attempting to import a module's environment within another environment may not work as expected. Let's create a new module `go.nu` that creates "shortcuts" to common directories. One of these will be the `$env.NU_MODULES_DIR` defined above in `my-utils`.

We might try:

```nu
# go.nu, in the parent directory of my-utils
use my-utils

export def --env home [] {
    cd ~
}

export def --env modules [] {
    cd $env.NU_MODULES_DIR
}
```

And then import it:

```nu
use go.nu
go home
# => Works
go modules
# => Error: $env.NU_MODULES_DIR is not found
```

This doesn't work because `my-utils` isn't _evaluated_ in this case; it is only _parsed_ when the `go.nu` module is imported. While this brings all of the other exports into scope, it does not _run_ the `export-env` block.

::: important
As mentioned at the start of this chapter, trying this while `my-utils` (and its `$env.NU_MODULES_DIR`) is still in scope from a previous import will _not_ fail as expected. Test in a new shell session to see the "normal" failure.
:::

To bring `my-utils` exported environment into scope for the `go.nu` module, there are two options:

1. Import the module in each command where it is needed

   By placing `use my-utils` in the `go home` command itself, its `export-env` will be _evaludated_ when the command is. For example:

   ```nu
   # go.nu
   export def --env home [] {
       cd ~
   }

   export def --env modules [] {
       use my-utils
       cd $env.NU_MODULES_DIR
   }
   ```

2. Import the `my-utils` environment inside an `export-env` block in the `go.nu` module

   ```nu
   use my-utils
   export-env {
       use my-utils []
   }

   export def --env home [] {
       cd ~
   }

   export def --env modules [] {
       cd $env.NU_MODULES_DIR
   }
   ```

   In the example above, `go.nu` imports `my-utils` twice:

   1. The first `use my-utils` imports the module and its definitions (except for the environment) into the module scope.
   2. The second `use my-utils []` imports nothing _but_ the environment into `go.nu`'s exported environment block. Because the `export-env` of `go.nu` is executed when the module is first imported, the `use my-utils []` is also evaluated.

Note that the first method keeps `my-utils` environment inside the `go.nu` module's scope. The second, on the other hand, re-exports `my-utils` environment into the user scope.

### Module files and commands cannot be named after parent module

A `.nu` file cannot have the same name as its module directory (e.g., `spam/spam.nu`) as this would create an ambiguous condition with the name being defined twice. This is similar to the situation described above where a command cannot have the same name as its parent.

## Windows Path Syntax

::: important
Nushell on Windows supports both forward-slashes and back-slashes as the path separator. However, to ensure that they work on all platforms, using only the forward-slash `/` in your modules is highly recommended.
:::

## Additional Examples

### Local Definitions

As mentioned above, definitions in a module without the [`export`](/commands/docs/export.md) keyword are only accessible in the module's scope.

Title: Resolving Environment Import Issues and Other Considerations
Summary
The chunk addresses the issue of importing a module's environment within another module in Nushell, where the `export-env` block isn't executed during parsing. It presents two solutions: importing the module in each command where the environment is needed, or importing the module's environment within an `export-env` block. It also covers that a module file cannot have the same name as its parent module directory and recommends using forward-slashes for Windows paths to ensure cross-platform compatibility. Finally, it briefly touches on local definitions within modules.