Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Publish-Module Violates Single Responsibility Principle #1393

Open
fourpastmidnight opened this issue Sep 6, 2023 · 5 comments
Open

Publish-Module Violates Single Responsibility Principle #1393

fourpastmidnight opened this issue Sep 6, 2023 · 5 comments
Labels
Area-nupkg Area-Publish feature_request
Projects
1.1
Milestone
vNext

Comments

@fourpastmidnight
Copy link

Summary of the new feature / enhancement

As a user, I expect Publish-Module to publish a module, not package AND publish a module. As a user, I also expect that I can issue Package-Module to create a new module package that can then be published to one or more places, such as the PowerShellGallery and/or private package feeds.

Proposed technical implementation details (optional)

For example, the following workflows are what I desire:

PS C:\MyProject> Package-Module -Path ./out/MyModule

 ModuleName      Version    Path
 ----------      -------    -------------------------
 MyModule        1.0.0      C:\MyProject\artifacts\MyModule-1.0.0.nupkg

and then, combined with Publish-Module, perhaps something like:

PS C:\MyProject> Package-Module -Path ./out/MyModule -PassThru | Publish-Module ...
@ThomasNieto
Copy link
Contributor

I also have had the same concern for a while. I would have wanted a New-PSResource or Build-PSResource and publish only pushes the resource to the repository.

@ThomasNieto
Copy link
Contributor

@SydneyhSmith I know this is close to release but the existing functionality is already there just splitting it into two cmdlets.

@SydneyhSmith
Copy link
Collaborator

We have been wanting to support publishing already built packages (nupkgs), and may need to in order to support certain repositories in the future...this won't block RC but I agree that it would be nice to have a Build-PSResource type command and support either unpacked modules or nupkgs as input for Publish-PSResource, probably as different parameter sets

@SydneyhSmith
Copy link
Collaborator

Today you can sort of accomplish this by using the -DestinationPath parameter on Publish

@SydneyhSmith SydneyhSmith added this to the vNext milestone Sep 11, 2023
@leoniDEV
Copy link

The problem with the -DestinationPath is that the command still try to upload the package to remote repository and if you don't provide an API key the command fail (after blocking the command line for a while) with a 401 error

michaeltlombardi added a commit to michaeltlombardi/Documentarian that referenced this issue Nov 22, 2023
@michaeltlombardi
(microsoftGH-116) Add local packaging task to module build script
38c44e6 
Prior to this change, the only way to get a local build for a
packaged module was to manually register a local PSRepository,
build and publish the module (manually publishing and external
dependencies too), then review the `.nupkg` files.

This change:

- Creates the `Projects/ModulesTools/LocalRepoFunctions.ps1`
  script with helper functions for interacting with a temporary
  local repository, handling both PSResourceGet and PowerShellGet.

  It has functions to get/register/unregister the local repository,
  and to get, remove, and publish packages to the local repository.
- Adds the new `Package` task to the shared build script, _not_
  on a per-module basis. This task is invoked from `Projects/Modules`
  as:

  ```powershell
  Invoke-Build -Task Package
  ```

  To compose and then package, run:

  ```powershell
  Invoke-Build -Task Compose, Package
  ```

  At the end of the package step, all specified modules and any of
  their defined dependencies are published to the local repository.
  By default, this is in `Projects/Modules/.repository`. At the
  end of the task, the local repository is unregistered so as not
  to conflict with any other repositories.
- This doesn't resolve (entirely) microsoft#116, which should implement
  per-module building and task management - however, it involved a
  significant amount of code for custom handling the packaging. For
  microsoft#116, we should instead wait for PowerShell/PSResourceGet#1393 and
  PowerShell/PSResourceGet#1034 to be resolved, and then we can use
  the built-in option to package the modules.

  Alternatively, we could explore using `dotnet pack` to package the
  modules after defining the `.nuspec` files ourselves. This would
  require a bit more work and introduce another dependency, but would
  be more portable and avoid the multi-API handling we have to do now.

  The last alternative is to just bump the required version for building
  modules to `7.4` or requiring **PSResourceGet** to be installed for
  the **Documentarian.DevX** module. This would be the easiest option.
@michaeltlombardi michaeltlombardi mentioned this issue Nov 22, 2023
Merged
4 tasks
michaeltlombardi added a commit to michaeltlombardi/Documentarian that referenced this issue Nov 22, 2023
@michaeltlombardi
(microsoftGH-116) Add local packaging task to module build script
81cd15d 
Prior to this change, the only way to get a local build for a
packaged module was to manually register a local PSRepository,
build and publish the module (manually publishing and external
dependencies too), then review the `.nupkg` files.

This change:

- Creates the `Projects/ModulesTools/LocalRepoFunctions.ps1`
  script with helper functions for interacting with a temporary
  local repository, handling both PSResourceGet and PowerShellGet.

  It has functions to get/register/unregister the local repository,
  and to get, remove, and publish packages to the local repository.
- Adds the new `Package` task to the shared build script, _not_
  on a per-module basis. This task is invoked from `Projects/Modules`
  as:

  ```powershell
  Invoke-Build -Task Package
  ```

  To compose and then package, run:

  ```powershell
  Invoke-Build -Task Compose, Package
  ```

  At the end of the package step, all specified modules and any of
  their defined dependencies are published to the local repository.
  By default, this is in `Projects/Modules/.repository`. At the
  end of the task, the local repository is unregistered so as not
  to conflict with any other repositories.
- This doesn't resolve (entirely) microsoft#116, which should implement
  per-module building and task management - however, it involved a
  significant amount of code for custom handling the packaging. For
  microsoft#116, we should instead wait for PowerShell/PSResourceGet#1393 and
  PowerShell/PSResourceGet#1034 to be resolved, and then we can use
  the built-in option to package the modules.

  Alternatively, we could explore using `dotnet pack` to package the
  modules after defining the `.nuspec` files ourselves. This would
  require a bit more work and introduce another dependency, but would
  be more portable and avoid the multi-API handling we have to do now.

  The last alternative is to just bump the required version for building
  modules to `7.4` or requiring **PSResourceGet** to be installed for
  the **Documentarian.DevX** module. This would be the easiest option.
@SydneyhSmith SydneyhSmith mentioned this issue Feb 12, 2024
Open
1 task
@SydneyhSmith SydneyhSmith mentioned this issue Apr 15, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-nupkg Area-Publish feature_request
Projects
1.1
Awaiting triage
Milestone
vNext
Development

No branches or pull requests
4 participants
@fourpastmidnight @leoniDEV @ThomasNieto @SydneyhSmith