feat: nupm registry subcommand

.editorconfig

@@ -0,0 +1,9 @@
+root = true
+
+[*]
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+indent_style = space
+indent_size = 4

docs/design/README.md

@@ -1,8 +1,8 @@
-# Design of `nupm` :warning: Work In Progress :warning: 
+# Design of `nupm` :warning: Work In Progress :warning:
 
 This file collects design ideas and directions. The intention is iterate on this document by PRs with discussion.
 
-> **Note**  
+> **Note**
 > in the following, until we settle down on precise names, we use the following placeholders:
 > - `METADATA_FILE`: the file containing the metadata of a package,
 > e.g. `project.nuon`, `metadata.json` or `nupm.nuon`
@@ -13,7 +13,7 @@ This file collects design ideas and directions. The intention is iterate on this
 # Table of content
 - [Project Structure](#project-structure-toc)
 - [Separate virtual environments](#separate-virtual-environments-toc)
-- [Installation, bootstraping](#installation-bootstraping-toc)
+- [Installation, bootstrapping](#installation-bootstrapping-toc)
 - [Dependency handling](#dependency-handling-toc)
 - [Package repository](#package-repository-toc)
 - [API / CLI Interface](#api--cli-interface-toc)
@@ -24,7 +24,7 @@ This file collects design ideas and directions. The intention is iterate on this
 
 A `nupm` project is defined by `METADATA_FILE`.
 This is where you define name of the project, version, dependencies, etc., and the type of the project.
-> **Note**  
+> **Note**
 > see [`METADATA.md`](references/METADATA.md) for a more in-depth description of
 > the `METADATA_FILE`
 
@@ -73,17 +73,17 @@ The overlays could be used to achieve all three goals at the same time. When ins
 * This file can be installed into a global location that's in your `NU_LIB_DIRS` (e.g., `NUPM_HOME/overlays`) -- now you have a global Python-like virtual environment
   * Each overlay under `NUPM_HOME/overlays` will mimic the main NUPM_HOME structure, e.g., for an overlay `spam` there will be `NUPM_HOME/overlays/spam/bin`, `NUPM_HOME/overlays/spam/modules` (`NUPM_HOME/overlays/spam/overlays`? It might not be the best idea to have it recursive)
 
-Each package would basically have its own overlay. This overlay file (it's just a module) could be used to also handle dependencies. If your project depends on `foo` and `bar` which both depend on `spam` but different versions, they could both import the different verions privately in their own overlay files and in your project's overlay file would be just `export use path/to/foo` and `export use path/to/bar`. This should prevent name clashing of `spam`. The only problem that needs to be figured out is how to tell `foo` to be aware of its overlay.
+Each package would basically have its own overlay. This overlay file (it's just a module) could be used to also handle dependencies. If your project depends on `foo` and `bar` which both depend on `spam` but different versions, they could both import the different versions privately in their own overlay files and in your project's overlay file would be just `export use path/to/foo` and `export use path/to/bar`. This should prevent name clashing of `spam`. The only problem that needs to be figured out is how to tell `foo` to be aware of its overlay.
 
-## Installation, bootstraping [[toc](#table-of-content)]
+## Installation, bootstrapping [[toc](#table-of-content)]
 
 Requires these actions from the user (this should be kept as minimal as possible):
 * Add `NUPM_HOME/bin` to PATH (install location for binary projects)
 * Add `NUPM_HOME/modules` to NU_LIB_DIRS
 * Add `NUPM_HOME/overlays` to NU_LIB_DIRS
 * Make the `nupm` command available somehow (e.g., `use` inside `config.nu`)
 
-> :warning: **WIP**  
+> :warning: **WIP**
 > The disadvantage of this is that the default install location is not an overlay. We could make `nupm` itself an overlay that adds itself as a command, so that you can activate/deactivate it. We might need a few attempts to get to the right solution.
 
 There are several approaches:
@@ -98,7 +98,7 @@ There are several approaches:
 In compiled programming languages, there are two kinds of dependencies: static and dynamic. Static are included statically and compiled when compiling the project,
 dynamic are pre-compiled libraries linked to the project.
 
-> **Note**  
+> **Note**
 > Nushell is [similar to compiled languages][Nushell compiled] rather than typical dynamic languages like Python, so these concepts are relevant for Nushell.
 
 Static dependencies:
@@ -120,7 +120,7 @@ as long as it has `METADATA_FILE` telling `nupm` what to do.
 
 Nushell's module design conflates CLI interface with API -- they are the same. Not all of the below are of the same priority.
 
-> **Note**  
+> **Note**
 > commands like `list`, `install`, `search`, `uninstall`, `update`, ..., i.e. should
 > - print short descriptions by default
 > - print long descriptions with `--long-description (-l)`
@@ -161,7 +161,7 @@ Nushell's module design conflates CLI interface with API -- they are the same. N
     - publish package to a repository
     - **NOT SUPPORTED FOR NOW**: the repository will be a *GitHub* repo with packages submitted by PRs to start with
 
-The following are for Python-style global overlays, we might need to re-think this for local package overlays: 
+The following are for Python-style global overlays, we might need to re-think this for local package overlays:
 - `nupm overlay new`
     - create a new global overlay (Python's virtual environment style)
     - `--local` flag could generate an overlay locally from the currently opened project
@@ -178,7 +178,7 @@ The following are for Python-style global overlays, we might need to re-think th
 ### Other CLI-related notes [[toc](#table-of-content)]
 
 * We could later think about being able to extend `nupm`, like `cargo` has plugins.
-* Mutable actions (like install) have by default Y/n prompt, but can be overriden with `--yes`
+* Mutable actions (like install) have by default Y/n prompt, but can be overridden with `--yes`
 * By default, new projects are cross-platform:
     * Windows
     * MacOS

docs/design/registry.md

@@ -92,7 +92,7 @@ _See the new `registry/` directory, the following example slightly differs from
 
 It is possible to only publish to a registry stored on your file system because we don't have a web service or anything like that.
 
-The intented workflow for publishing a package is:
+The intended workflow for publishing a package is:
 1. Check out the git repository with the registry
 2. `cd` into the package you want to publish
 3. Run `nupm publish chosen_registry` to preview the changes

nupm/install.nu

@@ -1,7 +1,7 @@
 use utils/completions.nu complete-registries
 use utils/dirs.nu [ nupm-home-prompt cache-dir module-dir script-dir tmp-dir ]
 use utils/log.nu throw-error
-use utils/misc.nu [check-cols hash-fn url]
+use utils/misc.nu [check-cols hash-fn url flatten-nupm-env]
 use utils/package.nu open-package-file
 use utils/registry.nu search-package
 use utils/version.nu filter-by-version
@@ -105,6 +105,7 @@ def install-path [
             let tmp_dir = tmp-dir build --ensure
 
             do {
+                flatten-nupm-env
                 cd $tmp_dir
                 ^$nu.current-exe $build_file ($pkg_dir | path join 'nupm.nuon')
             }

nupm/mod.nu

@@ -2,15 +2,19 @@ use std/log
 
 use utils/dirs.nu [
     DEFAULT_NUPM_HOME DEFAULT_NUPM_TEMP DEFAULT_NUPM_CACHE
-    DEFAULT_NUPM_REGISTRIES nupm-home-prompt
+    DEFAULT_NUPM_REGISTRIES DEFAULT_NUPM_INDEX_PATH nupm-home-prompt
 ]
 
+use utils/registry.nu open-index
+
 export module install.nu
 export module publish.nu
+export module registry.nu
 export module search.nu
 export module status.nu
 export module test.nu
 
+
 export-env {
     # Ensure that $env.NUPM_HOME is always set when running nupm. Any missing
     # $env.NUPM_HOME during nupm execution is a bug.
@@ -22,12 +26,12 @@ export-env {
     # Ensure install cache is set
     $env.NUPM_CACHE = ($env.NUPM_CACHE? | default $DEFAULT_NUPM_CACHE)
 
-    # TODO: Maybe this is not the best way to set registries, but should be
-    #       good enough for now.
-    # TODO: Add `nupm registry` for showing info about registries
-    # TODO: Add `nupm registry add/remove` to add/remove registry from the env?
-    $env.NUPM_REGISTRIES = ($env.NUPM_REGISTRIES?
-        | default $DEFAULT_NUPM_REGISTRIES)
+    # check for the index path
+    $env.NUPM_INDEX_PATH = ($env.NUPM_INDEX_PATH? | default $DEFAULT_NUPM_INDEX_PATH)
+
+    # read from registry index but don't overwrite registires already present in $env.NUPM_REGISTRIES
+    $env.NUPM_REGISTRIES = ($env.NUPM_INDEX_PATH | open-index
+        | merge ($env.NUPM_REGISTRIES? | default $DEFAULT_NUPM_REGISTRIES))
 
     use std/log []
 }