PowerShell / PowerShell/PSResourceGet

Please support git/http

Offen
#165 10 Kommentare 13 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Area-PSRepository feature_request help wanted Needs-Triage Status-Investigating
Vorherrschende Sprache
C#
Sterne
576
Forks
114
Ø Merge
1 T. 2 Std.
Gemergte PRs (30 T.)
7

Beschreibung

I'd like to suggest offering support for git/http based repositores.

PowerShellGet 2 supports only NuGet or SMB repositories. NuGet repositories like powershellgallery.com (PSG) is great as a platforum to centrally distribute (especially binary) modules.

Disadvantages of NuGet and SMB repositories

It's an entry barrier because after you commited the code to your git repository, you need additional steps to publish the module to PSG, starting by registering a PSG account and retrieving an API key. Then you must maintain the code repository as well as the PSG repository.

For company-use this is even more of a burden. Modules may be company-internal, meaning that they cannot be published at PSG. In addition to the above, you require a NuGet repository, which requires a server, a repository service and specific knowldge, which in turn requires more staff, more budget and more time. Alternatively you can rely on SMB repositories, which require nothing more than a file server. However, there may be limitations due to security concerns or file share permission management.

Advantages of git/http repositories

With git/http support, you would be able to install a module from any git server, regardless of the transport protocol. Publishing modules would be integrated into the development flow. Modules can be locally developed and pushed into any git repository, be it local or on an SMB share, on GitHub, GitLab or BitBucket. From there PowerShellGet 3 should be able to download them via SMB or http GET.

This would enable beginners or maintainers of smaller modules to keep all of their workflow on the same platform.

This would also enable companies to develop internal-use modules and distribute them using already available tools.

How it could work

Take a look at the built-in Go package management. Modules can be directly published to github (instead of something like npm or pypi) and can be retrieved and with e.g. go get github.com/google/codesearch/index.

Without knowing how Golang solved this, one example would be like this: Let's say we want to publish a module named CompanyADUserTools.

  • The master branch would be the current stable version of the module. Tags are used for versioning and they must be equal to the version string in the module metadata (psd1).
  • To install the module, you could do Install-Module https://gitlab.intranet.company.com/it/CompanyADUserTools.
  • This would get the module from the master branch.
  • To publish a new version, merge the changes into master and tag it as a new version.
  • To update the module you would then run Install-Module https://gitlab.intranet.company.com/it/CompanyADUserTools. PowerShellGet would then compare the installed version with the master branch versions, or simply just get the current master branch.
  • Using tags you can install older versions of the module.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

In der Issue werden keine Dateien oder Tests genannt. Beginne damit, die vorhandenen Repository- und Modulinstallationspfade von PSResourceGet zu überprüfen, und vergleiche dann den angeforderten git/HTTP-Workflow mit dem Beispiel zur Go-Paketverwaltung; abgeschlossen ist die Aufgabe, wenn getaggte Modulversionen aus git- oder HTTP-Repositorys installiert, aktualisiert und ausgewählt werden können.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
git, powershell
Bereich
cli, devtools
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
25/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.