Powershell: ConvertFrom-Yaml, ConvertTo-Yaml

DSC 측면 에서 비슷한 논의를했습니다.
json 기반 구성 파일을 변경할 수 있도록하여 xml 기반 파일, YAML 기반 파일, Text Manipulation cmdlet 내에서 RegEx 스왑을 지원하는 INI 기반 파일을 수정하는 옵션을 원했습니다.

PS의 기존 지원이 없다는 것은 그러한 능력을 얻기 위해 열심히 노력해야한다는 것을 의미합니다.
커뮤니티 기여를 위해 보류되었지만 PS에 구워지면 DSC 부분도 훨씬 쉬워 질 것입니다.

기본적으로 말할 때 XML 또는 JSON과 같은 의미입니까?

현재 생각하고있는 것은 YAML이 PowerShell에 전혀 구워 지지 않아야한다는 것입니다. 대신 새 버전의 PowerShell을 선택하지 않고도 업데이트 할 수있는 별도의 모듈이어야합니다.

YAML이 XML과 같은 PowerShell로 구워 졌다면 불가능합니다 ([xml] " b "를 생각해보십시오).

JSON 경로를 사용했다면 YAML과 함께 작동하는 cmdlet이있을 것입니다. 따라서 실제로 PowerShell에 구워진 것은 아니지만 YAML 업데이트를 받기 위해 PowerShell을 업데이트해야하는 단점이 있습니다.

@lzybkr 우리가 새 라이브러리를 가져오고 싶지 않다고 말한 것을 알고 있지만 이것이 재평가가 필요할 수 있다고 생각합니다. 이상적으로는 갤러리 에도 모듈을 제공해야하지만 현대 시나리오의 톤에는 YAML이 필요하다고 생각합니다.

6.0 시간대가 아닐 수도 있지만 이에 대해 이야기해야합니다.

@ArieHein- 레지스트리에 해시 배열을 저장하고 검색하는 몇 가지 간단한 함수가 있습니다. REG_SZ 만 처리하십시오. 그러나 간단한 설정 세트의 경우 충분합니다. 사본이 필요한지 알려주십시오.

내가 "네이티브"라고 말했을 때 잘못 착각했습니다. 기본적으로 "내장"을 의미했습니다. 업데이트 할 수있는 스크립트 모듈이 기본 제공 되었다면 문제가되지 않을 것입니다.

첫 번째 토론 # 2109

@iSazonov- 아,

스레드에서 YAML에 대한 AWS 지원에 대한 참조를 발견했습니다. 일부 템플릿을 변환 해 왔으며 이것이 도움이되는 것으로 나타났습니다 : https://github.com/awslabs/aws-cfn-template-flip

@iSazonov 포인터 주셔서 감사합니다. 어떤 이유로 든 찾을 수 없었습니다. 그래도 잘 기억하십시오.

원래 스레드를 다시 읽을 때 향후 어느 시점에서 cmdlet을 확실히 구현하고 갤러리에 제공해야한다고 생각합니다. 품질과 사람들이인지 한 유용성 (6.0.0 이후에 수행 할 일부 리팩토링 작업과 함께)을 기반으로 인 박스 대 갤러리 전용 호출을 할 수 있습니다.

https://github.com/PowerShell/platyPS에 Yaml이

예, 이것이 있으면 좋을 것입니다. https://github.com/awslabs/aws-cfn-template-flip 을 사용하여 변환했습니다.

@MattTunny 기여를 환영합니다! :-)

그것에 투표하기 위해 열린 Windows Server 사용자 목소리가 있습니다 :-)

https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11088495-out-of-the-box-support-for-yaml-like-csv-xml-j

이것은 확실히 네이티브 PS 6.1 라이브러리의 일부 여야합니다. 요즘 YAML에는 많은 것들이 있습니다.

이제 PSGallery에 psyaml 및 powershell-yaml 모듈이 있지만 둘 다 VSTS 빌드 정의에서 YAML 파일을 왕복 할 수도 없습니다. 모듈이 PowerShell에 구워 졌는지 아니면 PSGallery의 모듈인지 상관 없습니다.

여기서 핵심 문제는 모듈을 배포하는 투박한 방법인지 궁금합니다. 오늘날 모듈을 사용하려면 먼저 모듈을 찾고, 신뢰하고, 설치해야합니다. 이것을 Javascript가 var m = require('mymodule') 하는 (분명히) 매끄러운 방식과 비교하십시오. DSC가 수행하는 작업을 수행 할 수있는 방법이 있지만 기본 PowerShell을 사용해야 할 수도 있습니다. DSC에서 모듈이 구성에서 참조되면 수동 작업없이 대상 노드에 자동으로 다운로드되고 설치됩니다. 중요하지만 핵심이 아닌 모듈을 이러한 방식으로 사용 가능하게하면 "핵심의 일부가되어야합니다"라는 주장을 제거해야합니다. 그리고 네트워크에서 연결이 끊어진 노드의 경우 스크립트의 종속성을 아카이브에 번들로 묶은 다음 대상에 배포하는 도구를 사용할 수 있습니다. 이것이 Azure DSC 리소스 확장이 작동하는 방식입니다. 스크립트를 스캔하여 필요한 모듈을 파악한 다음 필요한 모든 것이 포함 된 zip 파일을 빌드하고이를 Blob에 게시하는 도구가 있습니다. 그런 다음 Azure 리소스 확장은이 Blob을 가져와 모듈을 설치하고 스크립트를 실행합니다.

이처럼 중요한 것에 대해 벤더 링 방법이없는 한 타사 라이브러리에 의존하고 싶지는 않습니다. 타사 개발자가 전체 생태계를 잠재적으로 파괴하는 것은 너무 쉽습니다 (https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ 참조).

@bergmeister가 지적했듯이 더 광범위한 문제를 제외하고는 현재 PowerShell 용 좋은 YAML 모듈이 없습니다. 이것은 자동화에 중점을 둔 언어의 필수 사항입니다. YAML 기반 구성 파일은 현재 매우 인기가 있으며 그렇게하기 위해 팀의 의견과 경쟁 할 필요가 없더라도 피하는 것이 매우 어렵습니다. XML과 JSON을 언어의 핵심 부분으로 포함하는 이유를 생각해보십시오. YAML의 경우는 실제로 그렇게 다르지 않습니다.

@bgshacklett 내가 꼭두각시 녀석들로부터들은

platyPS 파서가 충분합니까?

@vors PowerShell Core repo에서 platyPS YAML 파서를 재사용하는 간단한 방법이 있습니까?

@lzybkr 과 같은 PowerShell 갤러리의 별도 공식 모듈 아이디어를 선호합니다. 이전 powershell 버전에서 사용할 수 있고 자체 릴리스를 가질 수 있기 때문입니다. 그것은 sqlserver 모듈과 같습니다. @BrucePay 가 Microsoft 자체 모듈이있는 PowerShell Gallery의 페이지라면 찾기가 더 쉬울 것이며 모두가 신뢰할 수 있다는 것을 알 것입니다.

그러나 XML 및 JSON으로 Powershell에 백업되었는지 이해합니다.

중요한 것은 ConvertFrom-YAML 및 ConvertFrom-YAML 공식 함수가 존재한다는 것입니다. YAML은 구성 파일에 널리 사용되는 형식이고 @bgshacklett이 지적한 것처럼 타사 모듈이

블로그 항목을 테스트하고 YAML 파일에서 작동하는 것으로 확인 된 두 모듈 인 PSYaml 및 powershell-yaml을 비교했습니다 .

내부적으로 다른 개체를 사용하기 때문에 다른 동작이 있습니다.

| 모듈 | 매핑 | 시퀀스 |
| --------- | : -------------- | ----------- |
| PSYaml | OrderedDictionary | 어레이 |
| powershell-yaml | Hastable | 목록 |

표준 ConvertFrom-YAML 및 ConvertFrom-YAML 가 필요하다고 생각합니다.

실제로, ConvertFrom-Yaml 에서 powershell-yaml 용도 OrderedDictionary 로 변환 할 때 -ordered 파라미터.
이 모듈을 잠시 동안 성공적으로 사용했지만 (DSC 구성 데이터 용 Datum 모듈 및 주방 yamls에서) 테스트 할 vsts 빌드 정의가 없습니다.

그것을 부르는 올바른 방법은 다음과 같습니다 : get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered (사람들은 종종 -Raw 놓칩니다).

Microsoft _official_ 모듈이 필요한 이유가 궁금합니다. MSFT에 더 많은 오버 헤드를 추가하고 휠을 다시 발명하는 것입니다. 문제는 더 나은 접근 방식입니다 ...
99 개의 기존 구현 중에서 표준을 만들려고 할 때 어떤 일이 발생하는지 알고 있습니다.

그리고 예, 언어 밖에서 더 좋을 것입니다. 종속성 관리가 더 좋을 수 있다는 데 동의합니다. 모든 것을 PS에 번들로 묶는 것은 해결책이 아닙니다.
광범위한 npm 문제는 프로세스의 실패이기도합니다. Fork 및 re-publish는 즉시 문제를 해결했습니다. 최신 버전의 인터넷에서 앱을 빌드하는 것이 많은 라이브 앱을 망가 뜨린 이유였습니다.

@gaelcolas에 동의합니다. 품질을 높이고 보장하기 위해 기존 커뮤니티 모듈의 소유자와 함께 작업하는 모든 사람에게 이것이 더 낫다고 생각합니다.

이러한 프로젝트에 대한 테스트에는 AppVeyor, Travis CI, VSTS, AWS CloudFormation 등과 같은 많은 실제 YAML 파일 작업이 포함되어야한다는 점을 추가하겠습니다. YAML deserilization에 대한 저의 경험을 위해 저는 하나의 솔루션이 보편적으로 작동하는 데는 거의 성공하지 못했고 궁극적으로 휠을 여러 번 재발 명해야했습니다. 그런 의미에서 저는 @BrucePay "좋은 YAML 파서가 없습니다"에 동의합니다.

이 platyPS 모듈은 이미 PowerShell 도움말 환경에서 활발하게 사용되고 있기 때문에 이야기하고 있습니다. 나는 MSFT에서 아무도이 모듈이 행동 강령 때문에 얼마나 좋은지 말할 수 없다고 생각한다. 그들은 조용히 그것을 거부하거나 개선 할 수 있습니다.
그리고 우리가 이것에 대해 오래 전에 이야기 해 왔지만 여기서이 모듈의 구성 요소를 간단한 방법으로 사용할 수있는 방법을 알 수 없습니다.
아마도 @adityapatwardhan 과 @ SteveL-MSFT는 특히 새로운 Help RFC가 이미 실험 단계에 있기 때문에 계획과 타임 라인을 열 것입니다.

제 개인적인 견해는 Msft의 "공식"모듈을 요구하는 것보다 더 많은 커뮤니티 모듈이 성공하고 사실상의 표준이되는 것을 바라는 것입니다.

@iSazonov 잘 정의 된 스키마를 직렬화 / 역 직렬화하는 솔루션을 갖는 것은 한 가지입니다. YAML을 준수하는 모든 스키마에서 일반적으로 작동하는 솔루션을 갖는 것은 또 다른 일입니다.

비용을 절감하기 위해 커뮤니티 프로젝트를 재사용하려는 MSFT의 바람을 이해합니다. 그러나 실제로 MSFT는 많은 커뮤니티 프로젝트를 사용하지 않을 수 있습니다.

• 많은 사람들이 나쁜 코드를 가지고 있고, 신뢰가 없습니다.
• 많은 프로젝트가 한 사람입니다

MSFT는 10 년 전에 Powershell 사양을 게시했지만 MSFT가 적용되기 전까지는 아무도이를 포팅하지 않았습니다.
OpenSSL 프로젝트는 수년 동안 존재 해 왔지만 MSFT는이를 수행하지 않은 동안 아무도 Windows로 이식하지 않았습니다.
MSFT는 수천 개의 API 인터페이스를 공개했지만 그중 몇 개가 Unix로 포팅 되었습니까?
회사가 Mono를 재사용하는 대신 .Net Core 프로젝트를 시작한 이유에 대한 흥미로운 점은 무엇입니까?
PowerShell은 이미 1 년 반이 오픈 소스 프로젝트이지만이 저장소에서는 커뮤니티의 한 사람 만 @markekraus 코드에 체계적으로 기여하고 한 사람 만 @ mklement0에서 체계적인 분석을 수행합니다.
프로젝트를 여러 부분으로 나누면 더 많은 기여를 할 수 있다고 생각하지 않습니다.
내일 상황이 바뀔 것이라고 생각하지 않습니다. 나는 그것을 믿지 않을 것입니다.

@markekraus 나는 http://yaml.org/spec/1.2/spec.html#id2802346에서 매우 희망합니다 :-)

@iSazonov 는 타사 모듈의 지원, 신뢰 및 유지 관리에 대한 중요한 사항을 제시합니다. 일부 타사 모듈은 Pester와 같이 성공하고 성숙해질 수 있습니다.
그러나 훌륭한 YAML 모듈이 향후 몇 년 동안 자체적으로 발전 할 것이라고 가정해서는 안됩니다. 현실은 대부분의 모듈이 특정 문제를 해결하고 일반적인 기본 코드를 게시하는 데 성공한 작성자에 의해 게시된다는 것입니다. 이것이 우리가 같은 문제를 해결하는 것을 목표로하는 2 개의 모듈로 끝낸 방법입니다. 이상적으로는 이들을 병합하여 노력에 집중해야합니다. 그렇지 않으면 미래에 더 멀어 지거나 부실 해져 곧 다른 사람들이 더 많은 모듈을 게시하게 될 것입니다.
적절한 파서를 갖는 근본적인 문제는 기본 (그리고 노력 측면에서 상당한) 기초 작업이 필요하고 좋은 YAML 모듈을 갖기 위해 필요함을 나타냅니다.
나는 YAML 전문가는 아니지만 이것은 느슨한 언어 사양 자체 또는 VSTS 또는 AppVeyor와 같은 다양한 시스템의 특정 해석의 문제입니까, 아니면 좋은 파서가 부족한 것일까 요?
VSCode에서 YAML을 작성하고 VSTS에서 실행할 때만 VSTS 파서가 좋아하지 않는다는 오류가 발생하는 것이 실망 스러웠습니다.

나에게이 대화는 오픈 소스의 "코드 큐 레이션 / 아키텍처"문제와 관련이 있습니다.

오픈 소스는 좋은 시드 아이디어와 코드 기반을 제공합니다. 그러나 가장 일반적인 솔루션으로 채택되었을 때 심각한 아키텍처 안목이 주어지지 않으면 적절한 설계 검토에서 처리 할 수있는 항목에 대한 10 년의 버그 수정입니다. .

@bergmeister "성숙한 성공"의 실제 사례에서는 코드베이스를 일반화하는 임무를 맡은 적극적인 관리자가되는 경우가 많습니다. 하지만 그렇게 보장 할 수는 없습니다.

우리 중 일부는 "YAML 지원은 파일 작성에 대한 지원과 같습니다. 핵심입니다. 동일한 방식으로 설계해야합니다 => 해당 기능에 대한 표준이 되려는 의도로해야합니다."

1) 오픈 소스의 반 아키텍처 속성과 2) Microsoft PowerShell 개발자가 작업에 적용하는 고도로 설계된 접근 방식을 촉구하는 YAML의 핵심 특성의 조합입니다. 오픈 소스가 실제로 우리에게 도움이 될 수있는 다른 모든 멋진 것에서 벗어나는 것이 반드시 필요한 것은 아닙니다.

소프트웨어 성숙도에 대한 매우 유효한 포인트. 나는 여기에 나열된 두 모듈을 면밀히 살펴 보지 않았고 어떤 의견도 제시하기 위해 yamldotnet을 보지 않았습니다. 6.2.0에 대한 계획을 시작할 때 살펴볼 수있는 것

오해하지 마세요. 저는 PowerShell 팀과 MSFT 개발자의 경험과 체계적인 접근 방식을 소중하게 생각합니다. 자신의 스탬프가 찍힌 MSFT의 모듈로 모든 격차를 메우려는 것이 잘못이라고 생각합니다. (그리고 우리는 이미 DSC 리소스의 문제를 보았습니다).
MSFT 제공 모듈에 대한 의존도를 높이는 것은 취약하며 커뮤니티 성장이나 생태계의 다양성에 도움이되지 않습니다.
나는 MSFT가 오픈 소스 프로젝트에 기여하여 그들의 경험을 공유하고 관행과 품질을 향상시키는 한편 그들에 대한 의존성을 만들지 않는 것에 찬성합니다 (왜냐하면 다람쥐 ...!).
승인 된 것의 고유 한 공급자로서의 _MSFT_는 이미 교육에 어려움을 겪고있는 오래된 모델이며 커뮤니티가이 접근 방식을 장려하는 데 도움이되지 않습니다. OSS 생태계의 태도).

PS 팀이 처음부터 다시 작성하는 대신 YAML 지원이 핵심이라는 데 동의합니다. 기존 프로젝트 관리자가 개선하도록 돕고 프로젝트를 병합하고 어떤 작업이 필요한지들을 수있는 기회를 제공합니다. 핵심 기능 모듈에 대한 PS 팀의 견습 / 멘토십과 비슷합니다.
새 모듈을 다시 작성하는 것만으로도 엔지니어링 문제가 아닌 문제를 해결하려는 엔지니어의 반응처럼 들립니다. YAML 모듈을 다시 작성하는 것은 PS 팀의 _ 쉬운 엔지니어링 작업이지만 커뮤니티 성숙도 문제를 해결하거나 적절한 인센티브를 제공하지는 않습니다.
Yaml이이 문제를 해결하기위한 전략적 항목인지 여부는 MSFT의 요청입니다. :)

뿡 빵뀨

나는 YAML 전문가가 아닌 자신으로 이것을 서두에 둘 것입니다. yaml 구성과 같은 AppVeyor를 내 franken-pipeline에 굽고 싶을 때 이에 대한 연구를 수행했습니다. 수십 개의 C # 프로젝트가 YAML을 어떻게 사용하는지 살펴 보았습니다. PowerShell 프로젝트는 YamlDotNet을 사용하기 때문에 이것이 쉽지 않다고 가정 할 수 있습니다. 나는 적어도 PSYaml과 powershell-yaml을 가지고 놀았고 그것들을 사용하는 몇 가지 PowerShell 프로젝트를 덜 면밀히 살펴 보았습니다.

나는 YAML 전문가는 아니지만 이것은 느슨한 언어 사양 자체 또는 VSTS 또는 AppVeyor와 같은 다양한 시스템의 특정 해석의 문제입니까, 아니면 좋은 파서가 부족한 것일까 요?

나는 기계가 더 쉽게 읽을 수있는 가능성을 희생하면서 인간이 읽을 수있는 YAML의 본질이라고 생각한다. 이 가독성 우선 패러다임은 YAML 작성자가 YAML 파일을 작성하는 방식으로 확장됩니다. 결과 YAML은 YAML 사양에 따라 호환되지만 실제로 유용한 개체에 대한 중개자로서 역 직렬화 된 개체를 사용하지 않고 코드에서 사용할 수 없도록 파싱됩니다.

즉, YAML에서 객체로의 역 직렬화의 90 %는 문제가 아니지만 데이터 디자인 / 아키텍처가 문제입니다. 나머지 10 %는 "YAML은 파싱하기 어렵습니다."라고 생각할 수있는 파싱 문제입니다. 그러나 deserialized 객체는 찾고있는 것을 정규화하는 것보다 약간 더 유용합니다 ....

예를 들어 AppVeyor.yml의 보안 문자열은

environment:
  my_var1: value1
  my_var2: value2
  my_secure_var1:
    secure: FW3tJ3fMncxvs58/ifSP7w==

powershell-yaml 및 YamlDotNet 는 이것을 객체로 변환하지만, 많은 논리없이 사용할 수 있습니다. 일단 그 논리가 있으면이 스키마에 적합하지만 다른 논리는 어떻습니까?

이러한 동일한 데이터 디자인 문제 중 일부는 JSON을 괴롭히지 만 JSON의 더 엄격한 특성으로 인해 이러한 단점을 해결할 수있는 모델을 만드는 것이 훨씬 쉽습니다. 이 스레드에서 언급 된 YAML 디시리얼라이저에 대한 모델을 만드는 것은 가능하다면 악몽입니다.

물론, 모델은 현재 JSON cmdlet에서 사용할 수있는 기능이 아니지만 실제로 추가하고 싶습니다. "공식적인"YAML 모듈 / cmdlet에 대한 발언이 있으면 "필수"기능으로 내려 놓을 것입니다. 특히 v5에 PowerShell 클래스가 추가되면서 놓친 기회입니다.

IMO, YAML 문자열을 객체로 가져 오는 것만으로는 충분하지 않습니다. 그것은 쉬운 것처럼 보인다 (적어도 90 %의 시간). 트릭은 YAML 문자열을 _useful_ 객체로 가져 오는 것입니다. 이를 위해서는 솔루션의 유연성이 필요합니다. 그러나 그 유연성은 다소 접근 가능해야하며 직렬화 조언을 제공하기 위해 @IISResetMe 및 @lzybkr 이 필요하지 않아야합니다 ....

그 효과를 위해 일반적인 범위에서 작동하는 것을 보지 못했습니다. 프로젝트는 사용 가능한 솔루션을 채택하고 그 결과물을 실제로 유용한 개체에 대한 중개자로 사용합니다 (업스트림에서 구워 져야하는 휠 재창조로 이어짐). 또는 프로젝트는 YAML에서 객체로 쉽게 구문 분석하기 위해 YAML 가독성을 손상시킵니다.

뿡 빵뀨

PS 팀이 처음부터 다시 작성하는 대신 YAML 지원이 핵심이라는 데 동의합니다. 기존 프로젝트 관리자가 개선 할 수 있도록 돕고 프로젝트를 병합 할 수있는 기회를 제공하고 필요한 사항을

MSFT가 몇 년 후 Mono를 계속하는 대신 .Net Core 프로젝트를 시작한 이유를 자문 해보십시오.

MSFT도 커뮤니티입니다. 그리고 모든 커뮤니티는 다른 커뮤니티와의 상호 작용에 대해 동일한 문제를 가지고 있습니다.

문맥 상, 나는 어떤 작업이 처음부터 수행된다는 것을 암시하는 것이 아니라 코드를 채택 할 수 있지만 개선되기 전에 시스템 개발 아키텍처 관점에서 면밀히 조사되어야합니다. 검토 및 재 출시 후 오픈 소스가 될 수도 있습니다.

제 요점은 거의 모든 곳에서 활용 될 핵심 코드의 뉘앙스를 철저히 이해하는 팀으로부터 중요한 아키텍처 검토 및 수정을받는 것입니다.

항상 고려할 가치가있는 또 다른 모델은 매입 / 계약 / 초입니다. 이를 기반으로 한 명 이상의 커뮤니티 구성원 / 회사와 상업적 조건에 도달하여 MSFT 주도 / 촉진 된 개발주기에 대한 서비스를 모집하여 제품을 (일부 방식으로) 통합 / 연결합니다. . 이것은 Net Foundation에 프로젝트를 시작하고 MIT에서 라이센스를 부여하고 Xamarin을 통해 Miguel de Icaza 및 Nat Friedman과 같은 주요 리소스를 모집 / 계약 / 관련시킨 Xamarin과 함께 성공적으로 수행되었습니다. 일부는 이것이 오픈 소스 반역이라고 우는 소리를냅니다. 그러나 이는 사람들과 소규모 기업이 나중에 하나 이상의 주요 생태계에 광범위하게 채택하고 통합하는 데 적합 할 수있는 프로젝트를 구상하고 개발하는 데 긍정적 인 인센티브를 제공합니다. 전체 개념과 기능과 많은 아이디어를 복사하지만 제작자와 (표면적으로) 코드를 버리는 빈 사내 다시 실행으로 바로 이동하는 것이 좋습니다.

@iSazonov 늦게 답장을 드려 죄송합니다. platyPS yaml 파서는 좋지 않습니다. 키 값 쌍만 지원합니다. 또한 YamlDotNet을 사용하여 yaml을 생성합니다.

이를 핵심 기능 세트에서 제외하려는 감정과 관련하여, Ruby, Python 또는 Node.js와 비교하여 PowerShell이 ​​종속성을 처리하는 방법에는 매우 중요한 차이가 있습니다.

이러한 각 언어에는 종속성 관리 도구 (번 들러, pip, npm / yarn)가있어 외부 종속성 관리를 쉽고, 무엇보다 재현 가능하게 만듭니다. Gemfile/Gemfile.lock 또는 package.json/package-lock.json [,yarn.lock] 와 같은 것을 사용하면 필요한 모든 패키지를 쉽게 설치할 수 있고 매우 특정한 패치 수준을 유지할 수 있다는 것은 제 생각에는 매우 중요한 차이점입니다. 이 근본적인 것을 실현할 수있는 타사 라이브러리를 만드는 이유.

이 문제를 해결하기 위해 Nuget으로 수행 할 수있는 작업이있을 수 있지만 PowerShell에 대한 종속성 관리 전략 / 패턴을 설명하는 기사는 본 적이 없습니다. 갤러리를 갖는 것은 훌륭하지만 필요한 모든 패키지를 수동으로 설치해야하는 경우 중요한 배포를 수행 할 수 없게됩니다.

편집하다:
그래서 내가 _may_를 찾고있는 것 같습니다 : https://docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduledependency. 잠시 시간을내어 테스트하겠습니다. 그것이 효과가 있다면, 이것이 핵심 항목이어야하는지 아닌지에 대한 내 입장을 재고해야 할 것입니다. 저는 여전히 JSON이 핵심 기능이라는 사실과 조화를 이루는 데 어려움을 겪고 있지만 "가장 낮은 공통 분모"로 간주 될 수 있다고 생각합니다.

@bgshacklett 은 매우 좋은 지적입니다.

@ chuanjiao10- 이 리포지토리의 많은 문제에서 방해가되는 댓글을 중지하세요. 올바른 해결책은 Microsoft.PowerShell.Utility 모듈에 포함 하지 않고 실제로 PowerShellGallery에서 호스팅되는 별도의 모듈로 배송하는 것입니다.

기본적으로 말할 때 XML 또는 JSON과 같은 의미입니까?

현재 생각하고있는 것은 YAML이 PowerShell에 전혀 구워 지지 않아야한다는 것입니다. 대신 새 버전의 PowerShell을 선택하지 않고도 업데이트 할 수있는 별도의 모듈이어야합니다.

YAML이 XML과 같은 PowerShell로 구워 졌다면 불가능합니다 ([xml] "b"를 생각해보십시오).

JSON 경로를 사용했다면 YAML과 함께 작동하는 cmdlet이있을 것입니다. 따라서 실제로 PowerShell에 구워진 것은 아니지만 YAML 업데이트를 받기 위해 PowerShell을 업데이트해야하는 단점이 있습니다.

개인적으로 이것은받은 편지함에 "올바른"것처럼 느껴지지만 실제로는 옳은 일이 아니라고 제안합니다.

@lzybkr 우리가 새 라이브러리를 가져오고 싶지 않다고 말한 것을 알고 있지만 이것이 재평가가 필요할 수 있다고 생각합니다. 이상적으로는 갤러리에서 모듈을 _ 또한 _ 배송해야하지만 현대 시나리오의 톤이 지금 YAML을 필요로한다고 생각합니다.

6.0 시간대가 아닐 수도 있지만 이에 대해 이야기해야합니다.

사용 하위하고 IMO가 가능한 고품질에 도착하는이 작업을 수행하는 덜 PowerShell에서의 팀 작업과 PowerShell을 팀의 도움으로이 드라이브에 더 많은 지역 사회의 수와 같은 외부 모듈을 배송하는 것은 훨씬 더 내보기입니다.

다시 @ chuanjiao10 이전에는 # 2109의 PowerShell Core에 YAML Cmdlet을 넣지 않기로 결정 꺼야 하므로 그 당시에는 올바르게 거부되었습니다.

...에 관해서

단결은 힘입니다. 자동차가 필요한 미국인, 그가 월마트에 가서 바퀴를 사고 아마존에 가서 엔진을 사고 자신을 합치는 것을 본 적이 있습니까?

자동차를 소프트웨어와 비교하는 것은 자동차의 구성 요소가 다양한 공급 업체에서 제공 한 다음 사용 가능한 제품으로 패키징된다는 점을 고려할 때 다소 잘못된 비유입니다. 이는 커뮤니티에서 개발 한 PowerShell 모듈과 다르지 않습니다. 스크립트에 사용

이 점에 대해

기본 라이브러리가 내장되어 있으며 이것은 매우 중요합니다. 그렇지 않으면 convertfrom-json, convertto-json 등도 PowerShellGallery에 배치해야합니다.

나는 # 1979에 따라 가능한 한 많은 내장 모듈에 대해 이것을 옹호했으며 # 5681에서 더 논의하기 시작한 PowerShell Core가 가능한 한 간결하다는 것을보고 싶습니다.

그리고 다시

YAML을 차별하지 말고 JSON을 칭찬하지 마십시오.

나는 둘 다 결함이 있지만 둘 다 사용이 있고 PowerShell에서 Json cmdlet을 제공하지 않는 데 영향을 미칠 수 있었다면 여기에서 수행하는 것과 똑같은 작업을 수행했기 때문에 Yaml을 차별하거나 Json을 아첨하지 않습니다.

이 토론을 약간 재구성하는 것이 도움이 될 것이라고 생각합니다. 특히 핵심 언어에 포함 된 YAML을 선호하는 사람들은 특정 사용 사례를 나열하고 PowerShell 갤러리의 모듈이 언급 된 사용 사례를 해결하는 데 충분하지 않은 이유를 나열 할 것입니까? 이 시점에서 우리는 요구 사항 중심의 토론을 할 수 있으며 잠재적으로 당면한 문제에 대한 실행 가능한 솔루션을 찾을 수 있습니다.

저의 주요 사용 사례는 운영 체제와 애플리케이션 배포 모두의 베어 메탈 자동화입니다. 적어도 하나의 경우 매개 변수를 이해하기 위해 스크립트를 호출 한 YAML 파일을 읽고 싶습니다.
종종 이러한 경우에 외부에 대한 종속성이 있고 SLA가 적용되지 않은 서비스는 절대 안됩니다. 프로덕션 확장 활동에 영향을 미칠 수 있습니다.

이것이 powershell 코어의 가장 기본적인 풋 프린트를 배송하기위한 사용 사례입니다.

활발한 토론에 감사드립니다. 예의를 갖추도록 노력하겠습니다. :)

@ PowerShell / powershell-committee는 이전에 이것을 논의했습니다. 우리는 YAML이 오늘날 얼마나 널리 퍼져 있는지를 고려할 때 YAML을 지원하는 것이 중요하다는 데 동의합니다. 또한 현재 PSCore6에서 제공하는 더 많은 모듈이 제거되어 PSCore6의 최소 설치로 시작한 다음 필요한 것을 추가하기를 원합니다 (메타 모듈을 사용하면 10 개 이상의 모듈을 추가 할 필요가 없으며 DevOps 하나만 추가 할 수 있음). 예를 들어

YAML 지원은 팀이 6.2 릴리스 이후를 살펴 보길 바라는 것입니다.

@ SteveL-MSFT 문제 및 https://github.com/dotnet/corefx/issues/34578 에 따라 의견을 보내 주

in. 내 의견은 convertfrom-json, convertfrom-jaml이 동일한 상태로 이동하거나 내장되어 있다는 것입니다.

저는 JSON cmdlet을 프로젝트 밖으로 옮겨야한다고 주장 해 왔습니다. 많은 사람들이 상당히 큰 변화를 원하지만 cmdlet이 PowerShell에 연결되어 있기 때문에 변경할 수 없습니다. 이를 프로젝트 외부로 이동하면 cmdlet 모듈의 새로운 주 버전에서 주요 변경 사항을 적용 할 수 있으며 PowerShell을 이전 버전과 함께 제공하여 이전 버전과의 호환성을 제공하지만 원하는 경우 사용자가 업데이트 할 수 있습니다. 이와 같은 외부 모듈 인 IMO를 포함하는 것은 매우 번거 롭습니다.

YAML을 같은 방식으로 임의로 취급하는 것보다 JSON과 Pester의 실수로부터 배우고 싶습니다. 확실히 PowerShell의 핵심 기능의 일부가 아니어야하지만 커뮤니티와 PS 팀간에 소유권을 공유하는 공식적으로 지원되는 일종의 모듈이 있어야합니다.

나는 그 생각을 좋아한다. JSON Cmdlet을 제거하면 현재 외부 모듈에 대한 엄격한 종속성으로 존재하는 워크 플로 문제를 파악하는 데 도움이됩니다.

그러나 yaml은 시스템 관리자, 스크립트 개발자에게 중요합니다. 이러한 사용자에게는 yaml 명령이 필요합니다.

그들은 그들을 필요로 할 수 있지만 외부 모듈 이상 허용 및 핵심 저장소에 번들로 무엇보다 더 유연한 지원 기간을 가지고 그들이 직접 PowerShell을 내에 포함해야한다는 것을 의미하지 않습니다.

저는 DevOps 메타 모듈에 대한 @ SteveL-MSFT 아이디어가 장기적으로이를위한 올바른 방법이라고 말해야합니다. 이것은 다른 사용자 세트가 훨씬 더 쉽게 관리 할 수있는 더 간단한 패키지 세트를 얻을 수 있도록하기 때문입니다. 내부 의존성보다 외부 의존성으로, 앞으로 나에게 많은 의미가 있지만, 기술 스택을 기반으로하는 메타 모듈이어야합니다. 왜냐하면 제가 Windows에 있고 anisble을 사용하지 않는다면 왜 yaml cmdlet이 필요할까요? 창문?

@ chuanjiao10에서 언급 한대로 yml을 사용하는 Linux 세계에는 많은 사용자가 있지만 Windows 세계에서는 그렇지 않습니다. 전체 PowerShell 사용에 대한 이해로 볼 때 여전히 대부분의 PowerShell 5.1은 시스템에 들어 있으므로 PowerShell 5.1을 사용합니다. , Yaml cmdlet을 번들로 제공하는 동안 Linux 사용자에게 도움이 될 수 있지만 Windows 사용자를위한 불필요한 추가 번들 항목처럼 느껴지지만 두 사용자 집합을 동일하게 처리하려면 두 사용자 집합이 모두 외부 모듈이된다는 것이 가장 좋습니다. 필요에 따라 활용할 수 있습니다

소유자가되어 별도의 프로젝트에서 이러한 cmdlet을 함께 사용하려는 사람이 있습니까?

@iSazonov corefx는 현재 내장 YAML 지원에 관심이없는 것 같습니다. YamlDotNet은 가장 인기있는 라이브러리 인 것 같고, MIT 라이센스가 있고 적극적으로 유지 관리되므로 거기서 시작하겠습니다. 커뮤니티 주도 프로젝트는 훌륭 할 것이며 PowerShell 팀에 맡기는 것보다 더 빨리 일어날 것입니다.

- @ SteveL - MSFT 좋은 이유에 대한 이잖아 보인다 https://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255 I는이 특정 라이브러리에 대한 신뢰를 낮춘 것으로 기대합니다.

corefx는 현재 내장 YAML 지원에 관심이없는 것 같습니다.

CoreFX 팀은 사용 사례에 대해 질문합니다. PowerShell 프로젝트에서 API가 필요하다고 말하면 API 추가를 고려할 것입니다.

커뮤니티 주도 프로젝트는 훌륭 할 것이며 PowerShell 팀에 맡기는 것보다 더 빨리 일어날 것입니다.

오, 그런 프로젝트는 단 하나뿐입니다-Pester. 그리고 저는 yaml 커뮤니티 주도 프로젝트를 믿지 않습니다. 왜 지난 몇 년 동안 나타나지 않았습니까?
프로젝트를 시작하려고했지만 MSFT가 요구하는 코드의 품질, 규정 준수 및 보안 수준에 도달 할 수 없다는 사실이 저를 막았습니다.
보안 감사 없이는 MSFT가 프로젝트를 신뢰하고 사용할 수 없을 것 같습니다.
나는 그것을 작동시킬 아이디어가 하나뿐입니다. CoreFX 및 PowerShell과 같은 MSFT GitHub 프로젝트는 "MSFT가 소유"하고 "MSFT가 주도"합니다. 새 프로젝트 유형은 "MSFT 소유", "커뮤니티 주도"및 "MSFT가 멘토링"할 수 있습니다. '멘토링'이란 프로젝트가 신뢰할 수 있고 품질이 높은 환경의 구현을 의미합니다.

Microsoft는 PowerShell Core에 대한 YAML 지원 기본 제공을 번들로 제공해야합니다. 단순하고 단순합니다.

@brettjacobson 예, 단순하고 단순하며 고품질이지만 MSFT 팀에는 리소스가 많지 않습니다. 기여할 준비가 되셨습니까? :-)

@brettjacobson -Microsoft는 YAML 지원을 번들로 제공 할 필요가 없습니다. 그렇게했다면 유용 할 수 있지만 그렇게 할 필요가없고 그렇게 할 필요도 전혀 없습니다.

이것은 많은 want 대한 기능 요청이며 궁극적으로 use 되지만 중요한 need 는 아니므로 @ SteveL-MSFT와 정확히 일치하는 우선 순위를 얻을 가능성이 _ 불가능합니다 _ 그가 다음과 같이 말했을 때

YAML 지원은 팀이 6.2 릴리스 이후를 살펴 보길 바라는 것입니다.

커뮤니티 주도 프로젝트는 훌륭 할 것이며 PowerShell 팀에 맡기는 것보다 더 빨리 일어날 것입니다.

PowerShell 팀은 규모가 크지 않으므로 YAML에 대한 지원을받을 수있는 가장 빠르고 가장 빠른 방법은 제품 자체에 적용되는 것이 아니라 PowerShell의 핵심 기능 집합 외부에있을 것입니다.

CoreFX 팀은 사용 사례에 대해 질문합니다. PowerShell 프로젝트에서 API가 필요하다고 말하면 API 추가를 고려할 것입니다.

@iSazonov IMHO는 아직 완전한 JSON 지원이 없기 때문에 CoreFX에 내장 된 YAML 지원이 없을 것입니다.

"훌륭한"타사 라이브러리를 기다리거나 James Newton-King에게 Newtonsoft.Yaml 하시겠습니까? :-)

@NextTurn .Net Core 3.0에서 새로운 Json (매우 빠르며 (Newton.Json보다 빠르며) 매우 유연함) 구현을 얻을 것입니다.
CoreFX 팀은 커뮤니티의 큰 요청이 있으면 항상 새로운 API를 추가합니다. YAML의 혜택을받을 수있는 프로젝트가 많으면 추가 할 것입니다. 현재 그러한 요청은 없습니다.

새로운 pwsh 시스템마다 무엇을하지 않습니까? 나는 Install-Module -Name powershell-yaml 합니다.

Mongo, Kubernetes, Istio, Ansible, 이름을 지정합니다. 이 모든 것이 YAML이며 YAML 템플릿과 변환이 있습니다. pwsh 은 DevOps에 적합하며 YAML을 사용합니다.

@ dzmitry-lahoda Issue # 5681은 Pester 등과 같은 공통 모듈 세트와 함께 제공되는 '풍부한'버전의 PowerShell을 제안합니다.이 문제에 게시 해주세요. 현재 사용 가능한 2 개의 yaml 모듈 사이에서 분명한 승자이며 서로를 방해하고 있습니다. 좋아하는 것을 선택하는 것은 어려운 결정일 수 있습니다.

YAML이 하나만 표시됩니다.

Pester , 예. pwsh 컨테이너 애플리케이션 용 YAML 리더와 달리 BDD 프레임 워크를 메인 라인으로 제공하기에는 너무 무겁습니다.

이 스레드가 끝났습니까? Microsoft에서 사용할 권장 (또는 제안) 모듈은 무엇입니까?
DevOps 파이프 라인은 yaml을 사용합니다. 모든 배포 자동화는 powershell로 빌드됩니다. yaml과 powershell이 ​​잘 작동하지 않는 것 같습니다. Powershell은 Azure DevOps 자동화에 적합하지 않나요?
내 미래의 사용 / 혁신에 대해 신중하게 생각할 필요가 있으며 어떤 방향을 고맙게 생각합니다.
미리 감사드립니다!

@dirkslab https://github.com/cloudbase/powershell-yaml을 사용할 수 있습니다.

GitHub

cloudbase / powershell-yaml

YAML 형식 조작을위한 PowerShell CmdLets. GitHub에서 계정을 만들어 cloudbase / powershell-yaml 개발에 기여하세요.

감사합니다 @iSazonov , 그것이 제가 현재 테스트하고있는 솔루션입니다. 지금까지의 해결책은 잘 작동하는 것 같습니다. 솔루션을 사용하는 데 아무런 문제가 없을 것입니다.

powershell-yaml을 사용하면 신뢰할 수없는 모듈을 확인해야합니다. 이것이 제가 이해하기 위해 싸우고있는 부분입니다. Microsoft는 yaml 파이프 라인 사용을 권장합니다. Microsoft (또는 적어도이 스레드)는 yaml 구성을 powershell과 통합 할 수 있도록 타사 모듈을 사용하는 것이 좋지만 보증하거나 권장하지 않습니다. 그것을 기업에 논리적으로 어떻게 설명합니까?
지금까지 내 경험은 항상 Microsoft가 보증하는 솔루션을 사용하지 않으면 솔루션 문제에 대한 Microsoft의 지원이나 이해가 음소거된다는 것입니다 (지원되지 않는 부품이 문제를 일으키는 모든 부분에 닿더라도 문제가되지 않음). 지원되지 않는 부품이 있다는 단순한 사실만으로는 일반적으로 지원 / 책임이 없습니다.
이 오픈 소스 시대에 상황이 바뀌었을 수도 있습니다. Microsoft의 간단한 공식 응답과 안내는 나를 편안하게하고 이해하는 데 도움이 될 것입니다.

귀하의 답변에 감사드립니다. 문안 인사.

@dirkslab 귀하의 MSFT 계정 관리자가 지원 정책에 대해 물어볼 수있는

CoreFX 팀이 사용 사례에 대해 묻습니다.

Yaml이 오늘날 CI / CD 및 구성 시스템 수에서 우리 주변에 있다는 명백한 이점을 활용하여 ConvertTo-Yaml의 추가 이점은 지금 사용해야하는 ConvertTo-Json 와 달리 사람이 읽을 수있는 형식으로 nasted HashTable을 나타냅니다. 출력을 읽을 수 없게 만듭니다.

그동안 Write-HashTable 을 사용하지만 OTB가 있으면 좋을 것입니다.

나는 yaml을 싫어한다. 나는 그것을 정말로 싫어한다. 그러나 MS 팀이 고려할 가치가있는 몇 가지 측면이 있습니다.

1. 그것은 CI의 사실상의 언어가되었습니다 : docker-compose.yaml, ansible, kuber, k8s, github, circle, azure, ... 그리고 CI를 사용하는 프로젝트로 크롤링하는 것 같습니다.

$config = Invoke-WebRequest https://$ciserver/api/projects/$project/config.yaml | ConvertFrom-Yaml
$config['started'] = Get-Date
$config['options'] = $options
Invoke-WebRequest -Method Post https://$ciserver/api/projects/$project/build -Body ($config | ConvertTo-Yaml)

이 배를 powershell과 함께 사용하면 CI 그룹에 전파하는 데 변화가있을 것입니다.
"MS powershell로 전환하면 자동으로 수행 할 수 있습니다."-> "추가 정보?"
vs
"ms powershell로 전환하고 갤러리에서 일부 스크립트를 다운로드하면"-> "아니요"

1. 실제로 이것은 순조 롭지 만 yaml은 json의 상위 집합이므로 json은 yaml의 축약 된 형태이고 효율적인 yaml 파서는 효율적인 json 파서입니다.

7.1에 대해 재고 할 수 있습니까? 또한 신뢰할 수없는 모듈을 사용하는 데 문제가 있으므로 DevsOpsy가 실제로 PowerShell에 기본적으로 제공되어야합니다.

IMHO, YAML은 JSON 및 CSV만큼 인기가 있으며 PowerShell에 YAML 용받은 편지함 변환기가없는 것은 다소 슬픈 일입니다. 받은 편지함 YAML 변환기를 사용하면 커뮤니티 모듈의 경우가 아닌 JSON 변환기와 동일한 동작을 수행 할 수 있습니다.

오해하지 마십시오. 사람들이 커뮤니티를위한 모듈을 생성한다는 점에 감사하지만, 현재 세상에서 YAML 변환은 테이블 스테이크입니다. 우리는 사람들이 JSON 변환을 위해 타사 모듈을 다운로드 할 것으로 기대하지 않습니다.