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.