[Feature] Support OCI registries for packages #123

Open
opened 2025-12-30 01:21:10 +01:00 by adam · 3 comments
Owner

Originally created by @eli-xciv on GitHub (Mar 21, 2024).

It would be nice to be able to store packages in and use packages from an OCI registry.

This issue/request is to support the oci:// URI in addition to package:// for dependencies.

As for OCI artifacts and layer media types, pkl could adopt vendor based media types for each layer, if each generated artifact was added as a separate layer, such as
application/vnd.apple.pkl.metadata.v1.xml for the metadata artifact
application/vnd.apple.pkl.metadata.v1.checksum_sha256 for the metadata checksum
application/vnd.apple.pkl.package.v1.zip for the actual package artifact
and
application/vnd.apple.pkl.package.v1.checksum_sha256 for the package checksum

This would possibly also require a change to the pkl-cli to add a flag to dictate how the package will be build (default | OCI)

Originally created by @eli-xciv on GitHub (Mar 21, 2024). It would be nice to be able to store packages in and use packages from an OCI registry. This issue/request is to support the `oci://` URI in addition to `package://` for dependencies. As for OCI artifacts and layer media types, pkl could adopt vendor based media types for each layer, if each generated artifact was added as a separate layer, such as `application/vnd.apple.pkl.metadata.v1.xml` for the metadata artifact `application/vnd.apple.pkl.metadata.v1.checksum_sha256` for the metadata checksum `application/vnd.apple.pkl.package.v1.zip` for the actual package artifact and `application/vnd.apple.pkl.package.v1.checksum_sha256` for the package checksum This would possibly also require a change to the `pkl-cli` to add a flag to dictate how the package will be build (default | OCI)
Author
Owner

@bioball commented on GitHub (Mar 21, 2024):

We've thought about this! It's also how CUE and KCL decided to distribute their packages.

This is somewhat compelling; something that package: is missing right now is some sort of index. OCI registries solve that problem for us.

But, I think we need some more time to understand the trade-offs of our current package model before adding any changes here.

@bioball commented on GitHub (Mar 21, 2024): We've thought about this! It's also how CUE and KCL decided to distribute their packages. This is somewhat compelling; something that `package:` is missing right now is some sort of index. OCI registries solve that problem for us. But, I think we need some more time to understand the trade-offs of our current package model before adding any changes here.
Author
Owner

@bvalyou commented on GitHub (Apr 9, 2024):

Since I'm looking at using Pkl as a replacement for Helm, being able to reuse our Helm registry for Pkl packages is something of a requirement. Currently considering using oras and some jank around local packages once they're downloaded to work around this for now.

@bvalyou commented on GitHub (Apr 9, 2024): Since I'm looking at using Pkl as a replacement for Helm, being able to reuse our Helm registry for Pkl packages is something of a requirement. Currently considering using [oras](https://oras.land/docs/quickstart) and some jank around local packages once they're downloaded to work around this for now.
Author
Owner

@eli-xciv commented on GitHub (Nov 5, 2024):

@bioball Just checking back in to see if you all have been able to have any conversations around packaging and possible support for this.

Thanks for any info!

@eli-xciv commented on GitHub (Nov 5, 2024): @bioball Just checking back in to see if you all have been able to have any conversations around packaging and possible support for this. Thanks for any info!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#123