Добавьте информацию о том, как вы хотите улучшить язык PowerShell, чтобы добавить версию. В атрибуте cmdletbinding?

Я думал сделать что-то вроде New-ScriptFileInfo, который генерирует такой заголовок комментария:

<#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()

Сделайте это PSFunctionInfo и попросите Get-Command проанализировать его. Или так же, как PowerShell может анализировать #requires, пусть он анализирует #version. Сложность возникает, когда у вас есть несколько функций в одном файле ps1, поэтому все, что я делал бы как автор функции, нужно было бы заключить в функцию. Это может быть проанализированный блок комментария, новая опция cmdletbinding () или, возможно, совершенно новый атрибут.

Function Get-Awesomeness {

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

 Param ()

 ...
}

Я не вижу ценности в этой функции. Мы можем публиковать на PowerShellGet и распространять сценарии PowerShell только как модули, мы не можем делать это для файлов. Можете ли вы описать бизнес-кейс / рабочий процесс?

Многие люди создают решения PowerShell, которые никогда не публикуются в галерее. Они используются внутри компании, скажем, в корпоративной среде. И не все упаковано в модуль. Я могу работать в корпоративной среде и иметь отдельный файл сценария с функцией. Мне нужна возможность отслеживать версию этой функции. Если я запускаю Get-Command Get-CompanyFoo, мне нужно видеть номер версии. В этом отношении даже в модуле все экспортируемые функции имеют один и тот же номер версии. Я хотел бы иметь возможность отслеживать информацию о версии для каждой функции. И, конечно же, без необходимости полагаться на чтение исходного кода. Если технический специалист службы поддержки использует одну из моих функций, он должен иметь возможность использовать PowerShell для определения версии команды.

Конечно, это нужно не каждой функции, даже входящей в модуль. У меня нет проблем с функцией в модуле, использующей версию модуля, если не обнаружена версия для конкретной команды.

@jdhitsolutions Спасибо!

Я вижу в вашем сценарии два компонента - (1) систему отслеживания версий, (2) систему распространения.
Первым может быть GIT (другие?).
Непонятно, как вы распространяете файлы сценариев.

(Я пытаюсь понять, где находится подходящее место для запрошенного атрибута.)

Я регулярно оставляю функции у клиентов, которые актуальны на момент последнего использования их на этом конкретном клиенте. На ум приходит тот, который я использовал сегодня у клиента - getWUlog. Он знает, как подключиться к удаленной системе, используя как WinRM, так и psexec (он проверяет, открыты ли 139 или 5985), и извлекает журнал WindowsUpdate с этого компьютера, извлекает его на локальный компьютер и открывает блокнот.

Другой - getFrameworkVersion. Делает именно это - ищет версию .NET Framework, установленную на данном компьютере, используя либо CIM, либо службу удаленного реестра (опять же - проверяет порты, чтобы выяснить, что делать), сообщает о них и сообщает о том, какие версии заблокированы, если есть.

Это автономные функции. Не является частью модуля. Но за последние несколько лет они регулярно обновлялись.

Было бы здорово к каждому из них прикрепить версию. Прямо сейчас у меня есть только «дата последнего изменения» вверху источника. Не так полезно ...

Я считаю, что распределение не имеет отношения к этому обсуждению. И да, git играет роль, но не проблема. Если я использую PowerShell и использую отдельную функцию. Когда я запускаю Get-Command Get-Foo, я хочу увидеть номер версии функции. Это так просто. Неважно, как распределялась функция. Дайте мне возможность добавить метаданные в функцию.

И чтобы быть абсолютно ясным, я не хочу заставлять пользователя или даже себя отслеживать источник и искать комментарии или заметки.

Я определенно пишу / использую некоторые автономные функции, но большинство из них находится в модулях. И большинство из них - это случайные беспорядочные инструменты, которые можно использовать как автономные функции. Я всегда помещаю семантические версии и журналы изменений в .NOTES в блоке комментариев и [version]$Version в начальный блок, потому что я хочу отслеживать, какие изменения я внес в конкретную функцию, а не только в модуль (который я увеличиваю, когда вношу изменения во внутренние функции). Было бы здорово иметь что-то вроде [version()] или [cmdletbinding(Version='01.00.0000')] ; Мне он нравится больше, чем .VERSION, потому что я знаю, что многие люди помещают несколько функций в файл psm1 (хотя я этого не делаю).
Я также использую git, кстати, но я не фиксирую каждый раз, когда вношу изменения в отдельную функцию; Я собираю их и фиксирую, когда меняю модуль, обычно с версией модуля в сообщении о фиксации. Да, да, я знаю, я странный.

Если сценарий находится в $env:PATH , он отображается для Get-Command. Поэтому кажется разумным сопоставить существующие метаданные ScriptFileInfo с членами ExternalScriptInfo, которые включают версию.

Будьте осторожны с этим предположением, Стив. У меня может быть один файл ps1 с несколькими функциями. Я не хочу верить, что Get-Command может найти файл сценария. Черт возьми, я мог бы захотеть определить функцию с контролем версий в скрипте профиля PowerShell.

Определенно есть версионные функции в моем скрипте профиля.

У нас уже есть тип System.Management.Automation.FunctionInfo, у которого есть свойство Version. Нам нужен способ, чтобы при загрузке функции свойство версии заполнялось из метаданных функции.

Спасибо всем за отличный отзыв! У меня остались вопросы. Какого поведения вы ожидаете, если PowerShell обнаружит несколько функций с таким же именем? Запустить функцию с более поздней версией? Должны ли мы принимать во внимание области видимости (вы загружаете старую функцию в текущую область видимости - следует ли вызывать новые функции из глобальной области видимости)? Или мы хотим иметь только информационный атрибут?

Речь не идет о запуске или распределении функций. Все, что мне нужно, - это механизм, позволяющий отслеживать и обнаруживать информацию о версии, чтобы при запуске Get-Command или, возможно, новой команды, такой как Get-Function, я мог видеть некоторые метаданные об этой функции. У меня есть несколько идей, которые я мог бы попробовать создать с помощью сценариев PowerShell.

Спасибо всем за отличный отзыв! У меня остались вопросы. Какого поведения вы ожидаете, если PowerShell обнаружит несколько функций с таким же именем? Запустить функцию с более поздней версией? Должны ли мы принимать во внимание области видимости (вы загружаете старую функцию в текущую область видимости - следует ли вызывать новые функции из глобальной области видимости)? Или мы хотим иметь только информационный атрибут?

Я не думаю, что кто-то предлагал какие-либо изменения в способе выполнения функций PS. Мы просто хотим поставить им версию. Информационные и способ допроса такие же.

Спасибо! У меня следующий вопрос. Файл с некоторыми функциями может иметь атрибут версии, общий для всех функций в файле. Следует ли нам это учитывать?

У меня есть несколько идей, которые я мог бы попробовать создать с помощью сценариев PowerShell.

Вы могли бы поделиться своими идеями в сущности.

Это мой план.

Классическая версия или SymVer 2.0?

Я все больше убеждаюсь, что управление версиями функций - это хорошо.

Чтобы ответить на последний вопрос @iSazonov - если он у нас есть, почему НЕ использовать SymVer?

Что касается файла функций - я бы сказал, что атрибут предназначен для каждой функции без атрибутов для каждого файла. Подобно сегодняшнему CMDLETBinding.

Прототип вытянут в ## 11686

Вы можете скачать артефакт из ПР и поиграться с новым атрибутом.

Сладкий.

Подумайте об этом - почему бы не расширить атрибут PSVersionAttribute, включив в него версию скрипта. Если мы версируем модули и (надеюсь, сейчас!) Функции, почему бы не сценарии?

Атрибут PSVersionAttribute также может служить значением по умолчанию для функций, определенных в скрипте.

И прежде чем кто-нибудь спросит ... Можно ли управлять версиями выполнения функций?

Мы могли бы загрузить несколько версий функции, выполнить последнюю по умолчанию, но иметь общий параметр -PSFunctionVersion, указывающий, какую конкретную версию следует запускать.
Без сомнения, есть и другие альтернативы - но должны ли мы обеспечивать версионное выполнение функций?

Если это атрибут, вы всегда можете просто использовать его повторно, подобно тому, как [CmdletBinding()] можно применить как к функциям, так и к сценариям, вы всегда можете просто использовать [PSVersion()] как для функций, так и для сценариев. Похоже, это интересный подход. 🙂

Я не предвижу большого использования такого рода вещей в модулях, где у нас по большей части уже есть версионный код, но для автономных скриптов и функций это действительно может быть очень интересно 🙂

Речь не идет о запуске или распределении функций. Все, что мне нужно, - это механизм, позволяющий отслеживать и обнаруживать информацию о версии, чтобы при запуске Get-Command или, возможно, новой команды, такой как Get-Function, я мог видеть некоторые метаданные об этой функции. У меня есть несколько идей, которые я мог бы попробовать создать с помощью сценариев PowerShell.

Если нам нужно добавить управление версиями функций, зачем ограничивать это только документацией? Если я могу указывать и запрашивать версии функций, было бы разумно разрешить выполнение на основе номера версии?

Либо способ загрузить несколько версий функции и иметь возможность выбрать одну для выполнения, либо позволить пользователю выбрать одну из разных версий для загрузки в список функций, который мы видим с помощью gcm, а затем выполнить эту.

Итак, вот доказательство концепции, которую я разработал на основе команд ScriptFileInfo:
https://gist.github.com/jdhitsolutions/65070cd51b5cfb572bc6375f67bcbc3d

На самом деле я пытаюсь смоделировать или прототипировать опыт. Я бы предпочел, чтобы данные отображались с помощью Get-Command, потому что соответствующий тип уже существует.

И получается смесь файлов.

Если функция принадлежит модулю, я не буду беспокоиться о версиях команд. Этим должен заниматься модуль.

Суть

Доказательство концепции добавления и получения информации о метаданных PowerShell.

Доказательство концепции добавления и получения информации о метаданных PowerShell - PSFunctionInfo.format.ps1xml

Хороший Джефф!

Так как же нам обрабатывать несколько версий одной и той же функции?
Как явно загрузить определенную версию функции?
Как явно выполнить конкретную версию функции?

@doctordns Вы несете ответственность за определение того, что запускать, и работу с несколькими версиями. Мой код прототипа просто перечисляет элементы в FunctIon: Psdrive и отображает информацию о метаданных. Насколько я знаю, в psdrive не может быть дублирующихся функций. Моя цель заключалась в том, что если у меня загружена отдельная функция, я хочу иметь возможность получать версию и, возможно, другую информацию о метаданных.

Хотя я думаю, было бы замечательно, если бы PowerShell поддерживал _embedded_ PSScriptInfo метаданные для _scripts_ ... пожалуйста, не делайте этого на уровне _function_.

Версии полезны, только если вы можете что-то с ними сделать

PowerShell в настоящее время _отчитывает_ версию по командам, но фактическая версия берется из _module_. Наличие отдельных версий для каждой функции не поможет, это просто сбивает с толку. Независимо от того, как вы распространяете свой код, вы не распространяете «фрагменты» подфайлов, и пользователь не может загрузить отдельную функцию (или что-либо еще, кроме полного файла), поэтому нет смысла пытаться их версии.

Думаю, нам нужны версии для модулей и скриптов. Функции должны наследовать свою версию от _module_, который их содержит. Скриптам нужна собственная версия.

Для записи:

Если у вас есть файл .ps1, в котором есть несколько функций, вам необходимо изменить расширение. Если вы этого не сделаете, то пользователи все равно не смогут обнаружить эти функции, поэтому управление версиями не имеет значения. Мы должны активно препятствовать тому, чтобы кто-либо пытался распространять _функции_ в чем-либо, кроме модуля. 🤨

@Jaykul Я согласен с тем, что если функция поставляется с модулем, который должен быть целью, версия модуля имеет значение. Однако есть много пользователей, которые используют автономные функции. Может быть загружен в профиль или в источник, чтобы удовлетворить конкретную потребность. Не все, что я делаю, нужно загружать и встроить в модуль. Я хочу управлять этими немодульными функциями. Мне нужен способ фиксировать версию и другую информацию метаданных, как мы это делаем для команд, загружаемых из модуля. Возможно, ответ - новая команда вроде моего прототипа.

@Jaykul Я думаю, что некоторые из нас уже сказали, что это действительно будет полезно для нас и что мы действительно распределяем отдельные функции.

ИМО, не всему нужен модуль.

Предлагаемая функция может быть вам не полезна. И это нормально. Но это для других из нас.

Мне нравится идея управления версиями функций. Но если мы сделаем решение, это должно быть больше, чем небольшая документация, которую вы могли бы сделать в комментариях. Без возможности контролировать загрузку различных версий и т. Д. Это функция, без которой мы, возможно, пока сможем обойтись.

Я предлагаю отказаться от этой идеи для версии 7.0. Мы СЛИШКОМ близки к RTM, чтобы добавлять новые функции. У меня плохие воспоминания о NT 5 дней !! Если мы сможем вернуться к 7.1, ЗАТЕМ давайте поговорим подробнее о том, как реализовать это полностью. Попытка просто выдвинуть это в последнюю минуту - верный способ вызвать разочарование.

Если это произойдет, это будет добавление 7.1. Я думаю, что вопрос загрузки нужной версии зависит от пользователя. Опять же, все, что я прошу, - это способ получить информацию о версии из загруженной автономной функции без необходимости копаться в исходном коде.

Я согласен с 7.1.

В то же время, я знаю пользователей и готов поспорить, что решение для документации будет генерировать запросы только для функций времени выполнения на основе версий. Я бы хотел, чтобы мы рассмотрели законченное и элегантное, а также хорошо спроектированное решение. .

У нас уже есть решение для автономных функций - выигрывает последняя загруженная. :-)

Без возможности контролировать загрузку различных версий и т. Д. Это функция, без которой мы можем пока обойтись.

Это заставит нас проверять версию функции при каждом ее вызове. Это совершенно неприемлемо по соображениям производительности. Модуль - лучший компромисс - проверка версии выполняется один раз при загрузке модуля.

@ SteveL-MSFT Я считаю, что он готов для заключения комитета PowerShell. Опытный образец №11686.

Вроде все сошлись во мнении, что версию для скриптов полезно иметь в движке.
Версия для функций находится под вопросом, поскольку существует модульная концепция.

Общим ограничением является то, что мы можем видеть только версии для загруженных скриптов и функций и не можем сделать это с помощью import-module - загрузить необходимую версию, но get-module также не имеет явных параметров версии.

Не зацикливайтесь на этом и не усложняйте задачу более сложной, чем она должна быть. Функции, поставляемые с модулями, относятся к модулю. Полная остановка. Это должно быть рекомендуемой передовой практикой. Однако не все функции, которые могут использоваться в производственной среде, развертываются с модулем. На самом деле меня не волнует, как это развернуть. Все, что я говорю, это то, что мне нужен способ взглянуть на загруженную функцию в Function: PSDrive и уметь видеть номер версии и, возможно, некоторую другую информацию о метаданных. Я не хочу заставлять себя или конечного пользователя отслеживать исходный код или папку для обнаружения информации о версии.

Я надеялся, что Get-Command станет инструментом для сбора этой информации, но, возможно, это нужно выделить во что-то совершенно отдельное для управления автономными функциями.

И, возможно, ответ состоит в том, что эту проблему лучше оставить на усмотрение сообщества. В таком случае, я думаю, у меня есть хорошее начало для решения.

Честная правда заключается в том, что использование точечных источников - неправильный путь, и их не следовало рекомендовать все те годы, когда модульная система появилась в v2. Единственный раз, когда это было хоть сколько-нибудь разумно для использования, было в v1.

Как мы все знаем сейчас, все функции должны быть реалистично размещены в модуле, даже те, которые вы загружаете как часть своего профиля (который вы должны загрузить в модуль, содержащий эти функции) или используя как часть более крупного скрипта для упрощения обслуживания, или даже те особые функции, которые вам нужно использовать в скриптах xyz.

Я могу только видеть, что это изменение добавит больше путаницы для тех, кто переходит на язык, чем пользы, добавляя предложенный атрибут [Version] к определениям функций, при этом многие думают, что им потребуется установить версии модуля и функции, когда они это делают. вещи правильно и фактически строят модули многоразового кода.

Да, это означает, что у вас должны быть psd1 и psm1, но 2 файла для надлежащего обнаружения и обслуживания - это не большая проблема, с которой действительно нужно справиться.

Как вы можете сказать, я лично не согласен с этим изменением и думаю, что вместо этого можно сосредоточиться на лучших вещах.

Да, это означает, что у вас должны быть psd1 и psm1, но 2 файла для надлежащего обнаружения и обслуживания - это не большая проблема, с которой действительно нужно справиться.

Да, это огромный вопрос. Попытки превратить администраторов-скриптеров в разработчиков значительно поднимают барьер для входа.

Сказать «о, вы должны скопировать это сюда и скопировать это там, а затем импортировать» гораздо сложнее и гораздо более подвержено ошибкам, чем сказать «скопируйте и вставьте это в файл с именем run.ps1, а затем введите \ run .ps1 ".

Это незначительное изменение, и оно принесет гораздо больше пользы обычным сценариям / администраторам, чем тернарные операторы или объединение нуля (что я до сих пор не понимаю) или множество других недавних изменений, которые были внесены для тех из вас, кто является разработчиками. Как и было сказано, о версиях функций могу сказать: если она вам не нравится, не используйте ее.

@ SteveL-MSFT Я полагаю, комитет PowerShell мог бы рассмотреть запрос на поддержку версий для скриптов и автономных функций. Прототип находится в № 11686.

Честная правда в том, что использование точечных источников - неправильный путь,

Но люди это делают, и в любом случае это не единственный вариант использования этого запроса.

и не следовало рекомендовать все те годы, когда модульная система появилась в v2. Единственный раз, когда это было хоть сколько-нибудь разумно для использования, было в v1.

Как мы все знаем сейчас, все функции должны быть реалистично размещены в модуле, даже те, которые вы загружаете как часть своего профиля (который вы должны загрузить в модуль, содержащий эти функции) или используя как часть более крупного скрипта для упрощения обслуживания, или даже те особые функции, которые вам нужно использовать в скриптах xyz.

Я могу только видеть, что это изменение добавит больше путаницы для тех, кто переходит на язык, чем пользы, добавляя предложенный атрибут [Version] к определениям функций, при этом многие думают, что им потребуется установить версии модуля и функции, когда они это делают. вещи правильно и фактически строят модули многоразового кода.

Да, это означает, что у вас должны быть psd1 и psm1, но 2 файла для надлежащего обнаружения и обслуживания - это не большая проблема, с которой действительно нужно справиться.

Да, но это не актуально. Никто не возражает, что мы не должны версировать модули. ;-)

Как вы понимаете, я лично не согласен с этим изменением и думаю, что есть более важные вещи, на которых можно сосредоточиться.

Вам не нужно будет его использовать. На самом деле вас не заставляют использовать [CmdletBinding ()] или наборы параметров.
У команд и командлетов есть версии.
Если у самой функции есть версия, _ независимо от того, находится ли указанная функция в модуле_, это просто второстепенный, но полезный момент в документации. Я создал множество модулей с различными и не связанными между собой инструментами, которые не оправдывают свои собственные отдельные модули. Если мой модуль MiscStuff 1.1.0002 , это отлично подходит для распространения; Я использую это. Если в нем тридцать функций, и я хочу быстро отметить, использую ли я Do-Thing 7.9.0 и могу ли сопоставить его с элементом в моем журнале изменений (что я и делаю!), Мне нужен какой-нибудь формальный метод для делать это, чего ни в коем случае не потребуют те, кто этого не желает.

@ PowerShell / комитет по PowerShell рассмотрел это, мы считаем, что правильное решение для управления версиями для функций скрипта - заключить их в модуль. Также неясно, каково будет ожидаемое поведение, если функция сценария находится внутри модуля, но имеет свой собственный атрибут версии. Кроме того, есть опасения по поводу других частей PowerShell, PowerShellGet и PSGallery, которые необходимо обновить с учетом этого нового атрибута. Если желательно иметь возможность передавать один файл сценария вместо папки (модуля), тогда было бы лучше инвестировать в возможность напрямую импортировать модуль zip / nupkg и упростить превращение .ps1 в модуль.

Как администратор, а не разработчик, я не думаю, что # 7259 и этот запрос (# 11667) имеют какое-либо отношение друг к другу.

Как администратор-скриптер, я НЕ БУДУ учиться использовать модули. Ко мне это не имеет отношения. Он не дает мне ЦЕННОСТИ. Это накладные расходы ДЛЯ РАЗРАБОТЧИКОВ. Модули не запускаются. (Не только для меня, но и для большинства админ-скриптеров.)

Для администраторов скриптов, а не разработчиков - как комитет предлагает осуществлять управление версиями для функций / фильтров?

Не хочу противоречить, но ... управление версиями само по себе является концепцией разработчика, по большому счету. Я не уверен, почему вы пытаетесь провести эту черту здесь, из всех возможных мест. 😕

Потому что я выпустил десятки автономных функций и скриптов. Без модулей. Совершенно уверен, что это описано выше в предыдущих комментариях от меня и нескольких других популярных блоггеров / издателей.

Не думаю, что # 7259 и этот запрос (# 11667) как-то связаны друг с другом.

Да, если честно, я тоже не понимаю.

Я НЕ научусь пользоваться модулями.

FWIW вы просто меняете расширение на psm1 и (необязательно) запускаете New-ModuleManifest . Это не так уж и много.

Ко мне это не имеет отношения. Он не дает мне ЦЕННОСТИ.

Если вы публикуете что-то для других, это определенно имеет ценность. Из-за того, как области видимости работают с модулями, намного сложнее вмешиваться в чье-то глобальное состояние сеанса и наоборот. Это делает вашу функцию значительно более устойчивой к неожиданным изменениям в средах.

Кроме того, его легче потреблять. Если вы выпускаете функцию как скрипт, людям нужно расставить точки по источнику, они должны знать, где она находится, поставить точку в источнике, а затем использовать команду. Если вы выпускаете его как модуль, люди могут просто развернуть его заранее и вызывать его, когда захотят.

как комитет предлагает делать версии для функций / фильтров?

Если бы управление версиями было реализовано для отдельных функций, ожидаете ли вы, что их версия будет доступна для запросов?

Если да, то можете ли вы подробнее рассказать о сценарии, в котором пользователь будет запрашивать его? Ожидаете ли вы, что он будет работать с любыми другими системами, такими как теги #requires ?

Если бы это были просто метаданные, видимые в источнике, вы могли бы просто поместить их в раздел NOTES справки на основе комментариев.

На основании заключения комитета PowerShell я закрываю проблему (прекращаю отслеживание), но вы можете продолжить обсуждение.

Да, сегодня я использую раздел ЗАМЕТКИ и $ pVersion / $ pName. Я подозреваю, что большинство из нас нуждаются в этом.

Когда я писал «Не буду», я говорил об общем человеке, а не обо мне конкретно (хотя я попадаю в эту категорию).

и $ pVersion / $ pName

Что ты с ними делаешь? У вас есть пример опубликованной вами нечеткой функции? Это может помочь в понимании варианта использования.

Когда я писал «Не буду», я говорил об общем человеке, а не обо мне конкретно (хотя я попадаю в эту категорию).

Да, определенно есть люди, которые отказываются изучать модули. Я знал и знаю множество таких людей (и несколько лет назад их называли народом), и нет никаких аргументов в пользу того, что они существуют. Тем не менее, совпадение между этими людьми и теми, кто 1. заботится о версиях и 2. имеет какое-либо желание публиковать свои работы - по моему опыту почти ноль. На самом деле большинство людей, установивших флажки 1 и 2, потратят ~ 10 минут на то, чтобы погуглить, как быстро обернуть модуль перед публикацией. Или, чаще, они не заботятся о версиях, и они просто хлопают об этом в суть или сообщение в блоге.

и $ pVersion / $ pName

Что ты с ними делаешь? У вас есть пример опубликованной вами нечеткой функции? Это может помочь в понимании варианта использования.

Когда я писал «Не буду», я говорил об общем человеке, а не обо мне конкретно (хотя я попадаю в эту категорию).

Да, определенно есть люди, которые отказываются изучать модули. Я знал и знаю множество таких людей (и несколько лет назад их называли народом), и нет никаких аргументов в пользу того, что они существуют. Тем не менее, совпадение между этими людьми и теми, кто 1. заботится о версиях и 2. имеет какое-либо желание публиковать свои работы - по моему опыту почти ноль. На самом деле большинство людей, установивших флажки 1 и 2, потратят ~ 10 минут на то, чтобы погуглить, как быстро обернуть модуль перед публикацией. Или, чаще, они не заботятся о версиях, и они просто хлопают об этом в суть или сообщение в блоге.

Я умею пользоваться модулями. Я их все время пишу. Черт возьми, эти функции часто находятся внутри модулей , и я использую внутреннее управление версиями, поэтому я могу отслеживать, что в последний раз изменялось в функции, без необходимости обращаться к внешнему (для функции) журналу изменений. Я не понимаю, почему .VERSION в функции мешает версии модуля. Я просто не знаю.

Я умею пользоваться модулями. Я их все время пишу. Черт возьми, эти функции часто являются _ внутренними _ _ модулями_, и я использую внутреннее управление версиями, чтобы я мог отслеживать, что последнее изменено в функции, без необходимости извлекать внешний (для функции) журнал изменений. Я не понимаю, почему .VERSION в функции мешает версии модуля. Я просто не знаю.

Верно, но главное: что вы собираетесь делать с этими метаданными? Это просто то, на что вы смотрите в источнике функции? Если да, то можете ли вы пояснить, почему раздел .NOTES для этого не подходит?

Также эта проблема заключалась в том, чтобы позволить отдельной функции объявлять номер своей версии в выводе Get-Command . Запрос на включение полного журнала изменений был бы совсем другой реализацией и, вероятно, лучше решал бы его собственную проблему.

на это легко ответить. это означает, что мне нужно открыть его в редакторе или выполнить какой-то неудобный поиск по строке, чтобы узнать версию, установленную на данном компьютере / в данном месте на указанном компьютере. это не всегда легко, как этот ответ. :-)

Не совсем?

Поле Notes отображается в выводе Get-Help, если вы пишете его как правильную справку на основе комментариев (что вам в любом случае должно быть).

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

Get-Help test -Full

# or
Get-Help test | % alertSet

Результат:

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

Так? Я не впечатлен. Были и другие, более подробные способы работы с тернарными операторами. И все же ... реализован более компактный способ. Потому что (часть) сообщества этого хотела. Я до сих пор не знаю, что такое операторы объединения с нулем.

Тогда не совсем уверен, что тебе нужно. Это совершенно очевидно позволяет вам относительно легко делать то, что вам нужно. Я не вижу смысла добавлять туда дополнительные поля.

Если да, не стесняйтесь открывать PR, и мы поговорим об этом дальше. 🤷

PR для чего? Я не программист на C #. Я не был профессиональным разработчиком более 30 лет.

Я думаю, что некоторые из нас действительно ясно понимали, что нам нужно, и наши варианты использования, и видели, что эти опасения сведены к минимуму, как вы только что сделали.

Те из вас, кто не знает сценариев администратора, думают: «просто сделайте это модулем». Большинство администраторов-скриптеров не знают, как это сделать, и они скажут (и я согласен), что это слишком много проблем, когда они увидят требования.

Но это бессмысленно, и я знал лучше. Заключение комитета PowerShell уже было сделано. Извините, я прокомментировал.

Заключение комитета PowerShell уже было сделано.

Любые предварительные выводы могут быть пересмотрены на основании отзывов.

Я думаю, что некоторые из нас действительно ясно понимали, что нам нужно, и наши варианты использования, и видели, что эти опасения сведены к минимуму, как вы только что сделали.

Я очень старался разобраться в реальной цели и вариантах использования, и мои вопросы в основном игнорировались. Очень хотелось бы понять.

Те из вас, кто не знает сценариев администратора

Чувак, я сисадмин. Большую часть своей карьеры я провел, думая, что синтаксис хеш-таблицы - это «синтаксис сплаттинга». Большинство моих коллег знают только абсолютные основы PowerShell (если вообще знают), как и большинство людей, которым я помогаю в Discord / Reddit.

Я понимаю, что у вас есть претензии к команде разработчиков PS, но, пожалуйста, не делайте вид, будто я не могу понять вашу точку зрения, потому что теперь я знаю C #. Я постоянно борюсь за эту точку зрения на это репо.

подумайте "просто сделайте это модулем". Большинство администраторов-скриптеров не знают, как это сделать, и они скажут (и я согласен), что это слишком много проблем, когда они увидят требования.

Для тех, кто позже столкнется с этой веткой и не захочет создавать модуль, вот требования:

1. Переименуйте файл .ps1 в .psm1
2. Используйте Import-Module ./file.psm1 вместо . ./file.ps1

Вот и все, у вас есть модуль. Все остальное - это просто лучшие практики, о которых вам пока не нужно беспокоиться. Если вы хотите его версию, вам понадобится манифест, вот полные требования для этого:

1. Переименуйте файл .ps1 в .psm1
2. Выполнить New-ModuleManifest -RootModule ./file.psm1 -Path ./file.psd1 -ModuleVersion 1.0.0
3. Используйте Import-Module ./file.psd1 вместо . ./file.ps1

Если вы отправляете в ps1 незакрепленную функцию, которую потребителю (или вам самому) нужно будет расставить точки в источнике, просто вставьте ее в модуль очень быстро, это облегчит вам жизнь.

Если вы отправляете сценарий, вызываемый напрямую, вы можете использовать New-ScriptFileInfo который сгенерирует файл сценария с таким комментарием:

<#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()

И вы можете запросить это с помощью Test-ScriptFileInfo .