Agregue información sobre cómo le gustaría mejorar el lenguaje de PowerShell para agregar la versión. ¿En el atributo cmdletbinding?

Mi pensamiento era hacer algo como New-ScriptFileInfo que genera un encabezado de comentario 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()

Hágalo PSFunctionInfo y haga que Get-Command lo analice. O de la misma manera que PowerShell puede analizar #requires, haga que analice #version. Donde se vuelve complicado es cuando tiene varias funciones en el mismo archivo ps1, por lo que cualquier cosa que haría como autor de una función debería incluirse en la función. Esto podría ser un bloque de comentarios analizado, una nueva opción cmdletbinding () o quizás un atributo completamente nuevo.

Function Get-Awesomeness {

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

 Param ()

 ...
}

No veo un valor de la función. Podemos publicar en PowerShellGet y distribuir scripts de PowerShell solo como módulos, no podemos hacer esto para archivos. ¿Puede describir un caso de negocio / flujo de trabajo?

Hay muchas personas que crean soluciones PowerShell que nunca se publican en la galería. Se utilizan internamente, por ejemplo, en un entorno empresarial. Y no todo está empaquetado en un módulo. Puedo trabajar en un entorno corporativo y tener un archivo de script independiente con una función. Quiero la capacidad de realizar un seguimiento de la versión para esa función. Si ejecuto Get-Command Get-CompanyFoo, necesito poder ver un número de versión. De hecho, incluso en un módulo, todas las funciones exportadas comparten el mismo número de versión. Me gustaría tener una instalación para rastrear la información de la versión por función. Y por supuesto, sin tener que depender de leer el código fuente. Si un técnico de la mesa de ayuda está usando una de mis funciones, debe poder usar PowerShell para descubrir la versión del comando.

Ciertamente, no todas las funciones necesitan esto, incluso las de un módulo. No tengo ningún problema con una función en un módulo que usa la versión del módulo si no se detecta una versión específica del comando.

@jdhitsolutions ¡Gracias!

Veo dos componentes en su escenario: (1) un sistema de seguimiento de versiones, (2) un sistema de distribución.
El primero podría ser GIT (¿otros?).
No está claro cómo distribuye los archivos de secuencia de comandos.

(Estoy tratando de entender dónde está el lugar correcto para el atributo solicitado).

Dejo las funciones en los clientes de forma regular, que están vigentes desde la última vez que las usé en ese cliente en particular. Me viene a la mente uno que utilicé en un cliente hoy: getWUlog. Sabe cómo conectarse a un sistema remoto usando WinRM y psexec (comprueba si hay 139 o 5985 abiertos) y recupera el registro de WindowsUpdate de esa computadora, lo recupera en la computadora local y abre el bloc de notas.

Otro es getFrameworkVersion. Hace exactamente eso: busca encontrar la versión de .NET Framework instalada en una computadora determinada, usando CIM o el servicio de registro remoto (nuevamente, verifica los puertos para averiguar qué hacer), los informa e informa qué versiones están bloqueadas, Si alguna.

Estas son funciones independientes. No forma parte de un módulo. Pero han pasado por actualizaciones periódicas durante los últimos años.

Sería genial adjuntar una versión a cada uno de ellos. En este momento, solo tengo una "fecha de última modificación" en la parte superior de la fuente. No es tan útil ...

En mi opinión, la distribución es irrelevante para esta discusión. Y sí, git juega un papel, pero no es el problema. Si estoy en PowerShell y estoy usando una función independiente. Cuando ejecuto Get-Command Get-Foo, quiero ver el número de versión de la función. Es tan simple como eso. No importa cómo se distribuyó la función. Dame una forma de inyectar metadatos en la función.

Y para ser absolutamente claro, no quiero obligar a un usuario, ni siquiera a mí mismo, a rastrear la fuente y buscar comentarios o notas.

Definitivamente escribo / uso algunas funciones independientes, pero la mayoría están en módulos. Y la mayoría de ellas son herramientas de desperdicio aleatorio que se pueden usar como funciones independientes. Siempre pongo versiones semánticas y registros de cambios en .NOTES dentro del bloque de comentarios, y un [version]$Version en el bloque de inicio, porque quiero hacer un seguimiento de los cambios que hice en una función en particular, no solo al módulo (que incremento cuando hago cambios en las funciones internas). Tener algo como [version()] o [cmdletbinding(Version='01.00.0000')] sería espectacular; Me gusta más que .VERSION porque sé que mucha gente pone múltiples funciones en un archivo psm1 (aunque yo no).
También uso git, por cierto, pero no me comprometo cada vez que hago un cambio en una función individual; Los agrupo y me comprometo cuando cambio el módulo, normalmente con la versión del módulo como mensaje de confirmación. Sí, sí, lo sé, soy raro.

Si el script se encuentra en $env:PATH , aparece para Get-Command. Por lo tanto, parece razonable asignar los metadatos ScriptFileInfo existentes a los miembros ExternalScriptInfo que incluyen la versión.

Tenga cuidado con esa suposición Steve. Podría tener un solo archivo ps1 con múltiples funciones. No quiero confiar en que Get-Command pueda encontrar el archivo de secuencia de comandos. Diablos, es posible que desee definir una función versionada en un script de perfil de PowerShell.

Definitivamente tengo funciones versionadas en mi script de perfil.

Ya tenemos el tipo System.Management.Automation.FunctionInfo que tiene una propiedad Version. Necesitamos una forma para que cuando se cargue la función, la propiedad de la versión se complete a partir de los metadatos de la función.

¡Gracias a todos por sus excelentes comentarios! Todavía tengo algunas preguntas. ¿Qué comportamiento espera si PowerShell encuentra algunas funciones con el mismo nombre? ¿Ejecutar la función con una versión superior? ¿Deberíamos tener en cuenta los alcances (se carga en la función anterior del alcance actual, deberíamos llamar a más funciones nuevas del alcance global)? ¿O queremos tener solo un atributo informativo?

No se trata de ejecutar o distribuir funciones. Todo lo que me gustaría es un mecanismo para proporcionar una forma de rastrear y descubrir la información de la versión para que si ejecuto Get-Command, o quizás un nuevo comando como Get-Function, pueda ver algunos metadatos sobre la función. Tengo algunas ideas que podría intentar crear un prototipo a través de scripts de PowerShell.

¡Gracias a todos por sus excelentes comentarios! Todavía tengo algunas preguntas. ¿Qué comportamiento espera si PowerShell encuentra algunas funciones con el mismo nombre? ¿Ejecutar la función con una versión superior? ¿Deberíamos tener en cuenta los alcances (se carga en la función anterior del alcance actual, deberíamos llamar a más funciones nuevas del alcance global)? ¿O queremos tener solo un atributo informativo?

No creo que nadie haya sugerido ningún cambio en la forma en que PS ejecuta las funciones. Solo queremos ponerles una versión. Informativo y una forma de interrogarlo.

¡Gracias! Siguiente pregunta que tengo. Un archivo con algunas funciones podría tener un atributo de versión común para todas las funciones del archivo. ¿Deberíamos considerar esto?

Tengo algunas ideas que podría intentar crear un prototipo a través de scripts de PowerShell.

Podrías compartir las ideas en esencia.

Ese es mi plan.

¿Debería ser la versión clásica o SymVer 2.0?

Estoy cada vez más convencido de que el control de versiones de funciones es algo bueno.

Para responder a la última pregunta de @iSazonov : si vamos a tenerlo, ¿por qué NO usar SymVer?

Y con respecto a un archivo de funciones, yo diría que el atributo es por función sin atributos por archivo. Al igual que funciona el CMDLETBinding de hoy.

El prototipo se extrae en ## 11686

Puedes descargar un artefacto del PR y jugar con un nuevo atributo.

Dulce.

Pensando en ello, ¿por qué no ampliar PSVersionAttribute para incluir la versión del script? Si versionamos módulos y funciones (¡con suerte ahora!), ¿Por qué no scripts?

El PSVersionAttribute también podría servir como un valor predeterminado para las funciones definidas en el script.

Y antes de que alguien más pregunte ... ¿Se puede versionar la ejecución de la función?

Podríamos cargar varias versiones de una función, ejecutar la última de forma predeterminada, pero tener un parámetro común -PSFunctionVersion que dice qué versión específica ejecutar.
Sin duda, hay más alternativas, pero ¿deberíamos proporcionar ejecución de funciones versionadas?

Si es un atributo, siempre puede reutilizarlo, al igual que [CmdletBinding()] se puede aplicar tanto a funciones como a scripts, siempre puede usar [PSVersion()] tanto para funciones como para scripts. Este parece un enfoque interesante. 🙂

No preveo mucho uso de este tipo de cosas en módulos, donde ya tenemos código versionado en su mayor parte, pero para scripts y funciones independientes esto podría ser muy interesante 🙂

No se trata de ejecutar o distribuir funciones. Todo lo que me gustaría es un mecanismo para proporcionar una forma de rastrear y descubrir la información de la versión para que si ejecuto Get-Command, o quizás un nuevo comando como Get-Function, pueda ver algunos metadatos sobre la función. Tengo algunas ideas que podría intentar crear un prototipo a través de scripts de PowerShell.

Si vamos a agregar el control de versiones de funciones, ¿por qué limitarlo a la documentación puramente? Si puedo especificar y consultar versiones de funciones, ¿no sería sensato permitir la ejecución en función del número de versión?

O una forma de cargar múltiples versiones de una función y poder elegir la que ejecutar, o permitir al usuario elegir entre diferentes versiones para cargar en la lista de funciones que vemos con gcm y luego ejecutar esa.

Así que aquí hay una prueba de concepto que elaboré en función de los comandos ScriptFileInfo:
https://gist.github.com/jdhitsolutions/65070cd51b5cfb572bc6375f67bcbc3d

Lo que realmente estoy tratando de modelar o prototipar es la experiencia. Prefiero tener los datos expuestos con Get-Command, porque ya existe un tipo apropiado.

Y obteniendo una mezcla de archivos.

Si una función pertenece a un módulo, no me voy a molestar con el control de versiones de comandos. Eso debería ser manejado por el módulo.

Esencia

Una prueba de concepto para agregar y obtener información de metadatos de PowerShell

Una prueba de concepto para agregar y obtener información de metadatos de PowerShell: PSFunctionInfo.format.ps1xml

¡Buen Jeff!

Entonces, ¿cómo manejamos múltiples versiones de la misma función?
¿Cómo se carga explícitamente una versión de función específica?
¿Cómo se ejecuta explícitamente una versión específica de una función?

@doctordns Usted es responsable de averiguar qué ejecutar y tratar con varias versiones. Mi código de prototipo es simplemente enumerar elementos en la función: Psdrive y mostrar información de metadatos. Hasta donde yo sé, no se pueden tener funciones duplicadas en psdrive. Mi objetivo ha sido, si tengo una función independiente cargada, quiero poder recuperar la versión y posiblemente otra información de metadatos.

Si bien creo que sería maravilloso si PowerShell admitiera los metadatos _embedded_ PSScriptInfo para _scripts_ ... por favor, no haga esto en el nivel _function_.

Las versiones solo son útiles si puedes hacer algo al respecto

Actualmente, PowerShell _ informa_ la versión de los comandos, pero la versión real proviene del _módulo_. Tener versiones separadas para cada función no sería útil, simplemente sería confuso. Independientemente de cómo distribuya su código, no está distribuyendo "trozos" de subarchivo y el usuario no puede cargar una función individual (ni nada excepto un archivo completo), por lo que no tiene sentido intentar versionarlos.

Creo que necesitamos versiones para módulos y scripts. Las funciones deben heredar su versión del _módulo_ que las contiene. Los scripts necesitan su propia versión.

Para el registro:

Si tiene un archivo .ps1 que tiene múltiples funciones, necesita cambiar la extensión. Si no lo hace, los usuarios no tienen forma de descubrir esas funciones de todos modos, por lo que el control de versiones no importará. Debemos desalentar activamente a cualquiera que intente distribuir _funciones_ en cualquier cosa que no sea un módulo. 🤨

@Jaykul Estoy de acuerdo en que si una función se envía con un módulo, que debería ser el objetivo, la versión del módulo es importante. Sin embargo, hay muchos usuarios que utilizan funciones independientes. Quizás se cargue en un perfil o se obtenga en puntos para satisfacer una necesidad específica. No todo lo que hago debe cargarse e integrarse en un módulo. Son estas funciones que no son módulos las que quiero administrar. Quiero una forma de capturar la versión y otra información de metadatos tal como lo hacemos con los comandos cargados desde un módulo. Quizás la respuesta sea un nuevo comando como mi prototipo.

@Jaykul Creo que varios de nosotros ya hemos dicho que, de hecho, sería útil para nosotros y que, de hecho, estamos distribuyendo funciones únicas.

En mi opinión, no todo necesita un módulo.

Es posible que la función propuesta no le resulte útil. Y eso está bien. Pero lo es para otros de nosotros.

Me gusta la idea del control de versiones de funciones. Pero si hacemos una solución, debería ser más que una pequeña documentación que podría hacer en los comentarios. Sin la capacidad de controlar la carga de diferentes versiones, etc., esta es una característica de la que podemos prescindir por ahora.

Sugiero que dejemos esta idea para la versión 7.0. Estamos DEMASIADO cerca de RTM para incorporar nuevas funciones a la mezcla. ¡Tengo malos recuerdos de NT 5 días! Si podemos retroceder esto a 7.1, ENTONCES tengamos una conversación más completa sobre cómo implementarlo por completo. Intentar simplemente sacar esto en el último minuto es una forma segura de causar decepción.

Si esto sucede, es una adición 7.1. Creo que el problema de cargar la versión correcta depende del usuario. Nuevamente, todo lo que pido es una forma de recuperar la información de la versión de una función independiente cargada sin tener que buscar en la fuente.

Estoy de acuerdo con 7.1.

Al mismo tiempo, "conozco a los usuarios, y apuesto una botella o tres a que una solución de documentación solo generará solicitudes para funciones de tiempo de ejecución basadas en la versión". Me gustaría que consideráramos una solución completa, elegante y bien diseñada. .

Ya tenemos una solución para funciones independientes: la última cargada gana. :-)

Sin la capacidad de controlar la carga de diferentes versiones, etc., esta es una característica de la que podemos prescindir por ahora.

Esto nos obligaría a comprobar la versión de la función cada vez que se llama. Esto es completamente inaceptable por motivos de rendimiento. El módulo es el mejor compromiso: la verificación de la versión se realiza una vez al cargar el módulo.

@ SteveL-MSFT Creo que está listo para la conclusión del Comité PowerShell. Prototipo # 11686.

Parece que todos están de acuerdo en que es útil tener una versión para scripts en el motor.
La versión para funciones está en duda porque existe la concepción del módulo.

La limitación común es que solo podemos ver las versiones de los scripts y funciones cargados y no podemos hacer lo que hace el módulo de importación: cargar la versión necesaria pero get-module tampoco tiene parámetros de versión explícitos.

No pienses demasiado en esto ni lo hagas más complicado de lo necesario. Las funciones enviadas con los módulos pertenecen al módulo. Punto final. Esa debería ser la mejor práctica recomendada. Sin embargo, no todas las funciones que podrían usarse en producción se implementan con un módulo. En realidad, no me importa cómo se implementa. Todo lo que digo es que quiero una forma de ver una función cargada en la Función: PSDrive y poder ver un número de versión, y quizás alguna otra información de metadatos. No quiero obligarme a mí ni a un usuario final a rastrear el código fuente o la carpeta para descubrir información de la versión.

Tenía la esperanza de que Get-Command fuera la herramienta para recopilar esta información, pero tal vez esto deba dividirse en algo completamente separado para la administración de funciones independientes.

Y tal vez la respuesta sea que es mejor dejar que la comunidad lo resuelva. En cuyo caso, creo que tengo un buen comienzo con una solución.

La verdad honesta aquí es que las funciones de abastecimiento de puntos no son el camino correcto a seguir, y no deberían haber sido recomendadas todos esos años atrás, cuando el sistema de módulos llegó en v2. La única vez que fue remotamente sensato para su uso fue en v1.

Como todos sabemos ahora, todas las funciones deben colocarse de manera realista dentro de un módulo, incluso aquellas que está cargando como parte de su perfil (que debe cargar el módulo que contiene estas funciones) o usar como parte de un script más grande para facilitar el mantenimiento. o incluso esas funciones singulares que necesita utilizar en scripts xyz.

Solo puedo ver que este cambio agregaría más confusión a los que vienen al lenguaje que el beneficio al agregar el atributo [Version] sugerido a las definiciones de funciones y muchos piensan que se les requeriría configurar las versiones de Módulo y Función cuando lo estén haciendo las cosas correctamente y construyendo módulos de código reutilizable.

Sí, esto significa que debe tener un psd1 y un psm1, pero 2 archivos para una capacidad de descubrimiento y mantenimiento adecuados no es una gran tarea para administrar realmente

Como puede decir, personalmente no estoy de

Sí, esto significa que debe tener un psd1 y un psm1, pero 2 archivos para una capacidad de descubrimiento y mantenimiento adecuados no es una gran tarea para administrar realmente

Sí, es una gran pregunta. Tratar de convertir a los scripters de administración en desarrolladores aumenta significativamente la barrera de entrada.

Decir "oh, tienes que copiar esto aquí y copiarlo allí y luego importarlo" es mucho más complicado y mucho más propenso a errores que decir "copia y pega esto en un archivo llamado run.ps1 y luego escribe, \ ejecutar .ps1 ".

Este es un cambio menor y puede beneficiar a los scripters casuales / de administración mucho más que a los operadores ternarios o de fusión nula (que todavía no entiendo) o muchos otros cambios recientes que se realizaron para aquellos de ustedes que son desarrolladores. Como se dijo al respecto, puedo decir sobre las versiones de funciones: si no te gusta, no lo uses.

@ SteveL-MSFT Creo que el comité de PowerShell podría buscar la solicitud para admitir versiones para scripts y funciones independientes. El prototipo está en # 11686.

La verdad honesta aquí es que las funciones de abastecimiento de puntos no son el camino correcto a seguir,

Pero la gente lo hace, y de todos modos no es el único caso de uso para esta solicitud.

y no debería haber sido recomendado todos esos años atrás cuando el sistema de módulos vino en v2. La única vez que fue remotamente sensato para su uso fue en v1.

Como todos sabemos ahora, todas las funciones deben colocarse de manera realista dentro de un módulo, incluso aquellas que está cargando como parte de su perfil (que debe cargar el módulo que contiene estas funciones) o usar como parte de un script más grande para facilitar el mantenimiento. o incluso esas funciones singulares que necesita utilizar en scripts xyz.

Solo puedo ver que este cambio agregaría más confusión a los que vienen al lenguaje que el beneficio al agregar el atributo [Version] sugerido a las definiciones de funciones y muchos piensan que se les requeriría configurar las versiones de Módulo y Función cuando lo estén haciendo las cosas correctamente y construyendo módulos de código reutilizable.

Sí, esto significa que debe tener un psd1 y un psm1, pero 2 archivos para una capacidad de descubrimiento y mantenimiento adecuados no es una gran tarea para administrar realmente

Sí, pero esto no es relevante. Nadie está argumentando que no deberíamos versionar módulos. ;-)

Como puede decir, yo personalmente _no estoy de acuerdo_ con este cambio y creo que hay mejores cosas en las que centrarse.

No se le pedirá que lo use. En realidad, tampoco está obligado a usar [CmdletBinding ()] o conjuntos de parámetros.
Los comandos y cmdlets tienen versiones.
Si una función en sí tiene una versión, si dicha función reside o no dentro de un módulo, es simplemente un punto de documentación menor, pero útil. He creado numerosos módulos con herramientas variadas y no relacionadas que no justifican sus propios módulos individuales. Si mi módulo es MiscStuff 1.1.0002 , eso es genial para la parte de distribución; Yo uso eso. Si hay treinta funciones dentro de él y quiero notar rápidamente si estoy usando Do-Thing 7.9.0 y poder correlacionarlo con un elemento en mi registro de cambios (¡lo cual hago!), Me gustaría algún método formal para haciendo esto, que de ninguna manera sería requerido por aquellos que no lo deseen.

@ PowerShell / powershell-Committee revisó esto, creemos que la solución adecuada para tener versiones para funciones de script es envolverlas en un módulo. Tampoco está claro cuál sería el comportamiento esperado si la función del script está dentro de un módulo, pero tiene su propio atributo de versión. Luego existe la preocupación por otras partes de PowerShell, PowerShellGet y PSGallery que deberían actualizarse para respetar este nuevo atributo. Si el deseo es poder pasar un solo archivo de script frente a una carpeta (módulo), entonces sería mejor invertir en la capacidad de importar un módulo zip / nupkg directamente y más fácil convertir un .ps1 en un módulo.

Como scripter de administrador y no como desarrollador, no creo que el # 7259 y esta solicitud (# 11667) tengan algo que ver entre sí.

Como scripter de administrador , NO aprenderé a usar módulos. No es relevante para mí. No me proporciona ningún valor. Es una sobrecarga PARA LOS DESARROLLADORES. Los módulos no son de arranque. (No solo para mí, sino para la mayoría de los administradores de secuencias de comandos).

Para scripters administradores y no desarrolladores, ¿cómo sugiere el comité que se realice el control de versiones para funciones / filtros?

No quiero ser contrario, pero ... el control de versiones en sí mismo es un concepto de desarrollador, en general. No estoy seguro de por qué está tratando de trazar esta línea aquí, de todos los lugares posibles. 😕

Porque he lanzado docenas de funciones y scripts independientes. Sin módulos. Estoy bastante seguro de que esto se cubrió anteriormente en comentarios anteriores míos y de varios otros bloggers / editores populares.

No creo que el # 7259 y esta solicitud (# 11667) tengan algo que ver entre sí.

Sí, tampoco entiendo la conexión para ser honesto.

NO aprenderé a usar módulos.

FWIW, simplemente cambie la extensión a psm1 y (opcionalmente) ejecute New-ModuleManifest . No hay mucho que hacer.

No es relevante para mí. No me proporciona ningún valor.

Si está publicando algo para que otros lo consuman, definitivamente proporciona valor. La forma en que funcionan los ámbitos para los módulos hace que sea mucho más difícil pisar el estado de sesión global de alguien y viceversa. Eso hace que su función sea significativamente más resistente a diferencias inesperadas en los entornos.

También es mucho más fácil de consumir. Si libera una función como un script, la gente necesita puntear la fuente, necesitan saber dónde está, la fuente punteada y luego usar el comando. Si lo publica como un módulo, la gente puede implementarlo con anticipación y llamarlo cuando lo deseen.

¿Cómo sugiere el comité que se hagan versiones para funciones / filtros?

Si se implementara el control de versiones para funciones individuales, ¿esperaría que se pudiera consultar su versión?

En caso afirmativo, ¿puede explicar un poco en qué escenario esperaría que el usuario lo consultara? ¿Esperaría que se reproduzca en otros sistemas como las etiquetas #requires ?

Si solo fueran metadatos visibles en la fuente, entonces podría ponerlos en la sección NOTES de la ayuda basada en comentarios.

Según la conclusión del Comité de PowerShell, cierro el problema (detener el seguimiento), pero puede continuar con la discusión.

Sí, hoy uso la sección NOTAS y $ pVersion / $ pName. Sospecho que la mayoría de nosotros con la necesidad, haz eso.

Cuando estaba escribiendo "No lo haré", estaba hablando de la persona genérica, no de mí específicamente (aunque pertenezco a esa categoría).

y un $ pVersion / $ pName

¿Qué haces con esos? ¿Tiene un ejemplo de una función suelta que haya publicado? Eso puede ayudar a comprender el caso de uso.

Cuando estaba escribiendo "No lo haré", estaba hablando de la persona genérica, no de mí específicamente (aunque pertenezco a esa categoría).

Sí, definitivamente hay personas que se niegan a aprender sobre módulos. He conocido y conozco a mucha gente así (y me han dicho gente hace unos años), no hay argumentos de que existan. Dicho esto, la superposición entre esas personas y las que 1. se preocupan por el control de versiones y 2. tienen algún deseo de publicar su trabajo, en mi experiencia es casi nula. De manera realista, la mayoría de las personas que marcan las casillas 1 y 2 se tomarán los ~ 10 minutos para buscar en Google cómo envolver un módulo muy rápido antes de publicarlo. O más a menudo, no les importa el control de versiones y simplemente lo incluirán en una esencia o en una publicación de blog.

y un $ pVersion / $ pName

¿Qué haces con esos? ¿Tiene un ejemplo de una función suelta que haya publicado? Eso puede ayudar a comprender el caso de uso.

Cuando estaba escribiendo "No lo haré", estaba hablando de la persona genérica, no de mí específicamente (aunque pertenezco a esa categoría).

Sí, definitivamente hay personas que se niegan a aprender sobre módulos. He conocido y conozco a mucha gente así (y me han dicho gente hace unos años), no hay argumentos de que existan. Dicho esto, la superposición entre esas personas y las que 1. se preocupan por el control de versiones y 2. tienen algún deseo de publicar su trabajo; en mi experiencia, es casi nula. De manera realista, la mayoría de las personas que marcan las casillas 1 y 2 se tomarán los ~ 10 minutos para buscar en Google cómo envolver un módulo muy rápido antes de publicarlo. O más a menudo, no les importa el control de versiones y simplemente lo incluirán en una esencia o en una publicación de blog.

Sé cómo usar módulos. Los escribo todo el tiempo. Diablos, estas funciones están dentro de los módulos la mayor parte del tiempo, y yo uso versiones internas para poder realizar un seguimiento de lo que cambió por última vez en una función sin tener que sacar a un registro de cambios externo (a la función). No veo por qué .VERSION en una función interferiría con la versión de un módulo. Yo simplemente no lo hago.

Sé cómo usar módulos. Los escribo todo el tiempo. Demonios, estas funciones son _inside_ _modules_ la mayor parte del tiempo, y uso versiones internas para poder realizar un seguimiento de lo que cambió por última vez en una función sin tener que sacar a un registro de cambios externo (a la función). No veo por qué .VERSION en una función interferiría con la versión de un módulo. Yo simplemente no lo hago.

Bien, pero lo principal es: ¿qué vas a hacer con esos metadatos? ¿Es solo algo que miras en la fuente de la función? Si es así, ¿puede explicar por qué la sección .NOTES no es adecuada para eso?

Además, este problema era para permitir que una función independiente declarara su número de versión en la salida Get-Command . Una solicitud para incluir un registro de cambios completo sería una implementación bastante diferente y probablemente estaría mejor en su propio problema.

eso es fácil de responder. eso significa que tengo que abrirlo en un editor o realizar algún tipo de búsqueda de cadena incómoda para encontrar la versión instalada en una computadora determinada / ubicación dada en dicha computadora. eso no siempre es tan fácil como esta respuesta. :-)

¿Realmente no?

El campo Notas se muestra en la salida de Get-Help si lo está escribiendo como ayuda adecuada basada en comentarios (que debería ser de todos modos).

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

¿Entonces? No me impresiona. También había otras formas más detalladas de hacer operadores ternarios. Y sin embargo ... se implementó una forma más compacta. Porque (una parte de) la comunidad lo quería. Todavía no sé qué diablos son los operadores de fusión nula.

Entonces no estoy seguro de lo que buscas. Eso claramente te permite hacer lo que buscas con relativa facilidad. No veo que valga la pena agregar campos adicionales allí.

Si lo hace, no dude en abrir un PR y hablaremos más al respecto. 🤷

¿Un PR para qué? No soy un codificador de C #. No soy desarrollador profesional desde hace más de 30 años.

Creo que varios de nosotros tuvimos muy claro lo que buscamos y nuestros casos de uso, y vimos esas preocupaciones minimizadas, como lo hizo nuevamente.

Aquellos de ustedes que están más allá de las secuencias de comandos de administración piensan "simplemente conviértalo en un módulo". La mayoría de los scripters de administración no sabrán cómo y dirán (y yo estaré de acuerdo) que es demasiado problema una vez que vean los requisitos.

Pero esto no tiene sentido y lo sabía mejor. Ya se llegó a la conclusión del Comité PowerShell. Lo siento, comenté.

Ya se llegó a la conclusión del Comité PowerShell.

Cualquier conclusión del diseño se puede reconsiderar en función de los comentarios.

Creo que varios de nosotros tuvimos muy claro lo que buscamos y nuestros casos de uso, y vimos esas preocupaciones minimizadas, como lo hizo nuevamente.

Me he esforzado mucho por llegar al fondo de cuál es el objetivo real y los casos de uso y mis preguntas han sido ignoradas en su mayoría. Realmente me gustaría entender.

Aquellos de ustedes que están más allá de las secuencias de comandos de administración

Hombre, soy un administrador de sistemas. La mayor parte de mi carrera la dediqué a pensar que la sintaxis de la tabla hash era "la sintaxis de splatting". La mayoría de mis compañeros de trabajo solo conocen los conceptos básicos absolutos de PowerShell (si es que los conocen), lo mismo que la mayoría de las personas a las que ayudo en discord / reddit.

Entiendo que tienes un problema con el equipo de desarrollo de PS, pero no finjas que no puedo entender tu perspectiva porque ahora conozco C #. Lucho constantemente por esa perspectiva en este repositorio.

piense "simplemente conviértalo en un módulo". La mayoría de los scripters de administración no sabrán cómo y dirán (y yo estaré de acuerdo) que es demasiado problema una vez que vean los requisitos.

Para cualquiera que se encuentre con este hilo más tarde y se desanime de hacer un módulo, estos son los requisitos:

1. Cambie el nombre de su archivo .ps1 a .psm1
2. Utilice Import-Module ./file.psm1 lugar de . ./file.ps1

Eso es todo, tienes un módulo. Todo lo demás son solo las mejores prácticas de las que no debe preocuparse todavía. Si desea versionarlo, necesita un manifiesto, estos son los requisitos completos para eso:

1. Cambie el nombre de su archivo .ps1 a .psm1
2. Ejecutar New-ModuleManifest -RootModule ./file.psm1 -Path ./file.psd1 -ModuleVersion 1.0.0
3. Utilice Import-Module ./file.psd1 lugar de . ./file.ps1

Si está enviando una función suelta en una ps1 que el consumidor (o usted mismo) necesitaría agregar a la fuente, simplemente colóquela en un módulo muy rápido que le hará la vida más fácil.

Si está enviando una secuencia de comandos directamente invocable, puede usar New-ScriptFileInfo que generará un archivo de secuencia de comandos con un comentario 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()

Y puede consultar eso con Test-ScriptFileInfo .