Specifying Platforms

As a concept, platforms are packages that only provide opinions on what should exist in an environment. They contain no files or code, and have no concrete dependencies but limit what versions are allowed in order to enforce consistency across teams, applications and developers.

As an example, the VFX Reference Platform provides “a set of tools and library versions to be used as a common target platform for building software for the VFX industry”. Platforms in SPK were designed to be able to describe and enforce these kinds of recommendations.

Platforms are Packages

At their core, platforms are a convenient way to write package specs that only provide an opinion on what versions can be used and nothing else. Once defined, platforms are still built, published, and used the same way as any other package.

A platform spec reduces the amount of boilerplate needed to set up a platform package compared to using the full v0/package recipe format. A platform spec will be filled in with appropriate defaults automatically for a platform-style package.

Creating Platforms

Below is an example platform

api: v1/platform
platform: company-platform/2025.01.01
requirements:
  - pkg: gcc
    atBuild: =9.3.1
    atRuntime: 9.3.1
  - pkg: python
    atBuild: =3.9.18
    atRuntime: 3.9
  - pkg: imath
    atBuild: =3.0.1
    atRuntime: 3

The platform: field provides the name of the platform package. The api: field indicates this is a platform spec.

The requirements field contains the list of requirements in the platform. In each case, the requirement specifies the version request to be used at build time vs at run time. This allows the platform to differently constrain the requirement depending on if it’s being used to define a build environment or a runtime environment.

These requirements are placed onto the build and run components of the package generated by this platform, respectively. The generated requirements will have include: IfAlreadyPresent added to them automatically, it does not need to be specified for them.

Inheritance

Additionally, the platform spec provides a way to inherit requirements from another package. Typically, it makes the most sense to inherit from another platform, but it could be any package.

By inheriting from base packages, platforms can augment and override their requirements. For example, a DCC (Digital Content Creation) application platform can inherit the requirements from company or site-specific platforms and then introduce additional constraints for the application itself.

Here is an example platform spec that inherits from the ‘company-platform’ and makes adjustments of its own:

api: v1/platform
platform: dcc-platform/2025.01.01
base:
  - company-platform/2024.01.01
requirements:
  # this DCC uses an older version of python
  - pkg: python
    atBuild: =3.7.10
    atRuntime: 3.7
  # it also has no need to constrain the version of imath that is used
  - pkg: imath
    atBuild: false
    atRuntime: false

The base: field indicates which platform this one inherits from. In the case of multiple bases, each one simply overrides the previous in turn.

Any atBuild or atRuntime value that is specified in the platform spec will override the same value for the named requirement in the bases. Conversely, this also means that if a requirement omits either of the atBuild or atRuntime fields, then the value from the base will still remain.

The special false value can be used to remove the requirement entirely.

This is the complete specification of the same resulting dcc-platform without basing it on the company-platform:

api: v1/platform
platform: dcc-platform
requirements:
  - pkg: gcc
    atBuild: =9.3.1
    atRuntime: 9.3.1
  - pkg: python
    atBuild: =3.7.10
    atRuntime: 3.7
  # - pkg: imath not present