-
Notifications
You must be signed in to change notification settings - Fork 0
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
base: main
Are you sure you want to change the base?
Conversation
39613c4
to
f4f4d0d
Compare
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
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
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. |
There was a problem hiding this comment.
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. :-)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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
* 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.
f4f4d0d
to
1a778ac
Compare
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
* 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.
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.