OCI: Define MediaTypes and decompression logic for nupkg/zip
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 45/100
Piste de recherche
Commencez par retracer le chemin existant de récupération des artefacts OCI et la manière dont les couches tar et tar+gzip sont gérées. Définissez les types de média nupkg et zip, appliquez le traitement unzip à ces couches et vérifiez que les paquets zip natifs sont consommés sans affecter les formats existants.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Summary of the new feature / enhancement
As a publisher, I want to publish PowerShell Modules packaged in nupkg as ORAS artifacts to consume in their native zip format rather than having to convert them to tar+gzip.
If I am hosting a large registry (e.g. https://pwsh.gallery), I can reference the same storage/packages for both nugetv2/v3 and oras packages, otherwise I have to hold and maintain duplicate copies/storage of every package.
Proposed technical implementation details (optional)
OCI allows definitions of both a media type and an image type. Rather then be generic, we should define types for both of these and implement them for nupkg/zip:
Nupkg MediaType: application/vnd.dotnet.nupkg.v1+zip
Zip Layer MediaType: application/vnd.oci.image.layer.v1.zip
When pulling packages, apply proper unzip to these layers and then handle the same as the tar+gzip. Potentially support a strict option to only accept items that were strictly published with the dotnet.nupkg mediatype.
This behavior would only occur on the specified image type, so it would not break any compatibility.
Registries could choose to then host powershell modules in either native zip, tar, tar+gzip, or tar+zstd.
This implementation would not require any registry-side changes, as they are designed for this and do not need to know or understand the zip format to work for both publishing and retrieval, unless a registry does some sort of non-standard validation of the artifact.
It may make sense to define these formats or the transfer mechanism in general in a PowerShell RFC so that all OCI-based PowerShell tools have a standard set of instructions to work from.
- Langage dominant
- C#
- Étoiles
- 576
- Forks
- 114
- Merge moyen
- 23 h 17 min
- PR mergées (30 j)
- 8
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de PowerShell/PSResourceGet
-
Create parent directories only after the containment check in InstallHelper.TryExtractToDirectory Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
PowerShell/PSResourceGet#2056 ·
-
feature_request
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
PowerShell/PSResourceGet#2013 · 3 commentaires ·
-
feature_request Needs-Triage
PowerShell/PSResourceGet#2057 · 1 personne assignée ·
-
Needs-Triage
Difficulté 3/5 1-2 jours Accessibilité débutants 68/100
PowerShell/PSResourceGet#2055 ·
-
Needs-Triage
Difficulté 3/5 1-2 jours Accessibilité débutants 72/100
PowerShell/PSResourceGet#2054 ·
Toutes les issues de PowerShell/PSResourceGet
Issues similaires
-
effort:S P3 refactor
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
nightscout/nocturne#1532 ·
-
core dependencies
Difficulté 1/5 Moins d'une heure Accessibilité débutants 80/100
-
documentation
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
C#/.NET Roslyn LSP Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
-
Suspicious code fragments Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
DotNetNext/SqlSugar#1458 ·