Adicione informações sobre como você deseja aprimorar o idioma do PowerShell para adicionar a versão. No atributo cmdletbinding?

Minha ideia era fazer algo como New-ScriptFileInfo, que gera um cabeçalho de comentário como este:

<#PSScriptInfo

.VERSION 1.0

.GUID 66c837b7-6478-4571-9dec-0621e13df4c3

.AUTHOR Jeff

.COMPANYNAME

.COPYRIGHT 2020

.TAGS

.LICENSEURI

.PROJECTURI

.ICONURI

.EXTERNALMODULEDEPENDENCIES 

.REQUIREDSCRIPTS

.EXTERNALSCRIPTDEPENDENCIES

.RELEASENOTES


.PRIVATEDATA

#>

<# 

.DESCRIPTION 
 This is a cool function 

#> 
Param()

Torne-o PSFunctionInfo e faça com que Get-Command o analise. Ou, da mesma forma que o PowerShell pode analisar #requires, faça com que ele analise #version. Quando fica complicado é quando você tem várias funções no mesmo arquivo ps1, então qualquer coisa que eu fizesse como autor de uma função precisaria ser incluída na função. Pode ser um bloco de comentário analisado, uma nova opção cmdletbinding () ou talvez um atributo totalmente novo.

Function Get-Awesomeness {

 [cmdletbinding()]
 [alias("awe")]
 [outputtype("psobject")]
 [version("1.1.0")]

 Param ()

 ...
}

Não vejo valor no recurso. Podemos publicar no PowerShellGet e distribuir scripts do PowerShell como apenas módulos, não podemos fazer isso para arquivos. Você pode descrever um caso de negócios / fluxo de trabalho?

Muitas pessoas criam soluções PowerShell que nunca são publicadas na galeria. Eles são usados ​​internamente, digamos em um ambiente corporativo. E nem tudo é empacotado em um módulo. Posso trabalhar em um ambiente corporativo e ter um arquivo de script autônomo com uma função. Desejo ter a capacidade de controlar a versão dessa função. Se eu executar Get-Command Get-CompanyFoo, preciso ver o número da versão. Por falar nisso, mesmo em um módulo, todas as funções exportadas compartilham o mesmo número de versão. Eu gostaria de ter a facilidade de rastrear as informações de versão por função. E, claro, sem ter que depender da leitura do código-fonte. Se um técnico de help desk está usando uma das minhas funções, ele precisa ser capaz de usar o PowerShell para descobrir a versão do comando.

Certamente, nem todas as funções precisam disso, mesmo aquelas em um módulo. Não tenho nenhum problema com uma função em um módulo usando a versão do módulo se nenhuma versão específica do comando for detectada.

@jdhitsolutions Obrigado!

Vejo dois componentes em seu cenário - (1) um sistema de rastreamento de versão, (2) um sistema de distribuição.
O primeiro poderia ser GIT (outros?).
Não está claro como você distribui arquivos de script.

(Estou tentando entender onde é o lugar certo para o atributo solicitado.)

Deixo funções nos clientes regularmente, que estão atualizadas desde a última vez que as usei naquele cliente em particular. Um que usei em um cliente hoje me vem à mente - getWUlog. Ele sabe como se conectar a um sistema remoto usando WinRM e psexec (verifica se 139 ou 5985 estão abertos) e recuperar o log do WindowsUpdate desse computador, recuperá-lo no computador local e abrir o bloco de notas.

Outra é getFrameworkVersion. Faz exatamente isso - procura encontrar a versão do .NET Framework instalada em um determinado computador, usando o CIM ou o serviço de registro remoto (novamente - verifica as portas para descobrir o que fazer), relata essas e relata quais versões estão bloqueadas, caso existam.

Estas são funções autônomas. Não faz parte de um módulo. Mas eles passaram por atualizações regulares nos últimos anos.

Seria ótimo anexar uma versão a cada um deles. No momento, tenho apenas uma "data da última modificação" no topo da fonte. Não tão útil ...

A distribuição é irrelevante em minha mente para esta discussão. E sim, git desempenha um papel, mas não é o problema. Se eu estiver no PowerShell e usando uma função autônoma. Quando executo Get-Command Get-Foo, quero ver o número da versão da função. É tão simples quanto isso. Não importa como a função foi distribuída. Dê-me uma maneira de injetar metadados na função.

E para ser absolutamente claro, não quero forçar um usuário, ou mesmo eu, a rastrear a fonte e procurar comentários ou notas.

Eu definitivamente escrevo / uso algumas funções autônomas, mas a maioria é em módulos. E a maioria delas são ferramentas de fragmentos aleatórios que podem ser usadas como funções autônomas. Eu sempre coloco versões semânticas e changelogs em .NOTES dentro do bloco de comentários, e [version]$Version no bloco inicial, porque quero acompanhar quais alterações fiz em uma função específica, não apenas para o módulo (que eu incremento quando faço alterações nas funções internas). Ter algo como [version()] ou [cmdletbinding(Version='01.00.0000')] seria espetacular; Gosto mais dele do que .VERSION porque sei que muitas pessoas colocam várias funções em um arquivo psm1 (embora eu não faça isso).
Eu uso git, também, btw, mas não me comprometo toda vez que faço uma alteração em uma função individual; Eu os empacotei e confirmo quando mudo o módulo, geralmente com a versão do módulo como a mensagem de confirmação. Sim, sim, eu sei, sou estranho.

Se o script for encontrado em $env:PATH , ele aparecerá para Get-Command. Portanto, parece razoável mapear os metadados ScriptFileInfo existentes para os membros ExternalScriptInfo que incluem a versão.

Tenha cuidado com essa suposição, Steve. Posso ter um único arquivo ps1 com várias funções. Não quero confiar que Get-Command pode encontrar o arquivo de script. Caramba, talvez eu queira definir uma função com versão em um script de perfil do PowerShell.

Definitivamente tenho funções versionadas no script do meu perfil.

Já temos o tipo System.Management.Automation.FunctionInfo que tem uma propriedade Version. Precisamos de uma maneira para que, quando a função for carregada, a propriedade de versão seja preenchida a partir de metadados na função.

Obrigado a todos pelo ótimo feedback! Eu ainda tenho algumas perguntas. Qual comportamento você espera se o PowerShell encontrar algumas funções com o mesmo nome? Executar função com versão superior? Devemos levar em conta os escopos (você carrega na função antiga do escopo atual - devemos chamar mais funções novas do escopo global)? Ou queremos ter apenas atributo informativo?

Não se trata de executar ou distribuir funções. Eu gostaria apenas de um mecanismo que fornecesse uma maneira de rastrear e descobrir informações de versão para que, se eu executar Get-Command, ou talvez um novo comando como Get-Function, possa ver alguns metadados sobre a função. Tenho algumas ideias que posso tentar criar um protótipo por meio de scripts do PowerShell.

Obrigado a todos pelo ótimo feedback! Eu ainda tenho algumas perguntas. Qual comportamento você espera se o PowerShell encontrar algumas funções com o mesmo nome? Executar função com versão superior? Devemos levar em conta os escopos (você carrega na função antiga do escopo atual - devemos chamar mais funções novas do escopo global)? Ou queremos ter apenas atributo informativo?

Não creio que alguém tenha sugerido qualquer mudança na forma como o PS executa as funções. Queremos apenas colocar uma versão deles. Informativo e uma forma de interrogar mesmo.

Obrigado! Próxima pergunta que tenho. Um arquivo com algumas funções pode ter um atributo de versão comum para todas as funções no arquivo. Devemos considerar isso?

Tenho algumas ideias que posso tentar criar um protótipo por meio de scripts do PowerShell.

Você pode compartilhar as ideias na essência.

Esse é o meu plano.

Deve ser a versão clássica ou SymVer 2.0?

Estou cada vez mais convencido de que o controle de versões de funções é uma coisa boa.

Para responder à última pergunta de

E com relação a um arquivo de funções - eu diria que o atributo é por função, sem atributos por arquivo. Muito parecido com o CMDLETBinding de hoje.

O protótipo é puxado para dentro ## 11686

Você pode baixar um artefato do PR e brincar com o novo atributo.

Doce.

Pensando nisso, por que não estender o PSVersionAttribute para incluir a versão do script. Se criarmos versões de módulos e (espero que agora!) Funções, por que não scripts?

O PSVersionAttribute também pode servir como um valor padrão para funções definidas no script.

E antes que alguém pergunte ... A execução da função pode ser versionada?

Poderíamos carregar várias versões de uma função, executar a mais recente por padrão, mas ter um parâmetro comum -PSFunctionVersion que informa qual versão específica executar.
Sem dúvida, existem mais alternativas - mas devemos fornecer execução de função com versão?

Se for um atributo, você pode apenas reutilizá-lo, da mesma forma que [CmdletBinding()] pode ser aplicado a funções e scripts, você sempre pode usar [PSVersion()] para funções e scripts. Esta parece ser uma abordagem interessante. 🙂

Não prevejo muito uso desse tipo de coisa em módulos, onde já temos o código versionado em sua maior parte, mas para scripts e funções autônomos, isso pode ser realmente muito interessante 🙂

Não se trata de executar ou distribuir funções. Eu gostaria apenas de um mecanismo que fornecesse uma maneira de rastrear e descobrir informações de versão para que, se eu executar Get-Command, ou talvez um novo comando como Get-Function, possa ver alguns metadados sobre a função. Tenho algumas ideias que posso tentar criar um protótipo por meio de scripts do PowerShell.

Se quisermos adicionar controle de versão de função, por que limitá-lo apenas à documentação? Se eu puder especificar e consultar versões de funções, não seria sensato permitir a execução com base no número da versão?

Uma forma de carregar várias versões de uma função e poder escolher aquela para executar, ou permitir ao usuário escolher entre diferentes versões para carregar na lista de funções que vemos com o gcm e então executar aquela.

Portanto, aqui está uma prova de conceito que desenvolvi com base nos comandos ScriptFileInfo:
https://gist.github.com/jdhitsolutions/65070cd51b5cfb572bc6375f67bcbc3d

O que realmente estou tentando modelar ou prototipar é a experiência. Prefiro ter os dados expostos com Get-Command, porque já existe um tipo apropriado.

E obter uma mistura de arquivos.

Se uma função pertence a um módulo, não vou me preocupar com o controle de versão do comando. Isso deve ser tratado pelo módulo.

Essência

Uma prova de conceito para adicionar e obter informações de metadados do PowerShell

Uma prova de conceito para adicionar e obter informações de metadados do PowerShell - PSFunctionInfo.format.ps1xml

Jeff legal!

Então, como lidamos com várias versões da mesma função?
Como alguém carrega explicitamente uma versão de função específica?
Como alguém executa explicitamente uma versão específica de uma função?

@doctordns Você é responsável por descobrir o que executar e lidar com várias versões. Meu código de protótipo está simplesmente listando itens na FunctIon: Psdrive e exibindo informações de metadados. Pelo que eu sei, você não pode ter funções duplicadas no psdrive. Meu objetivo é, se eu tiver uma função autônoma carregada, eu quero ser capaz de recuperar a versão e possivelmente outras informações de metadados.

Embora eu ache que seria maravilhoso se o PowerShell suportasse os metadados _embedded_ PSScriptInfo para _scripts_ ... por favor, não faça isso no nível de _função_.

As versões só são úteis se você puder fazer algo a respeito

O PowerShell atualmente _reporta_ a versão nos comandos, mas a versão real vem do _module_. Ter versões separadas para cada função não seria útil, seria apenas confuso. Independentemente de como você distribui seu código, você não está distribuindo "pedaços" de subarquivos e o usuário não pode carregar uma função individual (ou qualquer coisa exceto um arquivo completo) - então não há por que tentar versioná-los.

Acho que precisamos de versões para módulos e scripts. As funções devem herdar sua versão do _módulo_ que as contém. Os scripts precisam de sua própria versão.

Para registro:

Se você tiver um arquivo .ps1 com várias funções, será necessário alterar a extensão. Do contrário, os usuários não terão como descobrir essas funções, portanto, o controle de versão não importa. Devemos desencorajar ativamente qualquer pessoa que tente distribuir _funções_ em qualquer coisa que não seja um módulo. 🤨

@Jaykul Concordo que, se uma função for fornecida com um módulo, que deve ser o objetivo, a versão do módulo é importante. No entanto, há muitos usos que usam funções autônomas. Pode ser carregado em um perfil ou com origem em um ponto para atender a uma necessidade específica. Nem tudo que faço precisa ser carregado e integrado em um módulo. São essas funções não modulares que desejo gerenciar. Quero uma maneira de capturar a versão e outras informações de metadados, assim como fazemos para comandos carregados de um módulo. Talvez a resposta seja um novo comando como o meu protótipo.

@Jaykul Acho que vários de nós já disseram que seria, de fato, útil para nós e que estamos, de fato, distribuindo funções únicas.

IMO, nem tudo precisa de um módulo.

O recurso proposto pode não ser útil para você. E tudo bem. Mas é para outros de nós.

Eu gosto da ideia de controle de versão de função. Mas se fizermos uma solução, deve ser mais do que uma pequena documentação que você poderia fazer nos comentários Sem a capacidade de controlar o carregamento de diferentes versões, etc., este é um recurso que talvez possamos dispensar por enquanto.

Eu sugiro que abandonemos essa ideia para o 7.0. Estamos MUITO perto da RTM para introduzir novos recursos no mix. Tenho más recordações de NT 5 dias !! Se pudermos empurrar de volta para 7.1, ENTÃO vamos ter uma conversa mais completa sobre como implementá-lo totalmente. Tentar apenas empurrar isso no último minuto é uma maneira certa de causar decepção.

Se isso acontecer, é uma adição de 7.1. Acho que a questão de carregar a versão correta é com o usuário. Novamente, tudo o que estou pedindo é uma maneira de recuperar informações de versão de uma função autônoma carregada sem ter que vasculhar o código-fonte.

Eu concordo com 7.1.

Ao mesmo tempo, conheço os usuários e aposto uma ou três garrafas que uma solução de documentação só gerará solicitações de recursos de tempo de execução baseados em versão. Gostaria que considerássemos uma solução completa e elegante, além de bem projetada. .

Já temos uma solução para funções autônomas - o último carregado vence. :-)

Sem a capacidade de controlar o carregamento de diferentes versões, etc., este é um recurso que talvez possamos dispensar por enquanto.

Isso nos forçaria a verificar a versão da função cada vez que ela é chamada. Isso é totalmente inaceitável por motivos de desempenho. O módulo é o melhor meio-termo - a verificação da versão é feita uma vez no carregamento do módulo.

@ SteveL-MSFT Eu acredito que está pronto para a conclusão do Comitê do PowerShell. Protótipo # 11686.

Parece que todos concordam que é útil ter uma versão para scripts no motor.
A versão para funções está em questão porque existe a concepção do módulo.

A limitação comum é que só podemos ver versões de scripts e funções carregados e não podemos fazer o que o import-module faz - carrega a versão necessária, mas get-module também não tem parâmetros de versão explícitos.

Não pense demais nisso ou torne-o mais complicado do que o necessário. As funções enviadas com os módulos pertencem ao módulo. Ponto final. Essa deve ser a melhor prática recomendada. No entanto, nem todas as funções que podem ser usadas na produção são implantadas com um módulo. Na verdade, não me importo com a forma como ele é implantado. Tudo o que estou dizendo é que desejo uma maneira de ver uma função carregada na Função: PSDrive e ser capaz de ver um número de versão e talvez algumas outras informações de metadados. Não quero forçar a mim mesmo ou a um usuário final a rastrear o código-fonte ou a pasta para descobrir informações de versão.

Eu esperava que Get-Command fosse a ferramenta para coletar essas informações, mas talvez isso precise ser dividido em algo completamente separado para gerenciamento de função autônomo.

E talvez a resposta seja que é melhor deixar esse problema para a comunidade resolver. Nesse caso, acho que tenho um bom começo para uma solução.

A verdade honesta aqui é que as funções de dot sourcing não são o caminho correto a se seguir e não deveriam ter sido recomendadas anos atrás, quando o sistema de módulo veio na v2. O único momento em que foi remotamente adequado para uso foi na v1.

Como todos sabemos agora, todas as funções devem ser colocadas realisticamente em um módulo, mesmo aquelas que você está carregando como parte de seu perfil (que você deve carregar o módulo que contém essas funções) ou usando como parte de um script maior para facilitar a manutenção, ou mesmo aquelas funções singulares que você precisa usar em scripts xyz.

Eu só posso ver que essa mudança adicionaria mais confusão para aqueles que vêm para a linguagem do que benefícios, adicionando o atributo [Version] sugerido às definições de função, com muitos pensando que seriam obrigados a definir versões de Módulo e Função quando estiverem fazendo coisas corretamente e realmente construir módulos de código reutilizável.

Sim, isso significa que você precisa ter um psd1 e um psm1, mas 2 arquivos para uma detecção e manutenção adequadas não é uma tarefa difícil para gerenciar realmente

Como você pode dizer, eu pessoalmente discordo dessa mudança e acho que há coisas melhores em que se concentrar

Sim, isso significa que você precisa ter um psd1 e um psm1, mas 2 arquivos para uma detecção e manutenção adequadas não é uma tarefa difícil para gerenciar realmente

Sim, é uma grande pergunta. Tentar transformar scripts de administrador em desenvolvedores aumenta significativamente a barreira de entrada.

Dizer "oh, você tem que copiar isso aqui, copiar ali e depois importar" é muito mais complicado e muito mais sujeito a erros do que dizer "copie e cole em um arquivo chamado run.ps1 e digite, \ run .ps1 ".

Esta é uma pequena mudança e beneficia os criadores de scripts casuais / admin muito mais do que os operadores ternários ou coalescência nula (que eu ainda não entendo) ou muitas outras mudanças recentes que foram feitas para aqueles de vocês que são desenvolvedores. Como já foi dito sobre elas, posso falar sobre as versões de funções: se você não gosta, não use.

@ SteveL-MSFT Acredito que o comitê do PowerShell poderia examinar a solicitação de versões de suporte para scripts e funções autônomas. O protótipo está em # 11686.

A verdade honesta aqui é que as funções de dot sourcing não são o caminho correto a seguir,

Mas as pessoas fazem isso e, de qualquer maneira, não é o único caso de uso para essa solicitação.

e não deveria ter sido recomendado todos aqueles anos atrás, quando o sistema de módulo veio na v2. O único momento em que foi remotamente adequado para uso foi na v1.

Como todos sabemos agora, todas as funções devem ser colocadas realisticamente em um módulo, mesmo aquelas que você está carregando como parte de seu perfil (que você deve carregar o módulo que contém essas funções) ou usando como parte de um script maior para facilitar a manutenção, ou mesmo aquelas funções singulares que você precisa usar em scripts xyz.

Eu só posso ver que essa mudança adicionaria mais confusão para aqueles que vêm para a linguagem do que benefícios, adicionando o atributo [Version] sugerido às definições de função, com muitos pensando que seriam obrigados a definir versões de Módulo e Função quando estiverem fazendo coisas corretamente e realmente construir módulos de código reutilizável.

Sim, isso significa que você precisa ter um psd1 e um psm1, mas 2 arquivos para uma detecção e manutenção adequadas não é uma tarefa difícil para gerenciar realmente

Sim, mas isso não é relevante. Ninguém está argumentando que não devemos criar versões de módulos. ;-)

Como você pode dizer, eu pessoalmente _discordo_ com essa mudança e acho que há coisas melhores em que me concentrar

Você não seria obrigado a usá-lo. Você não é realmente forçado a usar [CmdletBinding ()] ou conjuntos de parâmetros.
Comandos e cmdlets têm versões.
Se uma função em si tem uma versão, _seja ou não a função resida dentro de um módulo_, é simplesmente um ponto de documentação secundário, mas útil. Criei vários módulos com ferramentas variadas e não relacionadas que não justificam seus próprios módulos individuais. Se meu módulo for MiscStuff 1.1.0002 , isso é ótimo para a parte de distribuição; Eu uso isso. Se houver trinta funções dentro dele e eu quiser notar rapidamente se estou usando Do-Thing 7.9.0 e ser capaz de correlacioná-lo a um item no meu changelog (o que eu faço!), Gostaria de algum método formal para fazendo isso, o que de forma alguma seria exigido por aqueles que não desejam.

@ PowerShell / powershell-Committee revisou isso, acreditamos que a solução adequada para ter controle de versão para funções de script é envolvê-los em um módulo. Também não está claro qual seria o comportamento esperado se a função de script estivesse dentro de um módulo, mas tivesse seu próprio atributo de versão. Então, há uma preocupação com outras partes do PowerShell, PowerShellGet e PSGallery que precisariam ser atualizadas para respeitar esse novo atributo. Se o desejo é poder passar um único arquivo de script em vez de uma pasta (módulo), então seria melhor investir na capacidade de importar um módulo zip / nupkg diretamente e mais fácil transformar um .ps1 em um módulo.

Como um script de script de administrador e não um desenvolvedor, não acho que # 7259 e esta solicitação (# 11667) tenham algo a ver um com o outro.

Como um script de script de administrador, NÃO VOU aprender a usar módulos. Não é relevante para mim. Não me fornece NENHUM VALOR. É uma sobrecarga PARA DESENVOLVEDORES. Os módulos não são iniciantes. (Não apenas para mim, mas para a maioria dos administradores de scripts.)

Para administradores de script e não desenvolvedores - como o comitê sugere que o controle de versão para funções / filtros seja feito?

Não quero ser contrário, mas ... o próprio versionamento é um conceito de desenvolvedor, em geral. Não sei por que você está tentando traçar essa linha aqui, de todos os lugares possíveis. 😕

Porque lancei dezenas de funções e scripts autônomos. Sem módulos. Tenho certeza de que isso foi abordado acima em comentários anteriores meus e de vários outros blogueiros / editores populares.

Não acho que # 7259 e esta solicitação (# 11667) tenham algo a ver um com o outro.

Sim, eu realmente não entendo a conexão para ser honesto.

NÃO VOU aprender a usar módulos.

FWIW você apenas altera a extensão para psm1 e (opcionalmente) executa New-ModuleManifest . Não há muito nisso.

Não é relevante para mim. Não me fornece NENHUM VALOR.

Se você está publicando algo para outras pessoas consumirem, definitivamente agrega valor. A maneira como os escopos funcionam para os módulos torna muito mais difícil entrar no estado de sessão global de alguém e vice-versa. Isso torna sua função significativamente mais resistente a diferenças inesperadas nos ambientes.

Também é muito mais fácil de consumir. Se você liberar uma função como um script, as pessoas precisam fazer a origem do ponto, eles precisam saber onde está, a origem do ponto e, em seguida, usar o comando. Se você o lançar como um módulo, as pessoas podem simplesmente implantá-lo com antecedência e chamá-lo quando quiserem.

como o comitê sugere que o controle de versão para funções / filtros seja feito?

Se o controle de versão foi implementado para funções individuais, você esperaria que sua versão pudesse ser consultada?

Em caso afirmativo, você pode elaborar um pouco sobre qual cenário você esperaria que o usuário o consultasse? Você esperaria que ele funcionasse em qualquer outro sistema, como #requires tags?

Se fossem apenas metadados visíveis na fonte, você poderia apenas colocá-los na seção NOTES da ajuda baseada em comentários.

Com base na conclusão do Comitê do PowerShell, encerro o problema (paro o rastreamento), mas você está livre para continuar a discussão.

Sim, eu uso a seção NOTES hoje e um $ pVersion / $ pName. Eu suspeito que a maioria de nós com a necessidade de fazer isso.

Quando eu estava escrevendo "Eu não vou", estava falando da pessoa genérica, não de mim especificamente (embora eu caia nessa categoria).

e um $ pVersion / $ pName

O que você faz com isso? Você tem um exemplo de uma função solta que publicou? Isso pode ajudar a entender o caso de uso.

Quando eu estava escrevendo "Eu não vou", estava falando da pessoa genérica, não de mim especificamente (embora eu caia nessa categoria).

Sim, definitivamente existem pessoas que se recusam a aprender sobre os módulos. Eu conheci e atualmente conheço muitas pessoas assim (e tem sido chamado de folk alguns anos atrás), nenhum argumento de que existam. Dito isso, a sobreposição entre essas pessoas e aquelas que 1. se preocupam com o controle de versão e 2. têm qualquer desejo de publicar seu trabalho - em minha experiência é quase zero. De forma realista, a maioria das pessoas que marcar as caixas 1 e 2 levará cerca de 10 minutos para pesquisar como envolver um módulo bem rápido antes de publicá-lo. Ou, com mais frequência, eles não se importam com o controle de versão e simplesmente colocam isso em uma parte essencial ou em uma postagem de blog.

e um $ pVersion / $ pName

O que você faz com isso? Você tem um exemplo de uma função solta que publicou? Isso pode ajudar a entender o caso de uso.

Quando eu estava escrevendo "Eu não vou", estava falando da pessoa genérica, não de mim especificamente (embora eu caia nessa categoria).

Sim, definitivamente existem pessoas que se recusam a aprender sobre os módulos. Eu conheci e atualmente conheço muitas pessoas assim (e tem sido chamado de folk alguns anos atrás), nenhum argumento de que existam. Dito isso, a sobreposição entre essas pessoas e aquelas que 1. se preocupam com o controle de versão e 2. têm qualquer desejo de publicar seu trabalho - em minha experiência é _quase_ zero. De forma realista, a maioria das pessoas que marcar as caixas 1 e 2 levará cerca de 10 minutos para pesquisar como envolver um módulo bem rápido antes de publicá-lo. Ou, com mais frequência, eles não se importam com o controle de versão e simplesmente colocam isso em uma parte essencial ou em uma postagem de blog.

Eu sei como usar módulos. Eu os escrevo o tempo todo. Caramba, essas funções estão dentro de módulos a maior parte do tempo, e eu uso versões internas para que eu possa acompanhar o que foi alterado pela última vez em uma função sem ter que puxar para um changelog externo (para a função). Não vejo por que .VERSION em uma função interfere na versão de um módulo. Eu simplesmente não quero.

Eu sei como usar módulos. Eu os escrevo o tempo todo. Caramba, essas funções são _inside_ _modules_ a maior parte do tempo, e eu uso versionamento interno para que eu possa acompanhar o que mudou pela última vez em uma função sem ter que puxar para um changelog externo (para a função). Não vejo por que .VERSION em uma função interfere na versão de um módulo. Eu simplesmente não quero.

Certo, mas o principal é: o que você vai fazer com esses metadados? É apenas algo que você observa na origem da função? Em caso afirmativo, você pode explicar como a seção .NOTES não é adequada para isso?

Além disso, esse problema era para permitir que uma função autônoma declarasse seu número de versão na saída Get-Command . Uma solicitação para incluir um log de alterações completo seria uma implementação bem diferente e provavelmente melhor em seu próprio problema.

isso é fácil de responder. isso significa que tenho que abri-lo em um editor ou realizar algum tipo de pesquisa estranha de string para descobrir a versão instalada em um determinado computador / local determinado no referido computador. isso nem sempre é fácil como esta resposta. :-)

Na verdade, não?

O campo Notas é mostrado na saída Get-Help se você estiver escrevendo como uma ajuda adequada com base em comentários (o que deveria ser feito de qualquer maneira).

function test {
    <#
    .NOTES
    Version: 1.5.0
    #>
    [CmdletBinding()]
    param()
}

Get-Help test -Full

# or
Get-Help test | % alertSet

Resultado:

PS> Get-Help test -Full
SYNTAX
    test [<CommonParameters>]


DESCRIPTION


PARAMETERS
    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer, PipelineVariable, and OutVariable. For more information, see
        about_CommonParameters (https://go.microsoft.com/fwlink/?LinkID=113216).

INPUTS

OUTPUTS

NOTES


        Version: 1.5.1


RELATED LINKS

PS> get-help test | % alertset



    Version: 1.5.1

Assim? Não estou impressionado. Havia outras maneiras mais prolixas de fazer operadores ternários também. E ainda ... uma forma mais compacta foi implementada. Porque (uma parte da) comunidade queria. Eu ainda não sei o que diabos são os operadores de coalescência nula.

Não tenho certeza do que você está procurando, então. Isso claramente permite que você faça o que deseja com relativa facilidade. Não acho que valha a pena adicionar campos extras aqui.

Se você fizer isso, fique à vontade para abrir um PR e conversaremos mais sobre isso. 🤷

Um PR para quê? Não sou um programador C #. Não sou desenvolvedor profissional há mais de 30 anos.

Acho que vários de nós foram muito claros sobre o que buscamos e nossos casos de uso, e viram essas preocupações minimizadas, como você acabou de fazer de novo.

Aqueles de vocês que estão além dos scripts de administração pensam "apenas torná-lo um módulo". A maioria dos criadores de scripts de administração não saberá como e dirão (e eu concordo) que é muito problemático assim que virem os requisitos.

Mas isso é inútil e eu sabia melhor. A conclusão do Comitê PowerShell já foi alcançada. Desculpe, eu comentei.

A conclusão do Comitê PowerShell já foi alcançada.

Quaisquer conclusões de projeto podem ser reconsideradas com base em feedbacks.

Acho que vários de nós foram muito claros sobre o que buscamos e nossos casos de uso, e viram essas preocupações minimizadas, como você acabou de fazer de novo.

Tenho tentado muito descobrir qual é o objetivo real e os casos de uso, e minhas perguntas têm sido quase todas ignoradas. Eu realmente gostaria de entender.

Aqueles de vocês que estão além dos scripts de administração

Cara, eu sou um administrador de sistema. Passei a maior parte da minha carreira pensando que a sintaxe hashtable era "a sintaxe de splatting". A maioria dos meus colegas de trabalho só conhece o básico absoluto do PowerShell (se é que conhece), o mesmo com a maioria das pessoas que ajudo no discord / reddit.

Eu entendo que você tem alguma briga com a equipe de desenvolvimento do PS, mas por favor, não finja que eu não poderia entender sua perspectiva porque eu conheço C # agora. Estou constantemente lutando por essa perspectiva neste repo.

pense "apenas torná-lo um módulo". A maioria dos criadores de scripts de administração não saberá como e dirão (e eu concordo) que é muito problemático assim que virem os requisitos.

Para qualquer um que se deparar com este tópico mais tarde e ficar desestimulado a fazer um módulo, aqui estão os requisitos:

1. Renomeie seu arquivo .ps1 para .psm1
2. Use Import-Module ./file.psm1 vez de . ./file.ps1

É isso, você tem um módulo. Todo o resto são apenas práticas recomendadas com as quais você não precisa se preocupar ainda. Se você quiser criar uma versão, precisará de um manifesto. Aqui estão os requisitos completos para isso:

1. Renomeie seu arquivo .ps1 para .psm1
2. Execute New-ModuleManifest -RootModule ./file.psm1 -Path ./file.psd1 -ModuleVersion 1.0.0
3. Use Import-Module ./file.psd1 vez de . ./file.ps1

Se você estiver enviando uma função avulsa em um ps1 que o consumidor (ou você mesmo) precisaria para criar um ponto fonte, basta colocá-la em um módulo bem rápido que tornará sua vida mais fácil.

Se estiver enviando um script invokable diretamente, você pode usar New-ScriptFileInfo que irá gerar um arquivo de script com um comentário como este:

<#PSScriptInfo

.VERSION 1.0.0

.GUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

.AUTHOR username

.COMPANYNAME

.COPYRIGHT

.TAGS

.LICENSEURI

.PROJECTURI

.ICONURI

.EXTERNALMODULEDEPENDENCIES 

.REQUIREDSCRIPTS

.EXTERNALSCRIPTDEPENDENCIES

.RELEASENOTES


.PRIVATEDATA

#>

<# 
.DESCRIPTION 
     Quick script description here.
#> 
param()

E você pode consultar isso com Test-ScriptFileInfo .