ActiveState Artifact Repository
Artifact
Attestation
Build
Build Graph
Build Plan
Catalog
Command Line Interface
Commit
Ingredient
Language
Legacy Language Version
Library
Managed Distribution
Operating System
Organization
Package
Platform
Private Project
Project
Project Branch
Public Project
Requirements
Runtime
Solver
Source Code
State Tool
Timestamp
An ActiveState Artifact Repository (AAR) is a software storage system for the code artifacts required by software teams and systems. It may contain third-party source code components imported from a public repository, as well as the packages built from those components.
Important features include:
A user-accessible package, bundle, binary, dependency, or transitive dependency whose source code has been downloaded by ActiveState and reviewed / vetted. Artifacts are available to users in the ActiveState catalog.
An authenticated statement (metadata) about a software artifact or collection of software artifacts. ActiveState can provide an attestation for any project commit or project branch commit.
A collection of artifacts for a specific project that can be installed as a runtime.
A GraphQL-based API that provides user access to our platform. The Build Graph can be used to:
The Build Graph uses GraphQL queries.
After a project is created and all needed packages have been added, a build plan is generated by the solver to determine the process needed to build the requested project configuration.
A collection of open source artifacts offered by ActiveState. It contains all languages and packages, dependencies, and transitive dependencies that are currently offered to users on the platform. The catalog is updated regularly to include the most popular and useful content possible.
The ActiveState command line interface is the State Tool.
A set of changes made to a project at a specific time by a specific user. Commits are the fundamental unit for tracking the changes to a project over time.
A pre-existing dependency or base dependency used to build an artifact on the platform. Typically composed of source code but may extend to other binaries (e.g. build tools and compilers).
Perl, Python, Tcl, Ruby, etc. A “language” refers to any software development language, or version of a language, provided to users via the ActiveState Platform.
Language versions that were previously available for download, but are no longer recommended for use due to age, risk of exploit, or obsolescence.
A C library or any code that is compiled by ActiveState that is not specific to a language core and is used as a system dependency.
Libraries are not selectable by users. However, they may be the dependency of a package and can be specified if they appear in the dependencies of a project.
A fully working runtime environment that is managed and maintained by ActiveState on behalf of the customer.
As part of a Managed Distribution, ActiveState will:
A specific operating system such as Windows 10, macOS 10.8, Linux glibc 2.25, etc. Every project will need to compile for at least one operating system. Only paid accounts are able to create projects that will compile for more than one operating system per project.
Organizations group ActiveState Platform projects for a company, department, or team. Members of the organization will have access to each project in the organization, with the ability to invite others to join, remove users, and create or modify runtimes (depending on the permissions settings of the user).
Paid organizations support both private and public projects. Free organizations can only support public projects.
Software built by ActiveState from source code that has been ingested from package managers such as PyPi, CPAN, and RubyCentral. A “package” may refer to a language submodule like a Python package or a Perl package.
The ActiveState Platform is a cloud-based solution that allows developers to create projects that easily build, run, and maintain open-source projects in Perl, Python, Tcl, and others. It includes tools for package management, automated builds, and the ability to collaborate on projects with other developers using the same runtime environment.
Projects that have hidden details (language and packages used) and only members of the organization may install this runtime. In the case of a project in a personal organization, only the creator can see and install this runtime.
An organizational unit used to group software components, requirements, variables, scripts, branches, and operating systems logically together. If a user wants to share a runtime with colleagues they will need to create a project within an organization first.
Branches can be created by forking a project to help with tests and new features. Branches bring support for experimental builds, managing complex multi-platform projects, creating different builds per environment, and more.
A project that is available for any web user to browse and download. Public projects have details (language & packages used) of the runtime publicly visible. Anyone, including anonymous users, can install the runtime of a public project.
A list of mandatory software dependencies that must be included in a project in order to meet the needs of the user. Examples of requirements include specified open source languages and version, libraries, and build options.
Requirements files can be uploaded to the platform in the following formats:
A pre-built, installable bundle that contains both a programming language version (e.g. “Python 2.7”) and the packages needed for developing in that language. A runtime does not contain any first-party code produced by developers using the runtime.
All runtimes are customizable. Individual bundles can be tailored to the specific requirements of any given application and scope. A runtime is activated via the CLI (i.e. the State Tool) and can be used on a local machine, server, container, etc.
An internal utility that determines the build graph that is needed for the requested project configuration. This includes the language version, OS, and any requested ingredients (including all transitive and upstream dependencies). When given a requested list of ingredients, the solver computes a working build graph that will create the runtime.
Original code written in the form of functions, descriptions, definitions, calls, methods and other operational statements. ActiveState uses an automated ingestion pipeline to copy in the source code of language core versions and packages from package managers such as PyPi, CPAN, and RubyCentral. The ActiveState Platform then ingests related CVEs and correlates those to the appropriate language core versions and packages before offering them to users.
The ActiveState command line interface (CLI), the State Tool allows users to create and manage projects right from the command prompt.
The State Tool can create new projects, view and modify existing projects, and download and install runtime environments.
A point in time before ingested ingredients that ActiveState has deemed safe for users are provided as available ingredients. This allows ActiveState to ingest but not prematurely expose ingredients to users.