Quark folder structure

NewQuark/
├── Assets
│   └── new_sound.wav
├── Classes
│   └── NewClass.sc
├── HelpSource
│   └── NewClass.scdoc
├── Platform
│   └── Plugins
│       └── new_quark_ugens-0.9-scsynth-3.13a-osx-14-arm64.scx
├── Tests
│   └── NewQuark_test.scd
└── baryon.yaml

/Assets Large non-code asset files. These will usually not be stored in git.

/Examples .scd files

/Classes .sc files

/HelpSource .scdoc files

/Platform All platform-specific install files, e.g. server plugins or executables. Installed on-request by the local CLI, which has the choice to pull binaries for whichever platforms it wishes (e.g. arm64 AND x86). Binary files are named according to: {name}-{version}-{runtime}-{runtime_version}-{platform}-{platform_version}-{architecture} ... where "runtime" refers to scsynth or supernova for server plugins.

/Tests Test classes and test scd files. .scd files will be assumed to be unit tests for automated testing purposes.

Repository folder structure

Repository/
└── flucoma
    ├── 1.0
    ├── 0.9
    └── 0155a28dd878fd030d4a81a77a81f4cffaa32210

A repository is a persistant cache of quark packages. It's a cache in the sense that it should not contain content that cannot easily be synced again (e.g. edited files). Its persistant in that sclang_conf.yaml files will point includes to these paths.

In general, there will be a default "global" repository (e.g. in ~/.baryon/repository), but this is a runtime flag / setting which can be set for each command. This would allow e.g. making project-local repositories of all requirements, or projects and their dependencies together on an external drive.

Settings

Settings are loaded according to:

 Default settings -> Global settings -> Workspace Settings -> Env Settings -> Cmd Line Flags

Default settings are defined in-code or calculated based on e.g. system context details.

Global settings are search for at e.g.: ~/.baryon/baryon_settings.hyml

Workspace settings are searched adjacent to the current baryon.yaml file: MyProject/.baryon_settings.yaml

Env settings are taken from environment variable overrides for some settings, e.g. GLOBAL_REPOSITORY_PATH=/my/new/path baryon install

Cmd line flags come from command line options for a given command: baryon install --repository-path=/my/custom/repo

Settings example:

repository_path: ~/.baryon/repository
use_local_repo: false
use_sclang: /path/to/sclang

Commands

baryon add {package-name} {version-spec}: Add a dependency. Could be global or local. baryon install {package-name}: Install all dependencies in the repo and add to sclang_conf (install only one if name is specified). Could be global or local. baryon info {package-name}: info about a specific package, including local install details baryon lock: lock dependencies and produce a lock file baryon list: nice list of all packages, including installation status baryon update {package-name}: recalculate dependencies with newest possible versions (for one package or all) baryon package {output.zip}: Assemble a packaged version of this quark and zip baryon upgrade_legacy {git_path}: Given a git repository, produce a set of "legacy" package releases based on the quark file, that can be used to install this quark via Baryon.

Baryon project file

baryon_version: 1.0

name: Lucid
version: 0.1.0
description: A lucid state orchestration toolkit.
authors: Astra Nomikos <[email protected]>
license: MIT
url: "https://example.com/Lucid"
repo: "https://github.com/astra/Lucid
help: "Lucid Main SCDoc Help File"

dependencies:
  - name: SCClassLibrary
    version: "<=3.13, >3.10"
  - git: http://github.com/...
    tag: "3.0.2"
  - name: FastCoding
    version: "<=3.0, >=2.0"
    repo: https://custom-baryon-repo.com/

SuperCollider components

SuperCollider component dependencies will be specified the same as other dependencies. In some install contexts, SuperCollider components versions will be fixed (e.g. "this is the SuperCollider version i am using") and dependency specs will only be used for constraint solving (e.g. "find a version of this package that works with sclang 13.10").

In other cases, installing SuperCollider components could be a part of the total installation (e.g. I am handed a project and need to install everything, including appropriate SuperCollider components).

Most components will only depend on SCClassLibrary. Server components will depend on SCServer. It is PROBABLY unwise to specify dependencies for supernova and scsynth separately, since these are in theory swappable implementations?

dependencies:
  - name: sclang-runtime
    version: 3.13
  - name: SCClassLibrary
    version: 3.13
  - name: SCCoreUGens
    version: 3.13
  - name: SC3Plugins
    version: 3.13
  - name: SCServer
    version: 14

sclang_conf.yaml

Probably automated baryon includes should be commented to make it easier to amend them later, avoid accidentally overwriting user-specified include paths?

includes:
  - /path/to/repo/flucoma/3.4                 # baryon: [email protected]
  - /path/to/repo/jitextensions/1.0           # baryon: [email protected]

Legacy Quarks

Dependencies on legacy quarks can be specified by a legacy: true flag in the dependency. When resolving any dependency with a legacy flag:

IF the dependency has baryon package releases (resolved by either package name or git url): resolve using baryon, and warn the user that the legacy flag is no longer needed.
IF there are no baryon releases, the legacy dependency needs to be converted to a direct git dependency
1. All quark file versions from the history of the project are collected.
2. Each is converted to a proxy baryon package....
  1. For each dependency in the quark file, if there are proper baryon releases, just turn this into a regular baryon dependency as best as possible.
  2. If there's no baryon release, then turn this into a legacy: true dependency.
3. Proxy baryon releases should be cached locally, because they are expensive to calculate. Possibly we can pre-fill this cache so the legacy dance doesn't need to happen for most commonly used quarks.

scztt/baryon-notes.md