repository·main·Indexed 23 days ago
https://github.com/alexykn/spsA Rust-powered package manager for macOS ARM architecture, inspired by Homebrew. It manages Formulae (CLI tools, libraries, languages) and Casks (desktop applications). The project includes the sps-common crate, which provides functionality for dependency resolution via DependencyResolver, cache management using the Cache struct, and installed package tracking through the KegRegistry.
To build the sps binary from the source repository, ensure you have a stable Rust toolchain installed. After building, the binary will be located in target/release/sps. You should add this path to your PATH environment variable to use the command globally.
git clone <repo-url>
cd sps
cargo build --releaseThe sps CLI allows you to manage Formulae (command-line tools, libraries, languages) and Casks (macOS desktop applications).
Note: Currently, sps supports ARM only.
You can install sps using cargo install. Note that the crates.io version may not always reflect the absolute latest changes due to update frequency.
cargo install spsTo use the most recent nightly builds, download the artifacts from the GitHub Actions workflow (actions/workflows/rust.yml). Select a successful build, download the artifact, extract it, and run the binary directly.
./sps --helpYou can control the amount of output and logging detail using the --verbose flag (or its equivalent in the CLI arguments). The verbosity levels affect both the console output and the log files written to the configured log directory.
INFO level logging.DEBUG level logging.TRACE level logging.When verbosity is greater than 0, logs are also written to a rolling daily file named sps.log in the configured logs directory.
A job in the sps pipeline moves through several states. Understanding these states is essential for implementing custom runners or monitoring tools:
PendingDownload: Waiting for the download to start.Downloading: Download is currently in progress.Downloaded(PathBuf): Download finished; the artifact is at the provided path.WaitingForDependencies(PathBuf): Artifact is ready, but waiting for required dependencies to succeed.DispatchedToCore(PathBuf): Job has been sent to the core worker pool.Installing(PathBuf): Installation/processing is actively being performed by a worker.Succeeded: The job completed successfully.Failed(Arc<SpsError>): The job failed with the provided error.pub enum JobProcessingState {
PendingDownload,
Downloading,
Downloaded(PathBuf),
WaitingForDependencies(PathBuf),
DispatchedToCore(PathBuf),
Installing(PathBuf),
Succeeded,
Failed(Arc<SpsError>),
}The pipeline execution engine determines if a target (Formula or Cask) can proceed by checking its dependencies against two sources: the current job_states and the ResolvedGraph.
To return true (success), every dependency must meet one of these criteria:
job_states with the state JobProcessingState::Succeeded.ResolvedGraph with a ResolutionStatus::Installed status.If a dependency is in a Failed state, or if it is neither succeeded nor pre-installed, the target's dependency check fails.
The NodeInstallStrategy determines the installation method for a formula and influences how its dependencies are resolved.
BottlePreferred: Attempts to use a pre-built bottle if available via has_bottle_for_current_platform. If no bottle is available, it falls back to SourceOnly.SourceOnly: Always builds from source.BottleOrFail: Attempts to use a bottle; if no bottle is available, the resolution fails.When a parent formula is resolved with a specific strategy, it affects its children via should_process_dependency_edge:
BottlePreferred or BottleOrFail: Pure BUILD dependencies (those that do not intersect with RUNTIME, RECOMMENDED, or OPTIONAL tags) are skipped. This is because a bottle-installed package typically does not require its build-time dependencies to be present in the runtime environment.SourceOnly: All relevant dependencies (based on global context filters) are processed.When a Cask contains a dictionary stanza in its artifacts definition, sps installs it by moving the declared .dictionary bundles from the staging area to the standard macOS user dictionary directory: ~/Library/Dictionaries.
To maintain traceability within the Caskroom, sps also creates a symlink in the cask_version_install_path that points back to the bundle in the user's Library directory. This behavior mimics the Homebrew Ruby definition class Dictionary < Moved; end.
The OCI utilities determine authentication based on the provided Config object. The priority for authentication is:
config.docker_registry_token is set, it uses Authorization: Bearer <token>.config.docker_registry_basic_auth is set, it uses Authorization: Basic <encoded_string>.ghcr.io (or the default domain) and no explicit credentials are provided, the client attempts to fetch an anonymous token from the registry's token endpoint (e.g., https://ghcr.io/token) for the specific repository scope.Authorization header.When upgrading a macOS application, sps avoids the standard 'remove and symlink' pattern used for fresh installs. Instead, it employs a Direct Overwrite Strategy (similar to Homebrew):
~/Library./Applications is removed via sudo rm -rf./Applications using sudo cp -pR.-p flag preserves file attributes, ownership, and timestamps, and the -R flag ensures recursive copying. This maintains the app's security context and Gatekeeper approval status.