RFC: Binary Distribution Format #2
Open
+367
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
theory
force-pushed
the
binary-distribution-format
branch
5 times, most recently
from
39613c4
to
f4f4d0d
Compare
Open
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
added
rfc
pgguru
reviewed
Jul 12, 2024
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. |
There was a problem hiding this comment.
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.
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.
Okay, added the Package Name type to #3. I think that will solve the problem. I'll rewrite this bit.
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.
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
force-pushed
the
binary-distribution-format
branch
from
f4f4d0d
to
1a778ac
Compare
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.
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.