Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Binary Distribution Format #2

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

theory
Copy link
Member

@theory theory commented Jul 11, 2024

Add a new RFC describing the proposed trunk binary distribution format for PGXN packages. Inspired by Python wheel and pgt.dev, aiming to support binaries for every OS and architecture supported by PostgreSQL itself, as well as many versions of PostgreSQL.

Previous discussion.

@theory theory added the documentation Improvements or additions to documentation label Jul 11, 2024
@theory theory self-assigned this Jul 11, 2024
@theory theory force-pushed the binary-distribution-format branch 5 times, most recently from 39613c4 to f4f4d0d Compare July 11, 2024 20:00
@theory theory mentioned this pull request Jul 11, 2024
theory added a commit that referenced this pull request Jul 11, 2024
Add a new RFC for Meta Spec v2. Based on the [PGXN Meta Sketch] and
additional research. Notable differences from v1:

*   Introduce the term "package" separate from "distribution". The
    "package" is the bundle of objects being distributed as a…package.
*   Use only one version for the entire distribution, rather than
    separate versions for each extension included in the distribution.
    This allows the deletion of the notes on comparing versions.
*   Make "Source Distribution" the formal term, but mostly refer to it
    as "Distribution". Will be distinguished from binary distributions
    that ship with their own metadata (see #2).
*   Use JSON data types as the base types instead of generic "list" and
    "map" types.
*   Add "Path", "purl", and "Platform" types
*   Use SPDX License Expressions instead of Perl Software::License-based
    structures.
*   Use the term "property" to describe object key/value pairs, to align
    with JSON Schema.
*   Use an array of objects to describe maintainers.
*   Replace the `provides` property with `contents`, with support for
    multiple kinds of PostgreSQL extensions, including TLEs, loadable
    modules, and background workers.
*   Move the `tags` property to the new `classifications` object, and
    add support for curated categories borrowed from [Trunk].
*   Replace `no_index` with `ignore` and use the gitignore format
    instead of separate lists of files and directories.
*   Rename `prereqs` to `packages` and move it into the new
    `dependencies` property, which also has `postgres`, `pipeline`,
    `platforms`, and `variations` properties. Use [purls]. to specify
    dependencies, so that any supported packaging dependency can be
    specified, as well as PGXN packages and Postgres core extensions and
    tools.
*   Remove `release_status`; we'll instead depend on [SemVer] to
    indicate pre-releases.
*   Simplify the `resources` object and add `badges` to it.
*   Add the `artifacts` property, so the extension author can include
    links to other packages or sources for a release.

Also configure `#` to hide a line in `json` code blocks and use it to
encode proper JSON objects without showing the surrounding braces.
Readers can hit the eye button that appears on hover to make the hidden
lines appear.

[PGXN Meta Sketch]: https://justatheory.com/2024/03/rfc-pgxn-metadata-sketch/
[Trunk]: https://pgt.dev
[purls]: https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rs
[SemVer] https://semver.org
theory added a commit that referenced this pull request Jul 11, 2024
Add a new RFC for Meta Spec v2. Based on the [PGXN Meta Sketch] and
additional research. Notable differences from v1:

*   Introduce the term "package" separate from "distribution". The
    "package" is the bundle of objects being distributed as a…package.
*   Use only one version for the entire distribution, rather than
    separate versions for each extension included in the distribution.
    This allows the deletion of the notes on comparing versions.
*   Make "Source Distribution" the formal term, but mostly refer to it
    as "Distribution". Will be distinguished from binary distributions
    that ship with their own metadata (see #2).
*   Use JSON data types as the base types instead of generic "list" and
    "map" types.
*   Add "Path", "purl", and "Platform" types
*   Use SPDX License Expressions instead of Perl Software::License-based
    structures.
*   Use the term "property" to describe object key/value pairs, to align
    with JSON Schema.
*   Use an array of objects to describe maintainers.
*   Replace the `provides` property with `contents`, with support for
    multiple kinds of PostgreSQL extensions, including TLEs, loadable
    modules, and background workers.
*   Move the `tags` property to the new `classifications` object, and
    add support for curated categories borrowed from [Trunk].
*   Replace `no_index` with `ignore` and use the gitignore format
    instead of separate lists of files and directories.
*   Rename `prereqs` to `packages` and move it into the new
    `dependencies` property, which also has `postgres`, `pipeline`,
    `platforms`, and `variations` properties. Use [purls]. to specify
    dependencies, so that any supported packaging dependency can be
    specified, as well as PGXN packages and Postgres core extensions and
    tools.
*   Remove `release_status`; we'll instead depend on [SemVer] to
    indicate pre-releases.
*   Simplify the `resources` object and add `badges` to it.
*   Add the `artifacts` property, so the extension author can include
    links to other packages or sources for a release.

Also configure `#` to hide a line in `json` code blocks and use it to
encode proper JSON objects without showing the surrounding braces.
Readers can hit the eye button that appears on hover to make the hidden
lines appear.

[PGXN Meta Sketch]: https://justatheory.com/2024/03/rfc-pgxn-metadata-sketch/
[Trunk]: https://pgt.dev
[purls]: https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rs
[SemVer] https://semver.org
@theory theory added rfc New RFC and removed documentation Improvements or additions to documentation labels Jul 11, 2024
text/0002-binary-distribution-format.md Show resolved Hide resolved
Comment on lines 123 to 128
3. For the left part, split on the right-most dash. If the string to the
right of the dash is a valid [SemVer], then the left part is the package
name. If the right string is not a valid [SemVer], try again at the second
right-most dash and check again. Continue until a valid SemVer is produced
or else fail.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semver are required to have 3 parts, with any suffix after a dash (presumably not with another semver-like system, so 3.1.2-0 would be valid, but 3.1.2-1.2.3? This part feels like it has the potential for some ambiguity to me to be honest, but I trust you're more familiar with semver than I am at this point. :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bah, no, of course, 3.1.2-1.2.3 is a valid Semver.

So perhaps it instead needs to be that distribution names cannot start with a digit or use a digit after a dash. That would simplify things: the version starts at the first digit after a dash. Of existing distributions, it looks like only DBT-2 would be a problem:

distinct name from distributions where name LIKE '%-%';
           name           
──────────────────────────
 DBT-2
 E-Maj
 foreign-keycloak-wrapper
 hashtypes-aleksabl
 neo4j-fdw
 passwd-fdw
 pg-json
 Slony-I
 soundex-function
 soundex-operator
 soundex-type
 trunklet-format
(12 rows)

Note that this does not apply to the name of the extensions, apps, or anything else inside the distribution, just the name of the thing being distributed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, added the Package Name type to #3. I think that will solve the problem. I'll rewrite this bit.

text/0002-binary-distribution-format.md Show resolved Hide resolved
theory added a commit that referenced this pull request Jul 12, 2024
Add a new RFC for Meta Spec v2. Based on the [PGXN Meta Sketch] and
additional research. Notable differences from v1:

*   Introduce the term "package" separate from "distribution". The
    "package" is the bundle of objects being distributed as a…package.
*   Use only one version for the entire distribution, rather than
    separate versions for each extension included in the distribution.
    This allows the deletion of the notes on comparing versions.
*   Make "Source Distribution" the formal term, but mostly refer to it
    as "Distribution". Will be distinguished from binary distributions
    that ship with their own metadata (see #2).
*   Use JSON data types as the base types instead of generic "list" and
    "map" types.
*   Add "Path", "purl", and "Platform" types
*   Use SPDX License Expressions instead of Perl Software::License-based
    structures.
*   Use the term "property" to describe object key/value pairs, to align
    with JSON Schema.
*   Use an array of objects to describe maintainers.
*   Replace the `provides` property with `contents`, with support for
    multiple kinds of PostgreSQL extensions, including TLEs, loadable
    modules, and background workers.
*   Move the `tags` property to the new `classifications` object, and
    add support for curated categories borrowed from [Trunk].
*   Replace `no_index` with `ignore` and use the gitignore format
    instead of separate lists of files and directories.
*   Rename `prereqs` to `packages` and move it into the new
    `dependencies` property, which also has `postgres`, `pipeline`,
    `platforms`, and `variations` properties. Use [purls]. to specify
    dependencies, so that any supported packaging dependency can be
    specified, as well as PGXN packages and Postgres core extensions and
    tools.
*   Remove `release_status`; we'll instead depend on [SemVer] to
    indicate pre-releases.
*   Simplify the `resources` object and add `badges` to it.
*   Add the `artifacts` property, so the extension author can include
    links to other packages or sources for a release.

Also configure `#` to hide a line in `json` code blocks and use it to
encode proper JSON objects without showing the surrounding braces.
Readers can hit the eye button that appears on hover to make the hidden
lines appear.

[PGXN Meta Sketch]: https://justatheory.com/2024/03/rfc-pgxn-metadata-sketch/
[Trunk]: https://pgt.dev
[purls]: https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rs
[SemVer] https://semver.org
@theory theory mentioned this pull request Jul 12, 2024
2 tasks
theory added a commit that referenced this pull request Jul 12, 2024
*   Add the "Package Name" type that disallows leading digits.
    [Discussion](#2 (comment)).
*   Document the Number type and allow `0` as a valid value for a
    Version Range.
*   Add the "Path Pattern" type and use it for the "ignore" property.
*   Merge "License" into "License Expression"
*   Rename "Version" to "SemVer", to distinguish it from any other
    versions used for dependencies.
*   Make "Version Range" not-specific to SemVers, since it's used for
    all sorts of dependency version requirements. Also, disallow version
    truncation in Version Ranges, since different version formats will
    have different rules.
*   Document that purl version expressions are valid but ignored.
*   Fix various spelling, grammatical, syntax, and narrative errors and
    clumsiness.
*   Update spec URLs to point to rfcs.pgxn.org.
*   Rename `generated_by` to `producer`.
*   Add question about preloading.
*   Note quality binary distribution as sign of success.
Add a new RFC describing the proposed trunk binary distribution format
for PGXN packages. Inspired by Python wheel and pgt.dev, aiming to
support binaries for every OS and architecture supported by PostgreSQL
itself, as well as many versions of PostgreSQL.
@theory theory force-pushed the binary-distribution-format branch from f4f4d0d to 1a778ac Compare July 12, 2024 21:47
theory added a commit that referenced this pull request Jul 12, 2024
Add a new RFC for Meta Spec v2. Based on the [PGXN Meta Sketch] and
additional research. Notable differences from v1:

*   Introduce the term "package" separate from "distribution". The
    "package" is the bundle of objects being distributed as a…package.
*   Use only one version for the entire distribution, rather than
    separate versions for each extension included in the distribution.
    This allows the deletion of the notes on comparing versions.
*   Make "Source Distribution" the formal term, but mostly refer to it
    as "Distribution". Will be distinguished from binary distributions
    that ship with their own metadata (see #2).
*   Use JSON data types as the base types instead of generic "list" and
    "map" types.
*   Add "Path", "purl", and "Platform" types
*   Use SPDX License Expressions instead of Perl Software::License-based
    structures.
*   Use the term "property" to describe object key/value pairs, to align
    with JSON Schema.
*   Use an array of objects to describe maintainers.
*   Replace the `provides` property with `contents`, with support for
    multiple kinds of PostgreSQL extensions, including TLEs, loadable
    modules, and background workers.
*   Move the `tags` property to the new `classifications` object, and
    add support for curated categories borrowed from [Trunk].
*   Replace `no_index` with `ignore` and use the gitignore format
    instead of separate lists of files and directories.
*   Rename `prereqs` to `packages` and move it into the new
    `dependencies` property, which also has `postgres`, `pipeline`,
    `platforms`, and `variations` properties. Use [purls]. to specify
    dependencies, so that any supported packaging dependency can be
    specified, as well as PGXN packages and Postgres core extensions and
    tools.
*   Remove `release_status`; we'll instead depend on [SemVer] to
    indicate pre-releases.
*   Simplify the `resources` object and add `badges` to it.
*   Add the `artifacts` property, so the extension author can include
    links to other packages or sources for a release.

Also configure `#` to hide a line in `json` code blocks and use it to
encode proper JSON objects without showing the surrounding braces.
Readers can hit the eye button that appears on hover to make the hidden
lines appear.

[PGXN Meta Sketch]: https://justatheory.com/2024/03/rfc-pgxn-metadata-sketch/
[Trunk]: https://pgt.dev
[purls]: https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rs
[SemVer] https://semver.org
theory added a commit that referenced this pull request Jul 12, 2024
*   Add the "Package Name" type that disallows leading digits.
    [Discussion](#2 (comment)).
*   Document the Number type and allow `0` as a valid value for a
    Version Range.
*   Add the "Path Pattern" type and use it for the "ignore" property.
*   Merge "License" into "License Expression"
*   Rename "Version" to "SemVer", to distinguish it from any other
    versions used for dependencies.
*   Make "Version Range" not-specific to SemVers, since it's used for
    all sorts of dependency version requirements. Also, disallow version
    truncation in Version Ranges, since different version formats will
    have different rules.
*   Document that purl version expressions are valid but ignored.
*   Fix various spelling, grammatical, syntax, and narrative errors and
    clumsiness.
*   Update spec URLs to point to rfcs.pgxn.org.
*   Rename `generated_by` to `producer`.
*   Add question about preloading.
*   Note quality binary distribution as sign of success.
Made possible by RFC-3 disallowing digits after dashes in package names.
Made possible by forbidding dots (.) in Terms in the metatdata spec
(80702c3), making it impossible for a package name to include a semver.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rfc New RFC
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants