버전을 추가하기 위해 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입니다. CIM 또는 원격 레지스트리 서비스를 사용하여 지정된 컴퓨터에 설치된 .NET Framework 버전을 찾고(다시 - 수행할 작업을 파악하기 위해 포트 확인), 이를 보고하고 차단된 버전에 대해 보고합니다. 만약에 어떠한.

이들은 독립 실행형 기능입니다. 모듈의 일부가 아닙니다. 그러나 그들은 지난 몇 년 동안 정기적인 업데이트를 거쳤습니다.

각각에 버전을 첨부하는 것이 좋습니다. 지금은 소스 상단에 "마지막 수정 날짜"만 있습니다. 그다지 유용하지 않습니다 ...

내 생각에 배포는 이 토론과 관련이 없습니다. 그리고 예, git이 역할을 하지만 문제는 아닙니다. PowerShell에 있고 독립 실행형 기능을 사용하는 경우. Get-Command Get-Foo를 실행할 때 함수의 버전 번호를 보고 싶습니다. 그것은 그것만큼 간단합니다. 함수가 어떻게 배포되었는지는 중요하지 않습니다. 함수에 메타데이터를 주입하는 방법을 알려주세요.

그리고 절대적으로 명확하게, 나는 사용자 또는 심지어 나 자신에게 소스를 추적하고 댓글이나 메모를 찾도록 강요하고 싶지 않습니다.

나는 확실히 일부 독립 실행형 기능을 작성/사용하지만 대부분은 모듈에 있습니다. 그리고 대부분은 독립 실행형 기능으로 사용할 수 있는 임의의 표류 화물 도구입니다. 나는 항상 주석 블록 내의 .NOTES 에 의미론적 버전과 변경 로그를 넣고 시작 블록에 [version]$Version 를 넣습니다 [version()] 또는 [cmdletbinding(Version='01.00.0000')] 와 같은 것을 갖는 것은 장관일 것입니다. 많은 사람들이 psm1 파일에 여러 기능을 넣었다는 것을 알고 있기 때문에 .VERSION보다 .VERSION이 더 좋습니다(그렇지는 않지만).
git, btw도 사용하지만 개별 기능을 변경할 때마다 커밋하지는 않습니다. 모듈을 변경할 때 번들로 묶고 커밋합니다. 일반적으로 커밋 메시지로 모듈 버전을 사용합니다. 그래, 그래, 나도 알아, 내가 이상해.

스크립트가 $env:PATH 에 있으면 Get-Command에 대해 표시됩니다. 따라서 기존 ScriptFileInfo 메타데이터를 버전을 포함하는 ExternalScriptInfo 멤버에 매핑하는 것이 합리적으로 보입니다.

스티브의 가정에 주의하십시오. 여러 기능이 있는 단일 ps1 파일이 있을 수 있습니다. Get-Command가 스크립트 파일을 찾을 수 있다는 것을 신뢰하고 싶지 않습니다. 젠장, PowerShell 프로필 스크립트에서 버전이 지정된 함수를 정의하고 싶을 수도 있습니다.

확실히 내 프로필 스크립트에 버전 기능이 있습니다.

Version 속성이 있는 System.Management.Automation.FunctionInfo 유형이 이미 있습니다. 함수가 로드될 때 버전 속성이 함수의 메타데이터에서 채워지도록 하는 방법이 필요합니다.

좋은 피드백 주셔서 감사합니다! 아직 질문이 있습니다. PowerShell이 ​​같은 이름을 가진 일부 함수를 찾은 경우 어떤 동작이 예상됩니까? 더 높은 버전으로 기능을 실행하시겠습니까? 범위를 고려해야 합니까(현재 범위에서 이전 함수를 로드해야 함 - 전역 범위에서 더 많은 새 함수를 호출해야 함)? 아니면 정보 속성만 갖고 싶습니까?

이것은 기능을 실행하거나 배포하는 것이 아닙니다. 내가 원하는 것은 버전 정보를 추적하고 검색하는 방법을 제공하여 Get-Command를 실행하거나 Get-Function과 같은 새 명령을 실행하면 함수에 대한 일부 메타데이터를 볼 수 있도록 하는 메커니즘뿐입니다. PowerShell 스크립팅을 통해 프로토타입을 만들 수 있는 몇 가지 아이디어가 있습니다.

좋은 피드백 주셔서 감사합니다! 아직 질문이 있습니다. PowerShell이 ​​같은 이름을 가진 일부 함수를 찾은 경우 어떤 동작이 예상됩니까? 더 높은 버전으로 기능을 실행하시겠습니까? 범위를 고려해야 합니까(현재 범위에서 이전 함수를 로드해야 함 - 전역 범위에서 더 많은 새 함수를 호출해야 함)? 아니면 정보 속성만 갖고 싶습니까?

PS가 기능을 실행하는 방식에 변화를 제안한 사람은 아무도 없다고 생각합니다. 우리는 단지 그들에 버전을 넣고 싶습니다. 정보 제공 및 심문 방법.

감사 해요! 다음 질문이 있습니다. 일부 기능이 있는 파일은 파일의 모든 기능에 공통적인 버전 속성을 가질 수 있습니다. 우리는 이것을 고려해야합니까?

PowerShell 스크립팅을 통해 프로토타입을 만들 수 있는 몇 가지 아이디어가 있습니다.

요점에서 아이디어를 공유할 수 있습니다.

그게 내 계획이야.

클래식 버전 또는 SymVer 2.0이어야 합니까?

나는 점점 더 함수 버전 관리가 좋은 것이라는 확신을 갖게 되었습니다.

@iSazonov 최신 질문에 답하려면 - 만약 우리가 그것을 갖고 있다면 SymVer를 사용하지 않는 이유는 무엇입니까?

그리고 함수 파일과 관련하여 - 나는 속성이 파일별 속성이 없는 함수별로 있다고 주장합니다. 오늘날의 CMDLETBinding이 작동하는 것과 매우 유사합니다.

프로토타입이 ##11686에 들어왔습니다.

PR에서 아티팩트를 다운로드하고 새로운 속성으로 플레이할 수 있습니다.

달콤한.

그것에 대해 생각해보십시오 - 스크립트 버전을 포함하도록 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이 ​​_scripts_에 대한 _embedded_ PSScriptInfo 메타데이터를 지원한다면 훌륭할 것이라고 생각하지만 ... _function_ 수준에서는 이 작업을 수행하지 마십시오.

버전은 당신이 그것에 대해 뭔가를 할 수 있는 경우에만 유용합니다

PowerShell은 현재 명령의 버전을 _보고_하지만 실제 버전은 _module_에서 가져옵니다. 각 기능에 대해 별도의 버전을 갖는 것은 도움이 되지 않을 뿐 아니라 혼란스러울 뿐입니다. 코드를 배포하는 방법에 관계없이 하위 파일 "덩어리"를 배포하지 않으며 사용자는 개별 기능(또는 전체 파일을 제외한 어떤 것도 로드할 수 없음)을 로드할 수 없습니다.

모듈과 스크립트용 버전이 필요하다고 생각합니다. 함수는 함수를 포함하는 _module_에서 해당 버전을 상속해야 합니다. 스크립트에는 자체 버전이 필요합니다.

기록을 위해:

여러 기능이 포함된 .ps1 파일이 있는 경우 확장자를 변경해야 합니다. 그렇지 않으면 사용자가 해당 기능을 발견할 수 있는 방법이 없으므로 버전 관리는 중요하지 않습니다. 우리는 _functions_을 모듈 이외의 다른 것으로 배포하려는 사람을 적극적으로 권장하지 않아야 합니다. 🤨

@Jaykul 함수가 모듈과 함께 제공되는 경우 목표가 되어야 하는 모듈 버전이 중요하다는 데 동의합니다. 그러나 독립 실행형 기능을 사용하는 사용자가 많이 있습니다. 특정 요구 사항을 충족하기 위해 소싱된 프로필 또는 점에 로드되었을 수 있습니다. 내가 하는 모든 작업을 모듈에 로드하고 빌드할 필요는 없습니다. 내가 관리하고 싶은 것은 이러한 비 모듈 기능입니다. 모듈에서 로드된 명령과 마찬가지로 버전 및 기타 메타데이터 정보를 캡처하는 방법을 원합니다. 아마도 대답은 내 프로토타입과 같은 새로운 명령일 것입니다.

@Jaykul 제 생각에 우리 중 몇몇은 이미 그것이 우리에게 유용할 것이며 우리가 실제로 단일 기능을 배포하고 있다고 말했습니다.

IMO, 모든 것에 모듈이 필요한 것은 아닙니다.

제안된 기능이 유용하지 않을 수 있습니다. 괜찮습니다. 그러나 그것은 우리 중 다른 사람들에게 있습니다.

기능 버전 관리라는 아이디어가 마음에 듭니다. 그러나 우리가 솔루션을 한다면 주석으로 할 수 있는 약간의 문서 이상이어야 합니다. 다른 버전의 로드를 제어할 수 있는 능력이 없다면 이것은 지금으로서는 우리가 할 수 있는 기능입니다.

7.0에서는 이 아이디어를 삭제하는 것이 좋습니다. 우리는 새로운 기능을 믹스에 밀어넣기에는 RTM에 너무 가깝습니다. NT 5days에 대한 나쁜 기억이 있습니다!! 이것을 7.1로 되돌릴 수 있다면 완전히 구현하는 방법에 대해 더 자세히 이야기합시다. 마지막 순간에 이것을 밀어내려고 하는 것은 실망을 야기하는 확실한 방법입니다.

이런 일이 발생하면 7.1 추가 사항입니다. 올바른 버전을 로드하는 문제는 사용자에게 달려 있다고 생각합니다. 다시 말하지만, 내가 요구하는 것은 소스를 파헤칠 필요 없이 로드된 독립 실행형 함수에서 버전 정보를 검색하는 방법에 대한 것입니다.

7.1에 동의합니다.

동시에 나는 사용자를 알고 있으며 문서 솔루션이 버전 기반 런타임 기능에 대한 요청만 생성할 것이라고 확신합니다. 나는 우리가 완벽하고 우아할 뿐만 아니라 엔지니어링된 솔루션을 고려하기를 바랍니다. .

우리는 이미 독립 실행형 기능을 위한 솔루션을 가지고 있습니다. 마지막에 로드된 것이 이깁니다. :-)

다른 버전 등의 로드를 제어하는 ​​기능이 없으면 현재로서는 이 기능 없이는 할 수 없는 기능입니다.

이렇게 하면 호출될 때마다 함수의 버전을 확인해야 합니다. 이것은 성능상의 이유로 완전히 받아들일 수 없습니다. 모듈은 최상의 절충안입니다. 버전 확인은 모듈 로드 시 한 번 수행됩니다.

@SteveL-MSFT PowerShell 위원회 결론을 위한 준비가 되었다고 생각합니다. 프로토타입 #11686.

스크립트용 버전이 엔진에 있는 것이 유용하다는 데 모두 동의한 것 같습니다.
모듈 개념이 존재하기 때문에 기능의 버전이 의심됩니다.

일반적인 제한은 로드된 스크립트 및 기능의 버전만 볼 수 있고 import-module이 수행할 수 없다는 것입니다. 필요한 버전을 로드하지만 get-module에도 명시적인 버전 매개변수가 없습니다.

이것을 지나치게 생각하거나 필요 이상으로 복잡하게 만들지 마십시오. 모듈과 함께 제공되는 기능은 모듈에 속합니다. 마침표. 권장되는 모범 사례입니다. 그러나 프로덕션에서 사용할 수 있는 모든 기능이 모듈과 함께 배포되는 것은 아닙니다. 나는 그것이 어떻게 배포

Get-Command가 이 정보를 수집하는 도구가 되기를 희망했지만 독립 실행형 기능 관리를 위해 완전히 별도의 것으로 분리해야 할 수도 있습니다.

그리고 아마도 그 대답은 이 문제가 해결하기 위해 커뮤니티에 맡기는 것이 가장 좋다는 것입니다. 어떤 경우에는 솔루션을 잘 시작했다고 생각합니다.

여기서 정직한 사실은 도트 소싱 기능이 올바른 방향이 아니며 모듈 시스템이 v2에 나왔을 때부터 권장되어서는 안 된다는 것입니다. 원격으로 사용할 수 있는 유일한 시간은 v1에서였습니다.

이제 우리 모두가 알고 있듯이 모든 기능은 실제로는 프로필의 일부로 로드하거나(이러한 기능을 포함하는 모듈을 로드해야 함) 더 쉬운 유지 관리를 위해 더 큰 스크립트의 일부로 사용하는 기능을 포함하여 모듈 내에 배치되어야 합니다. 또는 xyz 스크립트에서 사용해야 하는 단일 기능도 있습니다.

나는 이 변경이 함수 정의에 제안된 [Version] 속성을 추가함으로써 이점보다 언어를 사용하는 사람들에게 더 많은 혼란을 줄 것이라는 것을 알 수 있습니다. 많은 사람들은 수행할 때 모듈 및 함수 버전을 설정해야 한다고 생각합니다 적절하고 실제로 재사용 가능한 코드 모듈을 구축합니다.

네, 이것은 당신이 psd1과 psm1을 가지고 있어야 한다는 것을 의미합니다. 그러나 적절한 발견과 유지보수를 위해 2개의 파일은 관리에 대한 큰 요구가 아닙니다.

아시다시피 저는 개인적으로 이 변경 사항에 동의하지 않으며 대신 집중해야 할 더 나은 사항이 있다고 생각합니다.

네, 이것은 당신이 psd1과 psm1을 가지고 있어야 한다는 것을 의미합니다. 그러나 적절한 발견과 유지보수를 위해 2개의 파일은 관리에 대한 큰 요구가 아닙니다.

예, 그것은 큰 요구입니다. 관리자 스크립터를 개발자로 만들려는 시도는 진입 장벽을 크게 높입니다.

"오 이것을 여기에 복사하고 거기에 복사한 다음 가져와야 합니다"라고 말하는 것은 "이것을 복사하여 run.ps1이라는 파일에 붙여넣고 ,\run을 입력하는 것보다 훨씬 더 복잡하고 오류가 발생하기 쉽습니다. .ps1".

이것은 사소한 변경이며 삼항 연산자 또는 null-coalescing(나는 아직 이해하지 못함) 또는 개발자인 여러분을 위해 만들어진 다른 많은 최근 변경보다 캐주얼/관리자 스크립터에게 훨씬 더 도움이 됩니다. 그것에 대해 말했듯이 기능 버전에 대해 말할 수 있습니다. 마음에 들지 않으면 사용하지 마십시오.

@SteveL-MSFT 나는 PowerShell 위원회가 스크립트 및 독립 실행형 기능에 대한 버전 지원 요청을 볼 수 있다고 믿습니다. 프로토타입은 #11686에 있습니다.

정직한 사실은 도트 소싱 기능이 올바른 방향이 아니라는 것입니다.

그러나 사람들은 그렇게 하며 어쨌든 이 요청의 유일한 사용 사례는 아닙니다.

그리고 모듈 시스템이 v2에 나왔을 때 몇 년 동안 권장되어서는 안 되었습니다. 원격으로 사용할 수 있는 유일한 시간은 v1에서였습니다.

이제 우리 모두가 알고 있듯이 모든 기능은 실제로는 프로필의 일부로 로드하거나(이러한 기능을 포함하는 모듈을 로드해야 함) 더 쉬운 유지 관리를 위해 더 큰 스크립트의 일부로 사용하는 기능을 포함하여 모듈 내에 배치되어야 합니다. 또는 xyz 스크립트에서 사용해야 하는 단일 기능도 있습니다.

나는 이 변경이 함수 정의에 제안된 [Version] 속성을 추가함으로써 이점보다 언어를 사용하는 사람들에게 더 많은 혼란을 줄 것이라는 것을 알 수 있습니다. 많은 사람들은 수행할 때 모듈 및 함수 버전을 설정해야 한다고 생각합니다 적절하고 실제로 재사용 가능한 코드 모듈을 구축합니다.

네, 이것은 당신이 psd1과 psm1을 가지고 있어야 한다는 것을 의미합니다. 그러나 적절한 발견과 유지보수를 위해 2개의 파일은 관리에 대한 큰 요구가 아닙니다.

예, 하지만 이것은 관련이 없습니다. 아무도 우리가 모듈을 버전화해서는 안 된다고 주장하지 않습니다. ;-)

아시다시피, 저는 개인적으로 이 변경 사항에 _동의하지 않으며_ 대신 집중해야 할 더 나은 사항이 있다고 생각합니다.

당신은 그것을 사용할 필요가 없습니다. 실제로 [CmdletBinding()] 또는 매개 변수 집합을 사용하도록 강요되지도 않습니다.
명령 및 cmdlet에는 버전이 있습니다.
함수 자체에 버전이 있는 경우 _해당 함수가 모듈 내에 있는지 여부와 상관없이_ 이는 단순히 사소하지만 유용한 문서 요점입니다. 나는 그들 자신의 개별 모듈을 정당화하지 않는 다양하고 관련 없는 도구로 수많은 모듈을 만들었습니다. 내 모듈이 MiscStuff 1.1.0002 이면 배포 부분에 좋습니다. 나는 그것을 사용한다. 내부에 30개의 함수가 있고 내가 Do-Thing 7.9.0 사용하고 있는지 빠르게 확인하고 이를 내 변경 로그의 항목과 연관시킬 수 있다면(그렇게 합니다!) 이것은 원하지 않는 사람들이 요구하지 않을 것입니다.

@PowerShell/powershell-committee가 이를 검토했으며 스크립트 기능에 대한 버전 관리를 위한 적절한 솔루션은 모듈에서 이를 래핑하는 것이라고 생각합니다. 또한 스크립트 함수가 모듈 내에 있지만 고유한 버전 속성이 있는 경우 예상되는 동작이 무엇인지 명확하지 않습니다. 그런 다음 이 새 특성을 존중하기 위해 업데이트해야 하는 PowerShell, PowerShellGet 및 PSGallery의 다른 부분에 대한 우려가 있습니다. 단일 스크립트 파일 대 폴더(모듈)를 전달할 수 있기를 원하는 경우 zip/nupkg 모듈을 직접 가져오고 .ps1을 모듈로 쉽게

개발자가 아닌 관리자 스크립터 로서 #7259와 이 요청(#11667)이 서로 관련이 있다고 생각하지 않습니다.

관리자 스크립터 로서 나는 모듈을 사용하는 방법을 배우지 않을 것입니다. 나와는 관련이 없습니다. 그것은 나에게 가치를 제공하지 않습니다. 개발자에게는 오버헤드입니다. 모듈은 비스타터입니다. (나 뿐만 아니라 대부분의 관리자 스크립트 작성자를 위한 것입니다.)

개발자가 아닌 관리자 스크립터의 경우 - 위원회는 기능/필터의 버전 관리를 어떻게 제안합니까?

반대는 아니지만... 버전 관리 자체는 대체로 개발자 개념입니다. 나는 당신이 가능한 모든 장소에서 왜 여기에 이 ​​선을 그리려고 하는지 잘 모르겠습니다. 😕

수십 개의 독립 실행형 기능과 스크립트를 출시했기 때문입니다. 모듈 없이. 이것은 저와 여러 다른 인기 있는 블로거/출판자들의 이전 의견에서 이미 다뤘습니다.

#7259와 이 요청(#11667)은 아무 상관이 없다고 생각합니다.

네 저도 솔직히 연결이 잘 안되네요.

나는 모듈을 사용하는 방법을 배우지 않을 것입니다.

FWIW에서는 확장자를 psm1 하고 (선택적으로) New-ModuleManifest 합니다. 그것에 많은 것이 없습니다.

나와는 관련이 없습니다. 그것은 나에게 가치를 제공하지 않습니다.

다른 사람들이 소비할 수 있도록 게시하는 경우 확실히 가치가 있습니다. 모듈에 대한 범위가 작동하는 방식은 누군가의 전역 세션 상태를 밟는 것을 훨씬 더 어렵게 만들고 그 반대의 경우도 마찬가지입니다. 이를 통해 기능은 환경의 예상치 못한 차이에 대해 훨씬 더 탄력적입니다.

섭취하기도 훨씬 쉽습니다. 함수를 스크립트로 릴리스하는 경우 사람들은 점 소스를 작성해야 하며 위치를 알고 점 소싱한 다음 명령을 사용해야 합니다. 모듈로 출시하면 사람들이 미리 배포하고 원할 때마다 호출할 수 있습니다.

위원회는 기능/필터의 버전 관리를 어떻게 제안합니까?

개별 기능에 대해 버전 관리가 구현된 경우 해당 버전을 쿼리할 수 있을 것으로 예상합니까?

그렇다면 사용자가 쿼리할 것으로 예상되는 시나리오에 대해 조금 더 자세히 설명해 주시겠습니까? #requires 태그와 같은 다른 시스템에서 작동할 것으로 예상하십니까?

소스에서 볼 수 있는 메타데이터일 경우 주석 기반 도움말의 NOTES 섹션에 넣을 수 있습니다.

PowerShell 위원회 결론에 따라 문제를 종료하지만(추적 중지) 자유롭게 토론을 계속할 수 있습니다.

예, 저는 오늘 NOTES 섹션과 $pVersion/$pName을 사용합니다. 나는 우리 대부분이 필요하다고 생각합니다. 그렇게 하십시오.

내가 "나는 하지 않을 것이다"라고 썼을 때 나는 특정한 사람이 아니라 일반적인 사람에 대해 말하고 있었다(나는 그 범주에 속하지만).

및 $pVersion/$pName

그것들로 무엇을 합니까? 게시한 느슨한 기능의 예가 있습니까? 사용 사례를 이해하는 데 도움이 될 수 있습니다.

내가 "나는 하지 않을 것이다"라고 썼을 때 나는 특정한 사람이 아니라 일반적인 사람에 대해 말하고 있었다(나는 그 범주에 속하지만).

네, 분명히 모듈에 대해 배우기를 거부하는 사람들이 있습니다. 나는 그런 사람들을 많이 알고 있고 현재 알고 있습니다(몇 년 전에는 사람들이라고 했습니다). 그들이 존재한다는 주장은 없습니다. 즉, 그 사람들과 1. 버전 관리에 관심이 있는 사람들과 2. 자신의 작업을 출판하고 싶은 마음이 있는 사람들 사이의 겹침은 제 경험에 거의 0입니다. 실제로 1번과 2번 확인란을 선택하는 대부분의 사람들은 게시하기 전에 모듈을 정말 빨리 래핑하는 방법을 Google에 10분 정도 걸립니다. 또는 더 자주, 그들은 버전 관리에 신경 쓰지 않고 요점이나 블로그 게시물에 그것을 꽝 닫습니다.

및 $pVersion/$pName

그것들로 무엇을 합니까? 게시한 느슨한 기능의 예가 있습니까? 사용 사례를 이해하는 데 도움이 될 수 있습니다.

내가 "나는 하지 않을 것이다"라고 썼을 때 나는 특정한 사람이 아니라 일반적인 사람에 대해 말하고 있었다(나는 그 범주에 속하지만).

네, 분명히 모듈에 대해 배우기를 거부하는 사람들이 있습니다. 나는 그런 사람들을 많이 알고 있고 현재 알고 있습니다(몇 년 전에는 사람들이라고 했습니다). 그들이 존재한다는 주장은 없습니다. 즉, 그 사람들과 1. 버전 관리에 관심이 있고 2. 자신의 작업을 게시하고 싶은 마음이 있는 사람들 사이의 겹침은 제 경험에 _거의_ 0입니다. 실제로 1번과 2번 확인란을 선택하는 대부분의 사람들은 게시하기 전에 모듈을 정말 빨리 래핑하는 방법을 Google에 10분 정도 걸립니다. 또는 더 자주, 그들은 버전 관리에 신경 쓰지 않고 요점이나 블로그 게시물에 그것을 꽝 닫습니다.

모듈 사용법을 알고 있습니다. 나는 그것들을 항상 씁니다. 빌어 먹을, 이러한 기능은 내부 모듈은 많은 시간, 그리고 내가 변경 로그 (함수에) 외부로 꺼내하지 않고 마지막 함수에서 변경 무엇을 추적 할 수 있도록 나는 내부 버전을 사용합니다. 함수의 .VERSION 가 모듈 버전을 방해하는 이유를 모르겠습니다. 난 그냥하지 않습니다.

모듈 사용법을 알고 있습니다. 나는 그것들을 항상 씁니다. 젠장, 이러한 함수는 _inside_ _modules_ 많은 시간을 사용하며, 내부 버전 관리를 사용하므로 외부(함수에 대한) 변경 로그를 가져올 필요 없이 함수에서 마지막으로 변경된 내용을 추적할 수 있습니다. 함수의 .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

그래서? 나는 감동하지 않는다. 삼항 연산자를 수행하는 다른 더 장황한 방법도 있었습니다. 그러나... 더 간결한 방법이 구현되었습니다. (일부) 커뮤니티가 원했기 때문입니다. 나는 여전히 null-coalescing 연산자가 무엇인지 모릅니다.

당신이 무엇을 추구하고 있는지 잘 모르겠습니다. 그것은 당신이 원하는 것을 비교적 쉽게 할 수 있게 해줍니다. 거기에 추가 필드를 추가하는 데 시간을 할애할 가치가 없다고 봅니다.

그렇다면 자유롭게 PR을 열어 주시면 더 자세히 이야기하겠습니다. 🤷

무엇을 위한 PR인가? 저는 C# 코더가 아닙니다. 저는 30년 넘게 전문 개발자가 아닙니다.

나는 우리 중 몇몇이 우리가 추구하는 것과 우리의 사용 사례에 대해 정말 명확했으며 방금 다시 한 것처럼 이러한 우려가 최소화되는 것을 보았다고 생각합니다.

관리자 스크립팅을 넘어선 분들은 "그냥 모듈로 만드세요"라고 생각합니다. 대부분의 관리 스크립터는 방법을 알지 못하며 요구 사항을 보면 너무 문제가 많다고 말할 것입니다(그리고 저도 동의할 것입니다).

그러나 이것은 무의미하고 나는 더 잘 알고 있습니다. PowerShell 위원회의 결론은 이미 도달했습니다. 댓글을 달아 죄송합니다.

PowerShell 위원회의 결론은 이미 도달했습니다.

피드백을 기반으로 설계에 따른 결론을 재고할 수 있습니다.

나는 우리 중 몇몇이 우리가 추구하는 것과 우리의 사용 사례에 대해 정말 명확했으며 방금 다시 한 것처럼 이러한 우려가 최소화되는 것을 보았다고 생각합니다.

나는 실제 목표와 사용 사례가 무엇인지 파악하기 위해 정말 열심히 노력했지만 내 질문은 대부분 무시되었습니다. 정말 이해하고 싶습니다.

관리자 스크립팅을 넘어선 분들

저는 시스템 관리자입니다. 내 경력의 대부분은 해시 테이블 구문이 "스플래팅 구문"이라고 생각하는 데 사용되었습니다. 대부분의 동료는 내가 discord/reddit에서 도움을 주는 대부분의 사람들과 마찬가지로 PowerShell의 절대적인 기본 사항만 알고 있습니다(전혀 있다면).

나는 당신이 PS dev 팀과 약간의 관계를 가지고 있다는 것을 알지만, 내가 우연히 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 쿼리할 수 있습니다.