The above options are more or less self-explanatory with the exception of `local`. `local` will install a module that you have on your system, but not on the slope module path. This is useful if, for example, a person has made their module available but it is not in the slp registry. In which case you can clone their repo and run `slp local ~/path/to/their-module`. Once installed in this manner the slp `remove`, `installed`, and `docs` commands will be able to operate on the module based on its folder name. `update`, however, requires the registry to know what git tag is the current/newest tag.
Operations that accept a -g flag will attempt to install a module systemwide (this may require root access). A --global flag may be passed in lieu of a -g flag if desired for clarity.
The install location for global modules is: /usr/lib/slope/modules
Globals modules must be dealt with separately from local modules and cannot be combined in a single command.
Note that early versions of slope to not search the global module path. If you have installed modules globally on your system and are unable to use `load-mod` to access them: update your slope version.
## Adding new packages
Packages can be registered in the repository at [https://git.rawtext.club/slope-lang/packages](slope-lang/packages) by submitting a PR to that repository. If you are unsure of how to proceed feel free to open an issue at said repository instead, with a link to your module's source code.
_A note on module versioning_: At present, **slp** does not handle any versioning and will always grab the newest version of a module, while `update` will always update to the newest. There are plans in place to declare a module release via the release's tag value: `module-name@tag` (ex. ini@0.2.1). Stay tuned for an announcement that that has been added. In the meantime: good fortune and safe journeys in the wilderness.