Scientific Python Ecosystem Coordination on Scientific Python

SPEC 8 — Securing the Release Process

Tue, 04 Jun 2024 00:00:00 +0000

Description#

Open source libraries constitute a significant portion of the world’s digital infrastructure. Securing the Open Source supply chain (OSSC) is therefore an increasing concern, with examples of sophisticated attacks against the ecosystem (e.g., the 2024 xz utils backdoor) and malware attacks on PyPI highlighting the need for supply chain security to be taken seriously. The Python Software Foundation (PSF) is also taking the importance of the OSSC seriously, as demonstrated by the creation of the PSF Security Developer in Residence position in 2023.

SPEC 9 — Governance

Tue, 04 Jun 2024 00:00:00 +0000

Description#

This SPEC describes what governance is, and offers recommendations for choosing a governance model for open-source projects.

Open-source project communities are amalgamations of software and the humans who use and maintain it. Governance models define methods for decision-making within a project, roles for the community members imbued with decision-making authority, and processes for filling (and, if needed, vacating) those leadership roles. In the context of open-source software projects, governance models often also define the granting of necessary permissions or access to organization secrets necessary for the implementation of project-related decisions. Governance models are complementary to Codes of Conduct and Community Guidelines, which define the expectations and responsibilities of all participants in a project (including users of the software), regardless of their status as a project leader (cf. SPEC XXX), ensuring the long-term sustainability of a project.

SPEC 7 — Seeding Pseudo-Random Number Generation

Wed, 19 Apr 2023 00:00:00 +0000

Description#

Currently, libraries across the ecosystem provide various APIs for seeding pseudo-random number generation. This SPEC suggests a unified, pragmatic API, taking into account technical and historical factors. Adopting such a uniform API will simplify the user experience, especially for those who rely on multiple projects.

We recommend:

standardizing the usage and interpretation of an rng keyword for seeding, and
avoiding the use of global state and legacy bitstream generators.

We suggest implementing these principles by:

SPEC 6 — Keys to the Castle

Mon, 19 Dec 2022 00:00:00 +0000

Description#

Projects engage with restricted resources all the time. Examples include access to add & remove team members, grant commit rights, or make uploads to certain hosts.

Documenting resources is critical to ensuring uninterrupted operations. It is important that team members know who have access to resources, and how to gain access to resources. For example, if updated project documentation needs to be uploaded to a remote server via SSH, who are the team members that can do that, and by which process can a release manager request access?

SPEC 5 — CI Best Practices

Thu, 22 Sep 2022 00:00:00 +0000

Description#

Core Project Endorsement#

Ecosystem Adoption#

Badges#

Projects can highlight their adoption of this SPEC by including a SPEC badge.

[![SPEC 5 — CI Best Practices](https://img.shields.io/badge/SPEC-5-green?labelColor=%23004811&color=%235CA038)](https://scientific-python.org/specs/spec-0005/)

|SPEC 5 — CI Best Practices| 

.. |SPEC 5 — CI Best Practices| image:: https://img.shields.io/badge/SPEC-5-green?labelColor=%23004811&color=%235CA038
   :target: https://scientific-python.org/specs/spec-0005/

To indicate adoption of multiple SPECS with one badge, see this.

SPEC 4 — Using and Creating Nightly Wheels

Mon, 05 Sep 2022 00:00:00 +0000

Description#

This SPEC describes how to test against nightly wheels of several widely used projects and how to create nightly wheels for your project. The document uses the word nightly to refer to some semi regular interval, like daily, weekly, or every three days.

Regularly running your project’s tests while using the nightly version of your dependencies allows you to spot problems caused by upstream changes before a new release is made. This way potential issues can be resolved before they find their way into a release, at which point it becomes much harder to change or revert something.

SPEC 3 — Accessibility

Mon, 14 Feb 2022 00:00:00 +0000

Description#

Technology is a great tool to make the world accessible to the full range of human experience, which includes those with disabilities. The reach of accessibility guidelines extends beyond the scientific Python ecosystem including the Web Content Accessibility Guidelines (W3C), a comprehensive set of international standards designed to make web content more accessible.

The primary objective of this SPEC (Scientific Python Accessibility) is to provide fundamental recommendations for the Scientific Python communities and their projects. These recommendations aim to ensure accessibility and inclusivity for individuals with disabilities, particularly regarding web-based content and tools.

SPEC 2 — API Dispatch

Thu, 16 Dec 2021 00:00:00 +0000

Description#

This SPEC (Scientific Python Ecosystem Coordination) recommendation for API dispatching is designed to enhance interoperability and performance within the scientific Python ecosystem, leveraging the capabilities of Python entry_points.

This recommendation presents a systematic approach that enables users to redirect function calls to alternative computation backends seamlessly. This flexibility allows users to take advantage of optimized implementations simply by configuring an environment variable or adding an additional keyword argument (more on this later), rather than having to learn a new API’s interface, which might not be very “python-user”-friendly. Such adaptability facilitates the integration of hardware-specific optimizations, reimplementations in other programming languages (such as C or Rust), and the utilization of entirely new data structures.

SPEC 0 — Minimum Supported Dependencies

Thu, 17 Dec 2020 00:00:00 +0000

Description#

This SPEC recommends that all projects across the Scientific Python ecosystem adopt a common time-based policy for dropping dependencies. From the perspective of this SPEC, the dependencies in question are core packages as well as older Python versions.

All versions refer to feature releases (i.e., Python 3.8.0, NumPy 1.19.0; not Python 3.8.1, NumPy 1.19.2).

Specifically, we recommend that:

Support for Python versions be dropped 3 years after their initial release.
Support for core package dependencies be dropped 2 years after their initial release.

Note

Core packages may or may not decide to provide bug fix releases during the full 2 year period after release. Therefore, projects may occasionally want to drop support for core package dependencies earlier than recommended by this SPEC. For instance, if a newer minimum version of a core package is needed by a project due to a critical bug fix, which is not backported to older versions.

SPEC 1 — Lazy Loading of Submodules and Functions

Thu, 17 Dec 2020 00:00:00 +0000

Description#

This SPEC recommends a lazy loading mechanism—targeted at libraries—that avoids import slowdowns and provides explicit submodule exports.

For example, it allows the following behavior:

import skimage as ski  # cheap operation; does not load submodules

ski.filters  # cheap operation; loads the filters submodule, but not
             # any of its submodules or functions

ski.filters.gaussian(...)  # loads the file in which gaussian is implemented
                           # and calls that function

This has several advantages:

Mon, 01 Jan 0001 00:00:00 +0000

SPEC#

The Scientific Python Ecosystem Coordination (SPEC) mechanism is used to recommend project policies, coding conventions, and standard tooling.

See https://scientific-python.org/specs/ for a list of SPECs and their statuses.