KEMBAR78
Include the newer Microsoft.PowerShell.ThreadJob module - fixes #19742 by kilasuit · Pull Request #19744 · PowerShell/PowerShell · GitHub
Skip to content

Conversation

@kilasuit
Copy link
Collaborator

@kilasuit kilasuit commented Jun 5, 2023

PR Summary

Fixes #19742 by updating the package reference file for modules pulled from the gallery to also include the renamed Microsoft.PowerShell.ThreadJob module

PR Context

PR Checklist

@kilasuit
Copy link
Collaborator Author

kilasuit commented Jun 5, 2023

Raised this in this way as to allow for discussion on whether we should remove the currently shipped ThreadJob module or not cc @PaulHigin as I am a little concerned that doing so would have potential to break existing use if anyone is module qualifying to ThreadJob\Start-ThreadJob (including within this repo - which I'll have a look into shortly)

@kilasuit kilasuit changed the title Include the newer Microsoft.PowerShell.ThreadJob module - fixes #19742 Include the newer Microsoft.PowerShell.ThreadJob module - fix #19742 Jun 5, 2023
@kilasuit kilasuit changed the title Include the newer Microsoft.PowerShell.ThreadJob module - fix #19742 Include the newer Microsoft.PowerShell.ThreadJob module - fixes #19742 Jun 5, 2023
@kilasuit
Copy link
Collaborator Author

kilasuit commented Jun 5, 2023

looking into the failures now

@ThomasNieto
Copy link
Contributor

Doing a quick search on GitHub there are no references to the module qualified ThreadJob\Start-ThreadJob.

@pull-request-quantifier-deprecated

This PR has 25 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Small
Size       : +25 -0
Percentile : 10%

Total files changed: 4

Change summary by file extension:
.csproj : +1 -0
.json : +24 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

@kilasuit
Copy link
Collaborator Author

kilasuit commented Jun 5, 2023

The test failure is one that I've seen come up before and has nothing to do with this PR Set/New/Remove-Service cmdlet tests.Remove-Service can accept a ServiceController as pipeline input

@kilasuit kilasuit added the PowerShell-Docs needed The PR was reviewed and a PowerShell Docs update is needed label Jun 6, 2023
@kilasuit
Copy link
Collaborator Author

kilasuit commented Jun 6, 2023

I think there will need to be a minor update to docs for this PR

@kasini3000
Copy link

kasini3000 commented Jun 6, 2023

this pr renamed module from ThreadJob to Microsoft.PowerShell.ThreadJob?

Will this cause duplicate command names In multiple versions of pwsh ?
What mechanism is there to ensure that 【Microsoft. PowerShell. ThreadJob】 will be used before 【ThreadJob】when automatically importing module?

What are the differences between the two modules?
Why are the two modules forked? Why not update on ThreadJob?
Is there an RFC design specification?

"FileType": "NonProduct"
},
{
"Pattern": "Modules/Microsoft.PowerShell.ThreadJob/Microsoft.PowerShell.ThreadJob.pdb",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should avoid shipping the pdb. Can we file an issue in the threadjob repo

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue filed in the PowerShell/ThreadJob repo
Looking into the repo and it's structure to see if can get a better understanding and potentially raise a PR myself for this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adityapatwardhan adityapatwardhan added Breaking-Change breaking change that may affect users Review - Committee The PR/Issue needs a review from the PowerShell Committee labels Jun 6, 2023
@adityapatwardhan
Copy link
Member

Maintainers would like the Committee to review this breaking change of renaming the module from ThreadJob to Microsoft.PowerShell.ThreadJob.

Comment on lines 18 to +19
<PackageReference Include="ThreadJob" Version="2.0.3" />
<PackageReference Include="Microsoft.PowerShell.ThreadJob" Version="2.1.0" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not have both of them as the cmdlet names are same and autoloading might load a different module on different runs.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a Module Alias feature would help resolve this issue and others like it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JosephColvin I've raised about exactly that possible enhancement in #19745 but that won't come in anytime soon I wouldn't think.

@kilasuit
Copy link
Collaborator Author

kilasuit commented Jun 18, 2023

Currently waiting on this PR in the ThreadJob repo PowerShell/ThreadJob#29 so can then push update to this PR to resolve the conversation above by @adityapatwardhan

@daxian-dbw
Copy link
Member

Still waiting on the committee to make a conclusion.

@JamesWTruher JamesWTruher added Committee-Reviewed PS-Committee has reviewed this and made a decision and removed Review - Committee The PR/Issue needs a review from the PowerShell Committee labels Jun 28, 2023
@JamesWTruher
Copy link
Collaborator

The @PowerShell/powershell-committee discussed this (6/28/23) and suggest that proper way to achieve this is as follows:

  • Create a new version of the ThreadJob module which proxies to the new Microsoft.PowerShell.ThreadJob module
    • the proxy should include a warning message that the ThreadJob module will be deprecated and removed in PS 7.6
  • Include the new Microsoft.PowerShell.ThreadJob in the release

By taking step 1, we can avoid a breaking change and provide users a glide path to get off the old ThreadJob module which we would want to remove in PS7.6 (our next LTS after 7.4)

Implementation note:
The release YAML will need updating for the Microsoft.PowerShell.ThreadJob module for proper authorization

A new issue should be opened to track the removal of the ThreadJob module in PS7.6.

@kilasuit
Copy link
Collaborator Author

kilasuit commented Jun 29, 2023

@JamesWTruher - Just so that I am clear from the above

Currently we are waiting on a new ThreadJob release -> then can update this PR with that version number & inc the Microsoft.PowerShell.ThreadJob as currently proposed & all's good for the time being?

@JamesWTruher
Copy link
Collaborator

@JamesWTruher - Just so that I am clear from the above

Currently we are waiting on a new ThreadJob release -> then can update this PR with that version number & inc the Microsoft.PowerShell.ThreadJob as currently proposed & all's good for the time being?

sort of.

We want to be sure that the current ThreadJob module is updated with a deprecation notice (and create a proxy from ThreadJob\Start-ThreadJob to the Microsoft.PowerShell.ThreadJob\Start-ThreadJob cmdlet.

But essentially, we will ship the old ThreadJob module and the new Microsoft.PowerShell.ThreadJob module. If you must have the old behavior, you would be able to achieve this via: Import-Module -RequiredVersion x -Name ThreadJob but just typing Start-ThreadJob will auto-load the new Microsoft.PowerShell.ThreadJob module (which is why this is still technically a breaking change).

explicitly importing the new ThreadJob module should result in a warning message with the "this is going away, so you should use the Microsoft.PowerShell.ThreadJob module"

@kilasuit
Copy link
Collaborator Author

Thanks for clarifying @JamesWTruher that was how I understood it from your comment 🙂

@ghost ghost added the Review - Needed The PR is being reviewed label Jul 8, 2023
@ghost
Copy link

ghost commented Jul 8, 2023

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

@daxian-dbw
Copy link
Member

daxian-dbw commented Jul 10, 2023

@JamesWTruher A few questions:

but just typing Start-ThreadJob will auto-load the new Microsoft.PowerShell.ThreadJob module

  1. How would we guarantee Microsoft.PowerShell.ThreadJob will be the one loaded when just typing Start-ThreadJob?

  2. Who will be working on the proxy ThreadJob module? Is this PR blocked until the new proxy ThreadJob module is released? If so, I would rather to have this PR closed for now given that we don't have an ETA.

@ghost ghost removed the Review - Needed The PR is being reviewed label Jul 10, 2023
@JamesWTruher
Copy link
Collaborator

@JamesWTruher A few questions:

but just typing Start-ThreadJob will auto-load the new Microsoft.PowerShell.ThreadJob module

  1. How would we guarantee Microsoft.PowerShell.ThreadJob will be the one loaded when just typing Start-ThreadJob?
  2. Who will be working on the proxy ThreadJob module? Is this PR blocked until the new proxy ThreadJob module is released? If so, I would rather to have this PR closed for now given that we don't have an ETA.
  1. Currently, autoloading loads the first module found, and Microsoft.PowerShell.ThreadJob will be found before ThreadJob
  2. @SteveL-MSFT will have a more informed answer for this

@SteveL-MSFT
Copy link
Member

Yes, this PR is blocked until someone can develop the ThreadJob proxy module (could be part of this PR as it's just a script module).

@daxian-dbw
Copy link
Member

The proxy module shouldn't be developed in this PR, as the code should be in a different repo.
If this PR is blocked on that, then I will close this PR for now. Does it sound good to both of you?

@JosephColvin
Copy link

JosephColvin commented Jul 10, 2023 via email

@SteveL-MSFT
Copy link
Member

SteveL-MSFT commented Jul 10, 2023

The proxy module shouldn't be developed in this PR, as the code should be in a different repo. If this PR is blocked on that, then I will close this PR for now. Does it sound good to both of you?

The proxy module is really only relevant as part of PS7 due to the breaking change of ThreadJob being included in PS7 prior to renaming to Microsoft.PowerShell.ThreadJob. It's really only to provide compat for one (or two) release and provide a warning message then we can remove it.

If the issue being fixed is critical, we could also consider releasing a new version of Microsoft.PowerShell.ThreadJob as ThreadJob just to be included in PS7.

@daxian-dbw
Copy link
Member

daxian-dbw commented Jul 10, 2023

But ThreadJob is a published module in PowerShell Gallery (v2.0.3 now). If we are going to have a proxy module for it, we'd better release it to PowerShell Gallery too, maybe as v2.1, so as to formally deliver the message that this module is deprecating and Microsoft.PowerShell.ThreadJob should be one to use going forward.

Once the proxy module is published, PowerShell just need to pull it during the build, and then it's time to include Microsoft.PowerShell.ThreadJob module.

@SteveL-MSFT
Copy link
Member

SteveL-MSFT commented Jul 10, 2023

@daxian-dbw I agree it would make sense to have the ThreadJob module on PSGallery also indicate being deprecated and using Microsoft.PowerShell.ThreadJob instead. In that case, I would also agree that proxy module would be done outside of this PR and repo since it's published to PSGallery. It would make sense to have that proxy developed in https://github.com/powershell/threadjob

GitHub
Contribute to PowerShell/ThreadJob development by creating an account on GitHub.

@daxian-dbw
Copy link
Member

Opened PowerShell/ThreadJob#30 to track the proxy module work. I will close this PR for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Breaking-Change breaking change that may affect users Committee-Reviewed PS-Committee has reviewed this and made a decision PowerShell-Docs needed The PR was reviewed and a PowerShell Docs update is needed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PowerShell ships ThreadJob not Microsoft.PowerShell.ThreadJob

10 participants