Foire aux questions sur la PowerShell Gallery

Un module PowerShell est un paquet réutilisable contenant certaines fonctionnalités PowerShell. Tout ce qui est dans PowerShell (fonctions, variables, ressources DSC, etc.) peut être emballé dans des modules. Typiquement, les modules sont des dossiers contenant des types spécifiques de fichiers stockés sur un chemin précis. Il existe plusieurs types de modules PowerShell différents.

Un script PowerShell est une série de commandes stockées dans un fichier .ps1 pour permettre la réutilisation et le partage. Les flux de travail PowerShell sont aussi des scripts PowerShell, qui esquissent un ensemble de tâches et fournissent un séquençage pour ces tâches. Pour plus d’informations, veuillez consulter Commencer avec le flux de travail PowerShell.

Les modules sont généralement meilleurs pour le partage, mais nous activons le partage de scripts pour faciliter la contribution de flux de travail et de scripts à la communauté. Pour plus d’informations, consultez les blogs suivants :

• N’écrivez pas de scripts, écrivez des modules PowerShell
• Comprendre les modules PowerShell

Vous devez créer un compte dans la PowerShell Gallery avant de pouvoir publier des paquets dans la Galerie. Cela s’explique par le fait que la publication de paquets nécessite un NuGetApiKey, qui est fourni lors de l’enregistrement. Pour vous inscrire, utilisez votre compte personnel, professionnel ou scolaire pour vous connecter à la PowerShell Gallery. Un processus d’enregistrement unique est nécessaire lors de votre première connexion. Ensuite, votre NuGetApiKey est disponible sur votre page de profil.

Une fois inscrit dans la Galerie, utilisez les commandets Publish-Module ou Publish-Script pour publier votre dossier dans la Galerie. Pour plus de détails sur la façon d’exécuter ces cmdlets, consultez l’onglet Publier, ou lisez la documentation Publish-Module et Publish-Script .

Vous n’avez pas besoin de vous enregistrer ou de vous connecter à la Galerie pour installer ou sauvegarder des paquets.

Le message d’erreur complet est : « Échec du traitement de la demande. » « La clé API spécifiée est invalide ou n’a pas la permission d’accéder au package spécifié. » Le serveur distant a renvoyé une erreur : (403) Interdit. »

Cette erreur peut se produire pour les raisons suivantes :

• La clé API spécifiée est invalide. Assurez-vous d’avoir spécifié la clé API valide depuis votre compte. Pour obtenir votre clé API, consultez votre page de profil.
• Le nom du forfait spécifié ne vous appartient pas. Si vous avez confirmé que votre clé API est correcte, il se peut qu’il existe déjà un package portant le même nom que celui que vous essayez d’utiliser. Le colis a peut-être été non listé par le propriétaire, auquel cas il n’apparaîtra dans aucun résultat de recherche. Pour déterminer si un paquet portant le même nom existe déjà, ouvrez un navigateur et allez à la page des détails du paquet : https://www.powershellgallery.com/packages/<packageName>. Par exemple, naviguer directement vers https://www.powershellgallery.com/packages/pester vous mènera à la page de détails du module Pester, qu’elle ne soit pas répertoriée ou non. Si un colis avec un nom conflictuel existe déjà et n’est pas répertorié, vous pouvez :
  • Choisissez un autre nom pour votre forfait.
  • Contactez les propriétaires du forfait existant.

Veuillez noter que votre compte galerie ne permet pas de modifier votre alias principal d’email. Pour plus d’informations, voir Microsoft Email Aliases.

En cochant une case de catégorie, vous indiquez « Je souhaite voir tous les colis de cette catégorie. » Seuls les paquets des catégories sélectionnées seront affichés. De même, en cochant toutes les cases Catégories, vous déclarez « Je souhaite voir tous les colis dans n’importe quelle catégorie. » Mais certains paquets dans la galerie n’appartiennent à aucune des catégories listées, ils n’apparaîtront donc pas dans les résultats. Pour voir tous les paquets dans la galerie, décochez toutes les Catégories, ou sélectionnez à nouveau l’onglet paquets.

Tout type de module PowerShell (modules script, modules binaires ou modules manifest) peut être publié dans la galerie. Pour publier un module, PowerShellGet doit connaître quelques éléments à son sujet : la version, la description, l’auteur, et la manière dont il est sous licence. Ces informations sont lues dans le cadre du processus de publication à partir du fichier manifest du module (.psd1), ou à partir de la valeur du paramètre LicenseUri du cmdlet Publish-Module. Tous les modules publiés dans la Galerie doivent avoir des manifestes de modules. Tout module incluant les informations suivantes dans son manifeste peut être publié dans la Galerie :

• Version
• Description
• Auteur
• Un URI aux termes de licence du module, soit dans la section PrivateData du manifeste, soit dans le paramètre LicenseUri du cmdlet Publish-Module .

La façon la plus simple de créer un manifest de module est d’exécuter le cmdlet New-ModuleManifest . Dans PowerShell 5.0 ou versions ultérieures, New-ModuleManifest génère un manifeste de module correctement formaté avec des champs vierges pour des métadonnées utiles telles que ProjectUri, LicenseUri et Tags. Il suffit de remplir les blancs, ou d’utiliser le manifeste généré comme exemple de mise en forme correcte.

Pour vérifier que tous les champs de métadonnées requis ont été correctement remplis, utilisez le cmdlet Test-ModuleManifest .

Pour mettre à jour les champs du fichier manifest du module, utilisez le cmdlet Update-ModuleManifest .

Tout type de script PowerShell (scripts ou workflows) peut être publié dans la galerie. Pour publier un script, PowerShellGet doit connaître quelques éléments à son sujet : la version, la description, l’auteur, et la façon dont il est sous licence. Ces informations sont lues dans le cadre du processus de publication depuis la section PSScriptInfo du fichier script, ou depuis la valeur du paramètre LicenseUri du cmdlet Publish-Script. Tous les scripts publiés dans la Galerie doivent contenir des informations de métadonnées. Tout script incluant les informations suivantes dans sa section PSScriptInfo peut être publié dans la Galerie :

• Version
• Description
• Auteur
• Un URI des termes de licence du script, soit dans la section PSScriptInfo du script, soit dans le paramètre LicenseUri du cmdlet Publish-Script .

Tapez ce que vous cherchez dans la boîte de texte. Par exemple, si vous voulez trouver des modules liés à Azure SQL, tapez simplement « azure sql ». Notre moteur de recherche recherchera ces mots-clés dans tous les paquets publiés, y compris les titres, descriptions et à travers les métadonnées. Ensuite, sur la base d’un score de qualité pondéré, il affichera les correspondances les plus proches. Vous pouvez également rechercher par champ spécifique en utilisant la syntaxe champ :« valeur » dans la requête de recherche pour les champs suivants :

• Étiquettes
• Functions
• Applets de commande
• Ressources du Dsc.
• PowerShellVersion

Par exemple, lorsque vous cherchez PowerShellVersion :"2.0 », seuls les résultats compatibles avec PowerShellVersion 2.0 (basés sur leur manifeste module/script) seront affichés.

La façon la plus simple de créer un fichier script correctement formaté est d’exécuter le cmdlet New-ScriptFileInfo . Dans PowerShell 5.0, New-ScriptFileInfo génère un fichier script correctement formaté avec des champs vides pour des métadonnées utiles comme ProjectUri, LicenseUri et Tags. Il suffit de remplir les blancs, ou d’utiliser le fichier script généré comme exemple de mise en forme correcte.

Pour vérifier que tous les champs de métadonnées requis ont été correctement remplis, utilisez le cmdlet Test-ScriptFileInfo .

Pour mettre à jour les champs de métadonnées du script, utilisez le cmdlet Update-ScriptFileInfo .

Le terme module PowerShell désigne également les fichiers qui implémentent des fonctionnalités réelles. Les fichiers des modules script (.psm1) contiennent du code PowerShell. Les fichiers de modules binaires (.dll) contiennent du code compilé.

Voici une façon de voir les choses : le dossier qui encapsule le module est le dossier du module. Le dossier module peut contenir un manifest module (.psd1) qui décrit le contenu du dossier. Les fichiers qui effectuent réellement le travail sont les fichiers modules scripts (.psm1) et les fichiers modules binaires (.dll). Les ressources DSC se trouvent dans un sous-dossier spécifique et sont implémentées sous forme de fichiers modules de script ou de fichiers de modules binaires.

Tous les modules de la Galerie contiennent des manifestes de modules, et la plupart de ces modules contiennent des fichiers de modules script ou des fichiers binaires. Le terme module peut être déroutant à cause de ces significations différentes. Sauf indication contraire explicite, toutes les utilisations du mot module sur cette page désignent le dossier module contenant ces fichiers.

La gestion des paquets est une interface courante pour travailler avec tout gestionnaire de paquets. Finalement, que vous ayez affaire à des modules PowerShell, MSI, Ruby gems, paquets NuGet ou modules Perl, vous devriez pouvoir utiliser les commandes de PackageManagement (Find-Package et Install-Package) pour les trouver et les installer. PackageManagement fait cela en ayant un fournisseur de paquets pour chaque gestionnaire de paquets qui se connecte à PackageManagement. Les prestataires font tout le travail réel ; Ils récupèrent du contenu depuis les dépôts et l’installent localement. Souvent, les fournisseurs de paquets se contentent d’enrouler autour des outils de gestion de paquets existants pour un type de paquet donné.

PowerShellGet est le gestionnaire de paquets pour les paquets PowerShell. Il existe un fournisseur de paquets PSModule qui expose la fonctionnalité PowerShellGet via PackageManagement. À cause de cela, vous pouvez soit lancer Install-ModuleInstall-Package -Provider PSModule, soit installer un module depuis la PowerShell Gallery. Certaines fonctionnalités PowerShellGet, y compris Update-Module et Publish-Module, ne peuvent pas être accessibles via les commandes PackageManagement.

En résumé, PowerShellGet est uniquement axé sur une expérience premium de gestion de paquets pour le contenu PowerShell. La gestion des paquets vise à exposer toutes les expériences de gestion de paquets à travers un ensemble général d’outils. Si vous trouvez cette réponse insatisfaisante, il y a une longue réponse en bas de ce document, dans la section Comment la gestion des paquets est-elle réellement liée à PowerShellGet ?

Pour plus d’informations, veuillez consulter la page du projet PackageManagement.

La PowerShell Gallery est une version modifiée de la NuGet Gallery. PowerShellGet utilise le fournisseur NuGet pour travailler avec des dépôts basés sur NuGet comme PowerShell Gallery.

Vous pouvez utiliser PowerShellGet contre n’importe quel dépôt ou partage de fichiers NuGet valide. Il suffit d’ajouter le dépôt en exécutant le cmdlet Register-PSRepository .

Yes.

Sous le capot, PowerShellGet exploite fortement l’infrastructure de gestion de paquets.

Au niveau de la couche cmdlet PowerShell, Install-Module est en réalité un wrapper fin autour Install-Package -Provider PSModulede .

Au niveau du fournisseur de paquets PackageManagement, le fournisseur de paquets PSModule appelle en fait d’autres fournisseurs de paquets PackageManagement. Par exemple, lorsque vous travaillez avec des galeries basées sur NuGet (comme la PowerShell Gallery), le fournisseur du paquet PSModule utilise le fournisseur du paquet NuGet pour travailler avec le dépôt.

Figure 1 : Architecture PowerShellGet

En général, nous recommandons de choisir la dernière version du module PowerShellGet (notez qu’il nécessite .NET 4.5).

Le module PowerShellGet nécessite PowerShell 3.0 ou une version ultérieure.

Par conséquent, PowerShellGet nécessite l’un des systèmes d’exploitation suivants :

• Windows 10
• Windows 8.1 Professionnel
• Windows 8.1 Enterprise
• Windows 7 SP1
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2008 R2 SP1

PowerShellGet nécessite également .NET Framework 4.5 ou plus. Pour plus d’informations, consultez Installer le .NET Framework pour les développeurs.

Il n’est pas possible de squatter les noms de paquets. Si vous pensez qu’un colis existant a pris le nom qui correspond mieux à votre colis, essayez de contacter le propriétaire du colis. Si vous n'avez pas eu de réponse dans les semaines qui suivent, vous pouvez contacter le support et l'équipe PowerShell Gallery s'en occupera.

Consultez Managing Package Owners sur PowerShellGallery.com pour plus de détails.

Nous encourageons la communauté PowerShell à collaborer pour résoudre tout différend pouvant survenir entre les propriétaires des paquets et ceux des autres paquets. Nous avons élaboré un processus de résolution des litiges que nous vous demandons de suivre avant que PowerShellGallery.com administrateurs n’interviennent.