You can also add a folder where you keep your development quarks (your own and things you have forked):

Now each quark inside that folder will appear on the GUI for you to un/install.

If you wish to be able to uninstall local quarks, but still see them in the GUI, it is highly recommended to collect your local quark directories under a single master directory. Then, use Quarks: *addFolder to add the master directory. addFolder does not add individual quark directories.

To make project work simpler you can save and later reload your currently installed Quarks to and from a quarks.txt file. This is similar to what the LanguageConfig does but this also downloads the Quarks if needed and installs all dependencies.

This is very useful for projects because you can pin the exact releases of each Quark that your project depends on and you should be able to reload them exactly even years in the future.

This saves both what quarks you have and what git revision they are on. If you have uncommitted changes in one of the quarks then it will warn you that its dirty.

The save format specifies the revisions using git tags with a fall back to the full sha hash that specifies the revision. In git terminology this is known as a refspec.

If you have installed local paths that are not under git source control (your own work or things you have downloaded) then the paths will be saved without any version or refspec.

The file format looks like this:

Note that in this case `quarkname` was checked out to the tag 4.1.4, and `ddwCommon` was not on a tag so the refspec is the SHA hash. In both cases this results in an exact reference. `~/supercollider/quarks/my-thing` was not a git repo so the best it can do is to specify the path.

Even if a quark was installed by name using the directory, the full repository URL will be saved to ensure that the reference is unvarying (the directory.txt could be edited and the URL changed, and that might then point to different source code).

Any packages not under git source control are specified by path, abbreviated to the most logical path relative to the quark file, the home directory or by absolute path. They do not have a version or refspec.

Or create a folder where you do your development work and add that to the additional folders:

Now you can (un)install your own packages from your local folder.

Managing your code with git is optional, but you should consider using it early on. Even if you do not intend to share your code with anyone else, git provides a backup system and a time machine if you break something.

Bitbucket offers free hosting for private repositories, and you can setup your own git host on any machine that you have SSH access to. But you don't even need an externally hosted repository to use git.

Hard drives die, backups fail, people make mistakes. If you keep a copy on bitbucket then your work is that much safer.

Make a git repository and push it to github, bitbucket or any publicly accessible git host.

tag your releases. The name of the tag is the name of the release version. Using semver (eg "1.0.1") is recommended. This provides the Quarks system with a way to list versions in the interface and to checkout a version and for people to pin dependencies to a stable release. it also provides a downloadable version on your github releases page.

Contact me to transfer ownership to your own github account. You may also just fork any repo there, or if you've already moved your code to github then just edit the directory to point to your preferred newer version.

Quarks with spaces in the name had to have those spaces removed. Quarks nested inside other quarks (dewdrop_lib) are now un-nested.

Releases are specified with a git tag which refers to a specific commit regardless of what branch it is on. The default branch is master, but the branch does not really matter, only the tag. If you are not tagging specific releases then Quarks will fetch the master branch.

The quark file is a SuperCollider code file containing authorship, version, copyright and dependency information. It is optional but recommended. None of the fields are required and you may include any custom fields you like.

The most important feature is to specify dependencies, version, summary and to specify the help file.

It's similar to the package.json file in npm (JavaScript package manager) or bower.json for Bower (web/frontend package manager).

The file name is the name of the quark followed by the .quark extension:

and is a SuperCollider file that returns an IdentityDictionary

Common fields

name

summary

author

copyright

license - default is GPL

version - semver compatible string is preferred eg. "1.0.0"

schelp - title of the primary help file

url - home page, defaults to the github/bitbucket url

dependencies - see below

isCompatible - a function returning a Boolean. Can check for presence of classes, features, version numbers.