Main package list for the slope language's package manager, slp
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

3.0 KiB

slope package registry

This is the slope package registry. To have a package added:

  • fork this repo (if you do not already have a fork of it)
  • add your module's json to packages.json within your forked 'packages' repo, following the instructions below
  • commit your changes in your module, including a tag name or version number in the module.json file
    • You wont have made the tag yet, so add the name that you will use for the tag and then commit the changes
  • if you used a tag and commited the changes, be sure to add and push the tag
    • git tag my-tag-name, replacing my-tag-name with the name of your tag
    • git push origin my-tag-name, replacing my-tag-name with the name of your tag
  • make a pull request into the master branch of this repository from your forked version
    • This will be done in the Pull Requests section of the git.rawtext.club website for your fork of packages

When your pull request is approved (which it will be if the required json fields are present and your repository is a valid module) the package registry will be updated and slp will be able to pull in your code.

Package format

Your module should have, at a minimum, the following two files:

  • main.slo
  • module.json

A module skeleton with these files can be generated for you by running slp gen (assuming slp is on your $PATH).

main.slo

This is the main code file that will be loaded by (load-mod "module-name") (where "module-name" is your module's name). Any other files that are a part of the module should be loaded from this file via (load-mod-file "./some-other-file.slo"). As stated in the slope documentation arbitrary code will not be run, but definitions will be loaded.

module.json

This is the most important file for the purposes of this package registry. It should contain the following:

Here is an example:

{
	"title": "dlgs",
	"description": "GUI system dialogs for nix systems",
	"author": "sloum",
	"version": "0.1.0",
	"homepage": "",
  "tag": "v0.1.0",
	"repository": "https://git.rawtext.club/sloum/dlgs",
	"dependencies": []
}

The required fields are:

  • title
    • the name of the module as people will import it
  • description
    • a short 60 char or less description of the module
  • author
    • your name or alias
  • at least one out of:
    • version
      • an arbitrary version string decided on by you
    • tag
      • a git tag that has been added to your repository for a given commit
  • repository (the url to the repo holding the code)

If you have dependencies, they should be listed as strings within the dependency array. So, if you require the csv module for your module to function, your dependencies would look like this:

	"dependencies": ["csv"]

If you include a tag that is a valid git tag within your module then that tag will be checked out. This makes updates work smoother. However, if you just want people to always work off of whatever is current you can just change the version string and people will still see changes, though it will be less specific.