RFC: Meta Spec v2 #3
Open
Conversation
This file contains hidden or 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
meta-spec-v2
branch
2 times, most recently
from
7f30c48 to
9f7718b
Compare
theory
added
rfc
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.
Instead of having a separate "package name" type. A quick check of the PGXN database and [1000+ PostgreSQL EXTENSIONs] shows no existing extensions contain a dot. This will simplify parsing a package name from a semver in file names, since dots are required for semantic versions. [1000+ PostgreSQL EXTENSIONs]: https://gist.github.com/joelonsql/e5aa27f8cc9bd22b8999b7de8aee9d47
* extensions: `CREATE EXTENSION` extensions * modules: loadable modules for extensions, hooks, and workers * apps: Programs and scripts like pg_top, pgAdmin, or pg_partman scripts Add an example from pg_partman, which includes all three types.
* Add missing `contents` key to example * Rename "Path Pattern" to "Glob" * Fix ignore header * Fix missing package version * Use "cargo" instead of "rust" for pipeline value * Tweak wording on phases * Add url property to badge
theory
added a commit
to pgxn/meta
that referenced
this pull request
Jul 24, 2024
Based on pgxn/rfcs#3. As with the v1 schemas, use JSON Schema v2020 for the v2 schemas. Fix a few minor issues with the v1 schema, as well. Add full test suite in Rust; move code shared between the v1 and v2 tests to `tests/common/mod.rs`. This includes custom format functions not required for v1, including spdx version expression validation with the `spdx` crate, and path validation to ensure no `..` is included in paths.
theory
added a commit
to pgxn/meta
that referenced
this pull request
Jul 24, 2024
Based on pgxn/rfcs#3. As with the v1 schemas, use JSON Schema v2020 for the v2 schemas. Fix a few minor issues with the v1 schema, as well. Add full test suite in Rust; move code shared between the v1 and v2 tests to `tests/common/mod.rs`. This includes custom format functions not required for v1, including spdx version expression validation with the `spdx` crate, and path validation to ensure no `..` is included in paths.
This was referenced Jul 24, 2024
Also link to the Repology API.
This was referenced Sep 3, 2024
And fix a couple of version references and links.
theory
commented
Mar 27, 2025
| that are required to be compiled into PostgreSQL. Each corresponds to | ||
| the appropriate `--with` [configure flag]. **OPTIONAL**. | ||
|
|
||
| * **pipeline**: A [Term](#term) identifying the build pipeline required to |
There was a problem hiding this comment.
I'm wondering if this concept needs to be extended to support additional paraemters. Some examples from recent experience rebuilding Trunk extensions:
cargo pgrx package --features icu(source)RUSTFLAGS="-C target-feature=+avx2,+fma" cargo pgrx package(source)mvn clean install -Dpljava.libjvmdefault=/usr/lib/x86_64-linux-gnu/libjvm.so(source)make -C LDFLAGS_EX="-L/usr/lib/postgresql/17/lib"(Error compiling on Postgres 17 on Ubuntu 2ndQuadrant/pglogical#492)- This plrust custom build
- This bson custom build
- This timescale shell script
There was a problem hiding this comment.
Also need to consider how some pipelines are inconsistently used. Instructions for using cmake appear to vary quite a lot, for example.
Notable changes:
* Exclude parent directory components (`..`) from paths and globs
* Note contents items that need not be part of the source, but should
exist after building
* Limit the number of tags to 32
* Remove discussion of using Repology to resolve `pkg:generic`
dependencies
* Remove answered and irrelevant questions
* Add question about supporting pipeline features
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 for Meta Spec v2. Based on the PGXN Meta Sketch and additional research. Notable differences from v1:
providesproperty withcontents, with support for multiple kinds of PostgreSQL extensions, including TLEs, loadable modules, and background workers.tagsproperty to the newclassificationsobject, and add support for curated categories borrowed from Trunk.no_indexwithignoreand use the gitignore format instead of separate lists of files and directories.prereqstopackagesand move it into the newdependenciesproperty, which also haspostgres,pipeline,platforms, andvariationsproperties. 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.release_status; we'll instead depend on SemVer to indicate pre-releases.resourcesobject and addbadgesto it.artifactsproperty, so the extension author can include links to other packages or sources for a release.Also configure
#to hide a line injsoncode 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.