Kirk Munro

My feedback

  1. 20 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Storage  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
  2. 11 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  PowerShell » Microsoft.PowerShell.* Modules  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro commented  · 

    +1, and open source, please.

    Kirk Munro supported this idea  · 
  3. 21 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Linux Support » Virtualization  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
    Kirk Munro commented  · 

    Now that PowerShell Core has reached RTM, it would be great to get an idea of whether or not this is coming...

  4. 7 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  5 comments  ·  PowerShell » Package Management  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
    Kirk Munro commented  · 

    Yeah, this cmdlet shouldn't just carbon-copy the Save-Module behaviour because the use case is different. My gut reaction to this is that it should (a) only download what modules you don't already have, and (b) prompt you first before downloading them, with a way to get all/get just the script without prompting using parameters. Having it download modules that you already have is wrong. Having it download modules you don't have without an option to not download those is wrong. Why would you bother download a binary module, which in the case of Azure may be part of a sizeable package, when you just want to take a closer look at a script?

  5. 16 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  14 comments  ·  PowerShell » Microsoft.PowerShell.* Modules  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
    Kirk Munro commented  · 

    IMHO ConvertTo-Json/ConvertFrom-Json functions a little like taking a sentence or paragraph through an online translator to and from different languages over and over. I just took part of Joel's example and did the following:

    PS C:\Users\Poshoholic\Documents> rv x
    PS C:\Users\Poshoholic\Documents> '[
    >> [
    >> "Foo",
    >> 1
    >> ],
    >> [
    >> "Bar",
    >> 2
    >> ]
    >> ]' | ConvertFrom-Json -OutVariable x > $null
    PS C:\Users\Poshoholic\Documents> $x.GetType().FullName
    System.Collections.ArrayList
    PS C:\Users\Poshoholic\Documents> ,$x | gm Count

    TypeName: System.Collections.ArrayList

    Name MemberType Definition
    ---- ---------- ----------
    Count Property int Count {get;}

    PS C:\Users\Poshoholic\Documents> ConvertTo-Json $x
    [
    {
    "value": [
    [
    "Foo",
    1
    ],
    [
    "Bar",
    2
    ]
    ],
    "Count": 2
    }
    ]

    This makes no sense. If the original JSON I gave ConvertFrom-Json converts to an ArrayList, which does not have any extended members added to it, then why does ConvertTo-Json give me JSON that now represents an object array with one member, a PSCustomObject, with a value object array (that in turn contains two object arrays) and a count property. Wtf?

  6. 18 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  1 comment  ·  PowerShell » Documentation  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
  7. 6 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro commented  · 

    FYI to readers of this issue, if you're not sure what the issue is, do the following on a Windows 10 system:

    PowerShell -version 2
    ipmo PSWorkflow

    The issue with that error is twofold:

    1. It means that if a user tries to import any module that uses a "new" (not part of the current version of PowerShell you are in) manifest key, they get an unintuitive error, even if the module PSVersion clearly defines the minimum version that is required. e.g. If the module indicates PSVersion = 3.0, and if the manifest includes HelpInfoUri, and if you try to import that module on PSv2, rather than getting an error indicating that the module requires PowerShell 3.0 or later, users get a horrible error indicating that the manifest contains an invalid key. This is a horrible UX for end users who care nothing about the details of manifest keys.

    2. It means that in broader scenarios where manifest keys would be useful for tools like PowerShellGet, like the PrivateData section that was added for publishing to a PowerShell Gallery, those keys must go in PrivateData in order for downlevel support to be added because downlevel versions of PowerShell will always throw the error like you see above as long as the current logic remains as it is. Instead, PowerShell could simply ignore the keys that it does not recognize, trusting the module author that they are there for a reason.

    Downlevel support is really important, and the current approach (PrivateData) feels more like a hack than a solution. This change should have been done in PowerShell 3.0. Please vote this up.

    Kirk Munro supported this idea  · 
  8. 4 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
  9. 5 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  0 comments  ·  PowerShell » PowerShell Gallery  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
  10. 7 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  0 comments  ·  PowerShell » PowerShell Gallery  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro shared this idea  · 
  11. 146 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    8 comments  ·  Active Directory  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
  12. 21 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PowerShell » ISE and tooling  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro shared this idea  · 
  13. 55 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    8 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    survey  ·  Zachary Alexander responded

    Thank you for your input. Based on its current ranking compared to other feedback items and product schedule, work on this item is pending (and will be driven by) further customer input.

    Kirk Munro commented  · 

    I also agree opening this up to the community for interpretation would be a bad idea. The community (including product teams within Microsoft) have demonstrated that it is very easy to misinterpret how command names should be created, and everyone wants to be an exception. Let's keep the verb list small/regulated, but focus on getting the PowerShell team to add verbs that are missing that would make sense by logging suggestions on UserVoice.

    Kirk Munro commented  · 

    @Derp: What if you're sharing what you compile on a web service somewhere? Do you Publish the code into a compiled result, and then you Publish the result to the web service? That's just confusing.

    Kirk Munro commented  · 

    @Chris: As a developer I really don't like the idea of ConvertTo-Binary (or ConvertTo-CompiledExe or anything similar). Sure, it's converting the project code to machine code, assembling it into a package, etc. I still wouldn't like ConvertTo-ExecutableMachineCodePackage as a name. There really should just be "Compile" imho, because internally while I may call an exe to do the invocation, if I were to do that I would only do so because a programmatic API to do the same was not available. The verb that best describes what is being done, regardless of the technical details that describe how it is being done internally, is Compile.

    Kirk Munro shared this idea  · 
  14. 19 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
  15. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →

    Thanks for the suggestion. This has been filed as a doc bug.

    Based on its current ranking compared to other feedback items and product schedule, work on this item is pending (and will be driven by) further customer input. If you did not open this issue and are also impacted by it, please vote this item up.

    Kirk Munro shared this idea  · 
  16. 6 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PowerShell » Microsoft.PowerShell.* Modules  ·  Flag idea as inappropriate…  ·  Admin →

    We understand that this would allow a single-point expression of MinimumVersion and MaximumVersion. However, it’s unclear why changing to that nomenclature going to be a high priority. Additional information, particularly about why the existing functionality is insufficient – would help – thanks!

    Kirk Munro commented  · 

    This should help:

    [1.0,2.0) is currently not possible with MinimumVersion and MaximumVersion. You'd have to fake it with MinimumVersion='1.0';MaximumVersion="1.$([int]::MaxValue).$([int]::MaxValue).$([int]::MaxValue)", would you not? I think that's the main desired scenario, where you know that you support [x,y), but not [y] because a breaking change was introduced in that version of the module. This nomenclature allows us to address that issue, which can become necessary under a large number of scenarios (the module you were using increases their minimum requirement with a new version to something that is too high for you to take on with a given version of your module, breaking changes are introduced that require changes in your module, and so on).

    From the referenced versioning doc, these other scenarios do not seem to be supported with the current version keys that are available today:

    (,1.0) = x < 1.0
    (1.0,) = 1.0 < x
    (1.0,2.0) = 1.0 < x < 2.0

    Essentially, the round bracket part of the proposed version nomenclature is a big part of what is missing today.

    Something else worth considering here, that isn't mentioned in the Nuget versioning doc: if an unintentional breaking change was released to the wild, and if it was only discovered a few versions later then you may want to specifically exclude that version (or series of versions that were out with the breaking change) using nomenclature that supports it. For example:

    '[1.0,2.4.1],[2.5.3,)' # supports versions 1.0 up to 2.4.1, inclusive, and 2.5.3 onwards

    I think that is an important extension to consider with this nomenclature change, because it can and does happen in the field, and ultimately this would ensure that known broken scenarios occur less often once they are fixed.

    Kirk Munro supported this idea  · 
  17. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » Other PowerShell  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro supported this idea  · 
  18. 6 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » Microsoft.PowerShell.* Modules  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro shared this idea  · 
  19. 18 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PowerShell » Package Management  ·  Flag idea as inappropriate…  ·  Admin →

    Thanks for the comment. We will be monitoring this to see how many users are impacted by / recommending it.

    Kirk Munro supported this idea  · 
  20. 4 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » ISE and tooling  ·  Flag idea as inappropriate…  ·  Admin →
    Kirk Munro shared this idea  · 
← Previous 1

Feedback and Knowledge Base