Adds slp and module details to readme

master
sloum 2 years ago
parent fc2fccc1f2
commit 557d8a544f

@ -466,7 +466,7 @@ Unlike modules, arbitrary code execution will occur with preloads (not just `def
## Modules
slope has a very basic module system. When you use the `load` procedure you are loading a single file from a given path. Anything in that file will be run when it is loaded. Using `load-mod` allows you to load a module from a designated location on your system by simply passing the module's name (as represented by the directory name it is contained within).
slope has a basic module system. When you use the `load` procedure you are loading a single file from a given path. Anything in that file will be run when it is loaded. Using `load-mod` allows you to load a module from a designated location on your system by simply passing the module's name (as represented by the directory name it is contained within).
`load-mod` will load modules from the first non-empty-string value it finds out of these options:
@ -476,7 +476,10 @@ slope has a very basic module system. When you use the `load` procedure you are
So, a hypethetical module named `test` would be found at `~/.local/share/slope/modules/test`.
A separate tool is coming soon to help manage acquiring/removing/viewing modules as well as dealing with subdependencies. Until then it is a more manual process.
### slp
slope has a package manager available at [https://git.rawtext.club/slope-lang/slp](https://git.rawtext.club/slope-lang/slp). Once installed you will be able to search/browse packages, install, remove, and update things, generate new module skeletons, read docs, etc. The slp repository has information on how to get modules added to the package registry. This is, at present, the best way to deal with modules and is highly recommended but by no means required. The same thing can be done by finding a repository with a module and cloning it to your module path. So long as it is a valid module it will be loadable with `load-mod`.
### How Modules are Processed
@ -496,10 +499,11 @@ Taking our above example of a module named `test`, the bare minimum that the fol
You may, optionally, have other code files present in the module and can load them by calling `load-mod-file`. This procedure should be given a path relative to the module root directory. So within our `main.slo` file we might call something like: `(load-mod-file "./submodules/unit-tests.slo")`. Something to note is that a call to `load-mod-file` cannot jump out of the module's root directory (doing something like `../../../some-other-code.py` or `/etc/something` will result in a runtime panic).
#### module.info
#### module.json
Another special file that is not yet in use, but is planned, is `module.info`. This file will contain details about the module: name, dependencies, repo url, description, version number, commit-hash, license, etc. This will be used by an eventual tool that will manage modules and dependencies.
Modules found in the package registry will include this file. It contains metadata related to the package including things like description, version, repository url, homepage, author, and, most importantly the dependency list (so that a modules dependencies can also be installed).
If you are making a module and do not know what should be here you can look at an existing module to get a sense of it. Or, with `slp` installed, you can just run `slp gen` and it will build out your module skeleton for you.
## Building

Loading…
Cancel
Save