Powershell: ConvertFrom-Yaml, ConvertTo-Yaml

Kami memiliki diskusi serupa dari aspek DSC ,
memungkinkan kami untuk mengubah file konfigurasi berbasis json, kami ingin memiliki opsi untuk memodifikasi file berbasis xml, file berbasis YAML, file berbasis INI yang mendukung pertukaran RegEx dari dalam cmdlet Manipulasi Teks.

Kurangnya support yang ada di PS berarti kami harus bekerja keras untuk mendapatkan kemampuan tersebut.
Itu telah ditahan sambil menunggu kontribusi komunitas, tetapi jika itu dimasukkan ke dalam PS, itu akan membuatnya lebih mudah untuk bagian DSC juga.

Ketika Anda mengatakan secara native, apakah yang Anda maksud seperti XML atau JSON?

Pemikiran saat ini adalah bahwa YAML tidak boleh dimasukkan ke dalam PowerShell sama sekali, melainkan itu harus menjadi modul terpisah yang dapat Anda perbarui tanpa mengambil versi baru PowerShell.

Jika YAML dimasukkan ke dalam PowerShell seperti XML, itu tidak mungkin (pikirkan [xml] " b ")

Jika kami menggunakan rute JSON, Anda akan memiliki cmdlet untuk bekerja dengan YAML - jadi tidak benar-benar dimasukkan ke dalam PowerShell, tetapi Anda masih memiliki kekurangan karena perlu memperbarui PowerShell untuk mendapatkan pembaruan YAML.

@lzybkr Saya tahu kami mengatakan kami tidak ingin membawa perpustakaan baru, tapi saya pikir ini adalah sesuatu yang mungkin perlu kami nilai ulang. Idealnya, kami juga harus mengirimkan modul ke Galeri, tetapi saya pikir BANYAK skenario modern memerlukan YAML sekarang.

Mungkin tidak dalam jangka waktu 6.0, tapi kita harus membicarakannya.

@ ArieHein - Saya memiliki beberapa fungsi sederhana yang menyimpan dan mengambil array hash ke registri. Hanya menangani REG_SZ - tetapi untuk satu set pengaturan sederhana saja sudah cukup - beri tahu saya jika Anda menginginkan salinannya.

Saya salah bicara ketika saya mengatakan "asli" - maksud saya "bawaan" - itu tidak akan mengganggu saya jika mereka dikirim ke modul skrip yang dapat diperbarui.

Diskusi pertama kita # 2109

@iSazonov - ah ya saya mengerti!

Saya melihat referensi ke dukungan AWS dari YAML pada utas - Saya telah mengonversi beberapa templat dan menemukan ini berguna: https://github.com/awslabs/aws-cfn-template-flip

@iSazonov terima kasih atas penunjuknya, saya tidak dapat menemukannya karena alasan tertentu. Namun, ingatlah dengan baik.

Saat membaca ulang utas asli itu, saya pikir kita pasti harus menerapkan cmdlet di beberapa titik di masa mendatang, dan mengirimkannya ke Galeri. Berdasarkan kualitasnya, dan manfaat yang dirasakan orang (bersama dengan beberapa pekerjaan pemfaktoran ulang yang kami harap dapat dilakukan setelah 6.0.0), kami dapat melakukan panggilan dalam kotak vs. hanya Galeri.

Kami memiliki Yaml di https://github.com/PowerShell/platyPS

ya, ini akan luar biasa untuk dimiliki, akhirnya menggunakan https://github.com/awslabs/aws-cfn-template-flip untuk mengonversi

@MattTunny Selamat datang untuk berkontribusi! :-)

Ada suara pengguna Windows Server yang terbuka untuk memilihnya :-)

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

Ini pasti harus menjadi bagian dari pustaka PS 6.1 asli. Banyak hal saat ini ada di YAML.

Sekarang ada modul psyaml dan powershell-yaml di PSGallery tetapi keduanya bahkan tidak dapat memutar file YAML dari definisi build VSTS. Saya tidak keberatan jika modul tersebut dimasukkan ke dalam PowerShell atau merupakan modul dari PSGallery.

Saya ingin tahu apakah masalah inti di sini adalah cara kita menyebarkan modul yang kikuk. Hari ini, Anda harus menemukan, mempercayai, dan menginstal modul sebelum dapat menggunakannya. Bandingkan ini dengan cara yang (tampaknya) licin yang dilakukan Javascript var m = require('mymodule') . Mungkin kita harus memiliki beberapa cara untuk melakukan apa yang dilakukan DSC selain PowerShell asli. Di DSC, ketika sebuah modul direferensikan dalam konfigurasi, itu secara otomatis diunduh dan diinstal pada node target tanpa upaya manual. Membuat modul penting tetapi non-inti tersedia dengan cara itu harus menghilangkan argumen "itu harus menjadi bagian dari inti". Dan untuk node yang terputus dari internet, kita dapat memiliki alat yang menggabungkan dependensi dalam skrip menjadi arsip yang kemudian disebarkan ke target. Beginilah cara kerja ekstensi sumber daya Azure DSC - ada alat yang memindai skrip untuk mencari tahu modul yang diperlukan, lalu membuat file zip yang berisi semua yang diperlukan dan menerbitkannya ke blob. Ekstensi sumber daya Azure kemudian menarik blob ini, menginstal modul dan menjalankan skrip.

Untuk sesuatu yang sepenting ini, saya benar-benar tidak ingin bergantung pada perpustakaan pihak ketiga kecuali saya memiliki cara untuk menjajakannya. Terlalu mudah bagi pengembang pihak ketiga untuk berpotensi merusak seluruh ekosistem (lihat https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/).

Selain masalah yang lebih luas, saat ini tidak ada modul YAML yang bagus untuk PowerShell, seperti yang ditunjukkan @bergmeister . Ini adalah suatu keharusan untuk bahasa yang sangat berfokus pada otomatisasi. File konfigurasi berbasis YAML sangat populer sekarang dan sangat sulit untuk menghindarinya bahkan jika Anda tidak harus bersaing dengan pendapat tim untuk melakukannya. Pikirkan alasan di balik memasukkan XML dan JSON sebagai bagian inti dari bahasa tersebut. Kasus untuk YAML benar-benar tidak jauh berbeda.

@bgshacklett Dari apa yang saya dengar dari orang-orang Puppet, tidak ada pengurai YAML yang bagus :-)

Apakah parser platyPS cukup baik?

@vors Apakah ada cara sederhana untuk menggunakan kembali parser YAML platyPS di repo PowerShell Core?

Saya lebih suka ide modul resmi terpisah di Galeri PowerShell seperti yang dikatakan @lzybkr karena dimungkinkan untuk menggunakannya dalam versi PowerShell yang lebih lama dan dapat memiliki rilisnya sendiri. Itu akan seperti modul sqlserver . @BrucePay jika itu adalah halaman di Galeri PowerShell dengan modul Microsoft sendiri, akan lebih mudah untuk menemukannya dan semua orang akan tahu bahwa mereka dapat mempercayai mereka.

Tapi saya akan mengerti jika itu didukung ke Powershell sebagai XML dan JSON.

Yang penting adalah bahwa itu ada fungsi resmi ConvertFrom-YAML dan ConvertFrom-YAML karena YAML adalah format yang banyak digunakan untuk file konfigurasi dan seharusnya tidak menjadi modul pihak ketiga, seperti yang ditunjukkan @bgshacklett .

Saya membuat pengujian entri blog dan membandingkan dua modul yang saya temukan berfungsi dengan file YAML: PSYaml dan powershell-yaml .

Mereka memiliki perilaku yang berbeda karena secara internal mereka menggunakan objek yang berbeda:

| modul | pemetaan | urutan |
| --------- |: -------------- | ----------- |
| PSYaml | OrderedDictionary | Array |
| PowerShell-yaml | Hastable | Daftar |

Saya pikir kita membutuhkan standar ConvertFrom-YAML dan ConvertFrom-YAML .

Sebenarnya, ConvertFrom-Yaml dalam powershell-yaml menggunakan OrderedDictionary saat mengonversi dengan parameter -ordered .
Saya telah berhasil menggunakan modul ini untuk sementara waktu (dalam modul Datum saya untuk data Konfigurasi DSC, dan dengan yamls dapur), tetapi tidak memiliki definisi build vst untuk diuji.

Ingatlah bahwa cara yang tepat untuk menyebutnya adalah: get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered (orang sering melewatkan -Raw ).

Saya bertanya-tanya mengapa kita membutuhkan modul Microsoft _official_, menempatkan lebih banyak overhead pada MSFT dan menciptakan kembali roda ... Mungkin mencoba berkontribusi pada yang sudah ada terlebih dahulu, menambahkan tes untuk menghindari regresi, membuka masalah untuk memastikan pemilik mengetahui masalah adalah pendekatan yang lebih baik ...
Anda tahu apa yang terjadi ketika Anda mencoba membuat standar dari 99 implementasi yang ada ...

Dan ya akan lebih baik di luar bahasanya, saya setuju bahwa manajemen ketergantungan bisa lebih baik, menggabungkan semua yang ada di PS bukanlah solusi.
Masalah npm yang luas juga merupakan kegagalan dalam proses. Buat dan publikasikan ulang memperbaikinya dalam waktu singkat, membangun aplikasi dari versi terbaru internet adalah alasan mengapa begitu banyak aplikasi langsung rusak.

Saya setuju dengan @gaelcolas. Saya pikir ini lebih baik dengan semua orang yang bekerja dengan pemilik modul komunitas yang ada untuk meningkatkan dan memastikan kualitas.

Saya hanya akan menambahkan bahwa tes untuk proyek semacam itu harus mencakup bekerja dengan sejumlah besar file YAML dunia nyata untuk hal-hal seperti AppVeyor, Travis CI, VSTS, AWS CloudFormation, dll. Untuk pengalaman saya sendiri dengan deserilisasi YAML, saya pernah sedikit keberhasilan dengan satu solusi yang bekerja secara universal dan pada akhirnya harus menciptakan kembali roda beberapa kali. Dalam hal ini, saya setuju dengan @BrucePay "tidak ada

Kami berbicara tentang modul platyPS ini karena sudah aktif digunakan di lingkungan Bantuan PowerShell. Saya kira tidak ada seorang pun dari MSFT yang dapat mengetahui seberapa bagus modul ini karena Kode Etik. Mereka dapat secara diam-diam menolak atau memperbaikinya.
Dan meskipun kita telah membicarakan hal ini sejak lama, saya tidak melihat bagaimana kita dapat menggunakan komponen modul ini di sini dengan cara yang sederhana.
Mungkin @adityapatwardhan dan @ SteveL-MSFT akan membuka rencana dan timeline mereka terutama karena Help RFC yang baru sudah dalam tahap percobaan.

Pandangan pribadi saya adalah bahwa saya lebih suka melihat lebih banyak modul komunitas berhasil dan menjadi standar de facto daripada membutuhkan modul "resmi" dari Msft.

@iSazonov Memiliki solusi yang berfungsi untuk membuat serial / deserialisasi skema yang terdefinisi dengan baik adalah satu hal. Sangat berbeda dengan memiliki solusi yang bekerja secara umum dengan semua skema yang sesuai dengan YAML.

Saya memahami keinginan MSFT untuk menggunakan kembali proyek masyarakat untuk memangkas biaya. Tetapi kenyataannya, MSFT mungkin tidak memanfaatkan begitu banyak proyek komunitas:

• banyak yang memiliki kode buruk, tidak memiliki kepercayaan
• banyak proyek adalah satu orang

MSFT telah menerbitkan spesifikasi Powershell lebih dari 10 tahun yang lalu, tetapi belum ada yang mem-portingnya sampai MSFT melakukannya.
Proyek OpenSSL telah ada selama bertahun-tahun tetapi tidak ada yang melakukan porting ke Windows sementara MSFT belum melakukan ini.
MSFT mengungkapkan ribuan antarmuka API, tetapi berapa banyak di antaranya yang di-porting ke Unix?
Hal yang menarik tentang mengapa perusahaan meluncurkan proyeknya .Net Core daripada menggunakan kembali Mono?
PowerShell sudah satu setengah tahun adalah proyek open source, tetapi saya melihat bahwa di repositori ini hanya satu orang dari komunitas yang memberikan kontribusi sistematis dalam kode @markekraus dan hanya satu orang yang membuat analisis sistematis @ mklement0.
Saya tidak berpikir bahwa jika kita membagi proyek menjadi beberapa bagian, maka kita mendapat lebih banyak kontribusi.
Saya tidak berpikir situasinya akan berubah besok. Saya tidak akan mengandalkannya.

@markekraus Saya sangat berharap di http://yaml.org/spec/1.2/spec.html#id2802346 :-)

@iSazonov membuat poin penting tentang dukungan, kepercayaan, dan pemeliharaan modul pihak ketiga. Beberapa modul pihak ke-3 bisa menjadi sukses dan matang seperti misalnya Pester.
Namun, seseorang tidak boleh berasumsi bahwa modul YAML yang hebat akan berkembang dengan sendirinya selama beberapa tahun mendatang. Kenyataannya adalah bahwa sebagian besar modul diterbitkan oleh penulis yang memecahkan masalah tertentu dan melakukan perbuatan baik dengan menerbitkan kode dasar generik mereka. Ini adalah bagaimana kami berakhir dengan 2 modul yang bertujuan untuk memecahkan masalah yang sama. Idealnya seseorang perlu menggabungkannya untuk memfokuskan upaya, jika tidak mereka akan semakin menjauh di masa depan atau menjadi basi dan segera akan ada lebih banyak modul yang diterbitkan oleh orang lain.
Masalah mendasar dari memiliki parser yang tepat menunjukkan bahwa pekerjaan dasar dasar (dan substansial dalam hal upaya) diperlukan dan diperlukan untuk memiliki modul YAML yang baik.
Saya bukan ahli YAML, tetapi apakah ini hanya masalah spesifikasi bahasa yang longgar itu sendiri atau interpretasi spesifik oleh berbagai sistem seperti VSTS atau AppVeyor atau apakah ini hanya kekurangan parser yang baik?
Saya merasa frustasi untuk menulis YAML di VSCode dan hanya ketika menjalankannya di VSTS untuk mendapatkan kesalahan bahwa pengurai VSTS tidak menyukainya ...

Bagi saya percakapan ini adalah kasus yang berkaitan dengan masalah "kurasi kode / arsitektur" open source.

Sumber terbuka menyediakan ide-ide penyemaian yang baik dan basis kode - tetapi jika pandangan arsitektur yang serius tidak diberikan padanya ketika diadopsi sebagai solusi paling umum - maka 10 tahun perbaikan bug untuk item yang bisa ditangani dalam tinjauan desain yang layak .

Dalam kasus sebenarnya dari @bergmeister "keberhasilan yang matang", sering kali pengelola aktif yang telah mengambil misi untuk menggeneralisasi basis kode. Tapi itu tidak bisa dijamin akan terjadi.

Saya pikir beberapa dari kita mengatakan "Dukungan YAML seperti dukungan untuk menulis file - itu intinya - itu harus dirancang dengan cara yang sama => dengan maksud untuk menjadi standar emas untuk fungsi itu"

Kombinasi dari 1) atribut semi-architected dari open source bersama dengan 2) sifat inti dari YAML yang tampaknya membuat banyak dari kita mendesak untuk pendekatan yang sangat dirancang seperti yang kita tahu yang diterapkan oleh Pengembang Microsoft PowerShell pada pekerjaan mereka. Ini belum tentu menyimpang dari semua hal keren lainnya yang open source dapat membantu kita.

Poin yang sangat valid tentang kematangan perangkat lunak. Saya belum melihat secara dekat dua modul yang tercantum di sini, atau di yamldotnet untuk membuat opini apa pun. Sesuatu yang dapat kita lihat saat kita mulai merencanakan 6.2.0

Jangan salah paham, saya sangat menghargai pengalaman dan pendekatan sistematis dari tim PowerShell dan pengembang MSFT, saya hanya berpikir itu salah bagi mereka untuk mencoba mengisi semua celah dengan modul MSFT mereka sendiri yang dicap ... bukan skala (dan kami telah melihat masalah dengan resource DSC).
Meningkatkan ketergantungan pada modul yang disediakan MSFT sangatlah rapuh, dan tidak membantu menumbuhkan komunitas, maupun keragaman ekosistem.
Saya mendukung kontribusi MSFT pada proyek sumber terbuka untuk berbagi pengalaman mereka dan membantu meningkatkan praktik dan kualitas, tanpa membuat ketergantungan pada mereka (karena Anda tahu, tupai ...!).
_MSFT sebagai penyedia unik dari hal-hal yang disetujui_ adalah model lama yang sudah mereka perjuangkan untuk dididik, dan itu tidak membantu komunitas untuk mendorong pendekatan ini (yaitu _Saya akan menunggu, atau mengeluh, di Microsoft karena tidak menyelesaikan masalah yang saya miliki_ jenis sikap dalam ekosistem OSS).

Saya setuju bahwa dukungan YAML adalah inti, alih-alih tim PS menulis ulang dari awal, mengapa tidak membantu pengelola proyek yang ada untuk meningkatkan, dan memberi mereka kesempatan untuk menggabungkan proyek dan mendengar dari mereka apa yang diperlukan. Sedikit seperti magang / bimbingan dari tim PS tentang modul fungsionalitas inti.
Hanya menulis ulang modul baru terdengar seperti reaksi insinyur untuk memecahkan masalah yang bukan merupakan masalah teknik. Menulis ulang modul YAML adalah tugas rekayasa _easy_ untuk Tim PS, tetapi tidak akan (membantu) memperbaiki masalah kedewasaan komunitas, atau memberikan insentif yang tepat.
Apakah Yaml adalah item strategis untuk menangani ini adalah panggilan MSFT :)

@gambarunik

Saya akan mengawali ini dengan diri saya sendiri yang bukan ahli YAML. Saya kebetulan melakukan beberapa penelitian tentang hal ini ketika saya ingin memanggang beberapa konfigurasi AppVeyor seperti yaml ke dalam pipa franken saya sendiri. Saya melihat bagaimana selusin proyek C # menggunakan YAML. Karena proyek PowerShell menggunakan YamlDotNet, saya hanya bisa berasumsi bahwa ini tidak lebih mudah. Meskipun saya setidaknya telah bermain-main dengan PSYaml dan powershell-yaml dan telah melihat kurang dekat pada beberapa proyek PowerShell yang menggunakannya.

Saya bukan ahli YAML, tetapi apakah ini hanya masalah spesifikasi bahasa yang longgar itu sendiri atau interpretasi spesifik oleh berbagai sistem seperti VSTS atau AppVeyor atau apakah ini hanya kekurangan parser yang baik?

Saya menduga itu adalah sifat YAML yang dapat dibaca oleh manusia dengan kemungkinan mengorbankan lebih mudah dibaca oleh mesin. Paradigma pertama keterbacaan ini meluas ke cara penulis YAML menulis file YAML mereka. Meskipun YAML yang dihasilkan sesuai dengan spesifikasi YAML, ia diurai sedemikian rupa sehingga tidak dapat digunakan dalam kode tanpa menggunakan objek deserialisasi sebagai perantara ke objek yang sebenarnya berguna.

Artinya, 90% dari waktu deserialisasi dari YAML ke Objek bukanlah masalahnya, tetapi desain / arsitektur data yang menjadi masalah. 10% lainnya dari waktu _is_ masalah penguraian yang hanya bisa saya tuliskan dengan "YAML sulit diurai, man." Namun, objek deserialized seringkali hanya sedikit lebih berguna daripada regex-ing apa yang Anda cari ....

Sebagai contoh, string aman di AppVeyor.yml

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

powershell-yaml dan YamlDotNet memang mengonversinya menjadi objek, tapi semoga berhasil menggunakannya tanpa banyak logika. Setelah Anda memiliki logika itu, bagus untuk skema ini, tapi bagaimana dengan yang lain?

Beberapa dari masalah desain data yang sama ini mengganggu JSON, tetapi (menurut pengalaman dan pendapat saya) jauh lebih mudah untuk membuat model yang dapat mengatasi kekurangan tersebut karena sifat JSON yang lebih kaku. Mencoba membuat model untuk salah satu deserializer YAML yang disebutkan di utas ini adalah mimpi buruk jika dan di mana pun memungkinkan.

Memang, model bukanlah fitur yang saat ini tersedia di cmdlet JSON, meskipun saya benar-benar ingin menambahkannya. Jika saya memiliki suara dalam modul / cmdlet YAML "resmi", saya akan meletakkannya sebagai fitur yang "harus dimiliki". Ini adalah kesempatan yang terlewatkan terutama dengan penambahan kelas PowerShell di v5.

IMO, Hanya memasukkan string YAML ke dalam Object tidaklah cukup. Itu tampaknya mudah (setidaknya 90% dari waktu). Triknya adalah memasukkan string YAML ke objek _useful_. Itu membutuhkan beberapa fleksibilitas dari solusinya. Tetapi fleksibilitas itu juga harus dapat didekati dan tidak memerlukan @IISResetMe dan @lzybkr di sana untuk memberi Anda saran serialisasi ....

Untuk efek itu, saya belum melihat apa pun yang berfungsi pada ruang lingkup umum. Proyek mengadopsi solusi yang tersedia, dan kemudian menggunakan keluarannya sebagai perantara untuk objek yang benar-benar berguna (mengarah ke sekumpulan roda yang diciptakan kembali yang mungkin harus dipanggang di hulu). Atau, proyek membahayakan keterbacaan YAML untuk kemudahan penguraian dari YAML ke objek.

@gaelolas

Saya setuju dukungan YAML adalah inti, alih-alih tim PS menulis ulang dari awal, mengapa tidak membantu pengelola proyek yang ada untuk meningkatkan, dan memberi mereka kesempatan untuk menggabungkan proyek dan mendengar dari mereka apa yang diperlukan

Tanyakan pada diri Anda mengapa MSFT memulai proyek .Net Core alih-alih melanjutkan Mono bertahun-tahun kemudian.

MSFT juga merupakan komunitas. Dan karena komunitas mana pun memiliki masalah interaksi yang sama dengan komunitas lain.

Untuk konteksnya, saya tidak menyiratkan pekerjaan apa pun yang dilakukan dari awal - kode dapat diadopsi - tetapi kemudian harus diteliti dari perspektif arsitektur Pengembangan Sistem sebelum ditingkatkan. Bahkan bisa menjadi open source setelah review dan rilis ulang.

Maksud saya adalah memiliki tinjauan arsitektural yang signifikan dan perbaikan dari tim yang benar-benar memahami nuansa kode inti yang akan dimanfaatkan secara virtual di mana-mana.

Model lain yang selalu layak dipertimbangkan adalah memperoleh / kontrak / detik. Atas dasar ini, upaya dilakukan untuk mencapai persyaratan komersial dengan satu atau lebih anggota masyarakat / perusahaan untuk merekrut layanan mereka untuk siklus pengembangan yang dipimpin / difasilitasi MSFT untuk mengubah dan (dengan cara tertentu) mengintegrasikan / menghubungkan produk . Ini berhasil dilakukan dengan Xamarin, yang menendang proyek ke Net Foundation, melisensikannya di bawah MIT, dan merekrut / mengontrak / melibatkan sumber daya utama seperti Miguel de Icaza dan Nat Friedman melalui Xamarin. Beberapa mengeluh bahwa ini adalah pengkhianatan open source. Namun hal itu menciptakan insentif positif bagi masyarakat dan perusahaan kecil untuk membayangkan dan mengembangkan proyek yang nantinya dapat cocok untuk diadopsi secara luas dan diintegrasikan ke dalam setidaknya satu ekosistem utama. Tentu saja lebih disukai untuk melompat langsung ke papan tulis kosong ulang internal yang menyalin seluruh konsep dan fungsionalitas dan banyak ide tetapi membuang pencipta dan (seolah-olah) kodenya.

@iSazonov maaf atas jawaban yang terlambat, tidak ada parser yaml platyPS yang tidak baik: hanya mendukung pasangan nilai kunci. Kami juga menggunakan YamlDotNet untuk menghasilkan yaml di sana.

Mengenai sentimen untuk menjauhkan ini dari kumpulan fitur inti: ada perbedaan yang sangat signifikan dalam cara PowerShell menangani dependensi dibandingkan dengan, katakanlah, Ruby, Python atau Node.js.

Masing-masing bahasa ini memiliki alat manajemen ketergantungan (bundler, pip, npm / yarn) yang membuat manajemen ketergantungan eksternal mudah dan, yang lebih penting, dapat direproduksi. Memiliki sesuatu seperti Gemfile/Gemfile.lock atau package.json/package-lock.json [,yarn.lock] yang memudahkan instalasi semua paket yang diperlukan dan memastikan bahwa Anda tetap berada pada level patch yang sangat spesifik adalah perbedaan yang sangat signifikan, menurut pendapat saya, apa yang membuat perpustakaan pihak ketiga untuk sesuatu yang mendasar ini menjadi layak.

Mungkin ada sesuatu yang dapat dilakukan dengan Nuget untuk mengatasi masalah ini, tetapi saya belum pernah melihat artikel apa pun yang menjelaskan strategi / pola manajemen ketergantungan untuk PowerShell. Memiliki galeri itu bagus, tetapi jika Anda harus menginstal semua paket yang diperlukan secara manual, itu menjadi tidak layak untuk penerapan yang signifikan.

edit:
Jadi sepertinya yang saya cari _may_ sudah tersedia: https://docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduledependency. Saya akan mengujinya segera setelah saya punya waktu. Jika berhasil, saya perlu mempertimbangkan kembali posisi saya apakah ini harus menjadi item inti atau tidak. Saya masih mengalami kesulitan untuk mendamaikannya dengan fakta bahwa JSON adalah fungsionalitas inti, tetapi saya kira ini dapat dianggap sebagai "penyebut umum terendah".

@bggames.com adalah

@ chuanjiao10 - tolong hentikan komentar yang mengganggu di banyak masalah dalam repositori ini, solusi yang tepat adalah tidak memasukkannya ke dalam modul Microsoft.PowerShell.Utility dan sebenarnya mengirimkannya sebagai modul terpisah yang dihosting di PowerShellGallery

Ketika Anda mengatakan secara native, apakah yang Anda maksud seperti XML atau JSON?

Pemikiran saat ini adalah bahwa YAML tidak boleh dimasukkan ke dalam PowerShell sama sekali, melainkan itu harus menjadi modul terpisah yang dapat Anda perbarui tanpa mengambil versi baru PowerShell.

Jika YAML dimasukkan ke dalam PowerShell seperti XML, itu tidak mungkin (pikirkan [xml] "b")

Jika kami menggunakan rute JSON, Anda akan memiliki cmdlet untuk bekerja dengan YAML - jadi tidak benar-benar dimasukkan ke dalam PowerShell, tetapi Anda masih memiliki kekurangan karena perlu memperbarui PowerShell untuk mendapatkan pembaruan YAML.

Secara pribadi ini sementara rasanya seperti hal yang "benar" untuk kotak masuk saya akan menyarankan bahwa sebenarnya bukan hal yang benar untuk dilakukan

@lzybkr Saya tahu kami mengatakan kami tidak ingin membawa perpustakaan baru, tapi saya pikir ini adalah sesuatu yang mungkin perlu kami nilai ulang. Idealnya, kita harus _also_ mengirimkan modul ke Galeri, tetapi saya pikir BANYAK skenario modern memerlukan YAML sekarang.

Mungkin tidak dalam jangka waktu 6.0, tapi kita harus membicarakannya.

Mengirim modul eksternal jauh lebih baik menurut saya karena dapat digunakan di tingkat bawah dan IMO itu bukan tugas Tim PowerShell untuk melakukan ini dan lebih banyak komunitas untuk mendorong ini dengan bantuan dari tim PowerShell untuk mendapatkan kualitas tinggi jika memungkinkan.

Sekali lagi @ chuanjiao10 sebelumnya diputuskan untuk tidak menempatkan Cmdlet YAML ke dalam PowerShell Core di # 2109 dan kemudian ditolak dengan benar karena itu juga harus ditolak sekarang juga.

mengenai

kesatuan adalah kekuatan. Orang Amerika yang membutuhkan mobil, pernahkah Anda melihatnya pergi ke Wal-Mart untuk membeli roda, pergi ke Amazon untuk membeli mesin, dan menggabungkan dirinya sendiri (membuat mobil sendiri)?

Membandingkan mobil dengan perangkat lunak adalah analogi yang buruk mengingat komponen di dalam mobil berasal dari banyak pemasok yang berbeda dan kemudian dikemas menjadi produk yang dapat digunakan, yang tidak berbeda dengan Modul PowerShell yang dikembangkan oleh komunitas yang kemudian dapat dicampur dan dicocokkan & digunakan dalam skrip

Mengenai hal ini

Perpustakaan utama sudah ada di dalamnya, ini sangat penting, jika tidak saya melihat convertfrom-json, convertto-json, dll., Juga harus ditempatkan di PowerShellGallery.

Saya telah menganjurkan hal ini untuk sebanyak mungkin modul bawaan per # 1979 dan ingin melihat PowerShell Core menjadi seramping mungkin yang telah mulai dibahas lebih lanjut di # 5681

dan kembali

Jangan mendiskriminasi YAML, jangan memuji JSON.

Saya tidak membeda-bedakan Yaml atau menyanjung Json karena keduanya memiliki kekurangan tetapi keduanya memiliki kegunaan dan jika saya dapat memengaruhi untuk tidak mengirimkan cmdlet Json di PowerShell, saya akan melakukan hal yang sama persis seperti yang saya lakukan di sini.

Saya pikir mungkin bermanfaat untuk sedikit mengubah diskusi ini. Secara khusus, apakah mereka yang mendukung YAML yang disertakan dalam bahasa inti bersedia mendaftar kasus penggunaan tertentu dan mengapa modul di galeri PowerShell tidak cukup dalam menangani kasus penggunaan tersebut? Pada titik itu kita dapat melakukan diskusi yang didorong oleh persyaratan dan berpotensi menemukan solusi yang bisa diterapkan untuk masalah yang dihadapi.

Kasus penggunaan utama saya adalah untuk otomatisasi bare metal baik sistem operasi maupun penerapan aplikasi. Setidaknya dalam satu kasus saya ingin membaca file YAML yang memanggil skrip saya untuk memahami parameter.
Seringkali dalam kasus ini memiliki ketergantungan ke eksternal, non-SLAed bagi kami, layanan sangat tidak boleh. Ini dapat mempengaruhi aktivitas penskalaan produksi.

Itu adalah kasus penggunaan saya untuk pengiriman di footprint paling elemental dari inti PowerShell.

Saya menghargai diskusi yang hidup, mari kita coba untuk tetap sopan :)

@ PowerShell / PowerShell-committee telah membahas ini sebelumnya. Kami setuju bahwa mendukung YAML itu penting mengingat seberapa lazimnya saat ini. Kami juga ingin melihat lebih banyak modul yang saat ini kami kirimkan di PSCore6 dipindahkan sehingga Anda mulai dengan instalasi minimal PSCore6 dan kemudian menambahkan apa yang Anda butuhkan (dengan metamodul Anda tidak perlu menambahkan 10+ modul, cukup satu untuk DevOps , misalnya). Jadi mengenai YAML, pemikiran saat ini adalah ini harus menjadi modul terpisah (saya dapat membuat repo di bawah PowerShell org jika ada yang siap untuk mulai membuat prototipe ini, tim saya tidak memiliki bandwidth sekarang). Menggunakan YamlDotNet (atau pustaka pihak ketiga lainnya) tidak apa-apa setelah dievaluasi dari sudut pandang teknologi, lisensi, dukungan (mirip dengan cara kami mengambil ketergantungan pada Json.Net). Namun, terakhir kali kami melihat YAML dan YamlDotNet, masalahnya adalah implementasi YAML sangat bervariasi dan library itu tidak mendukung semua yang ada di luar sana (bahkan beberapa yang populer).

Saya hanya akan mengatakan bahwa dukungan YAML adalah sesuatu yang saya ingin tim perhatikan setelah rilis 6.2.

@ SteveL-MSFT Bisakah Anda memberi komentar berdasarkan masalah dan https://github.com/dotnet/corefx/issues/34578? Bisakah kami menggunakan YamlDotNet atau kami membutuhkan API yang lebih tepercaya dari CoreFX?

Menurut pendapat saya, biarkan convertfrom-json, convertfrom-jaml memiliki status yang sama, baik move out atau built in.

Saya telah menganjurkan bahwa kita harus mengeluarkan cmdlet JSON dari proyek. Ada beberapa perubahan yang ingin dilakukan banyak orang yang merupakan perubahan yang cukup merusak, tetapi perubahan tersebut tidak dapat dilakukan karena cmdlet terkait dengan PowerShell. Memindahkannya keluar dari proyek memungkinkan kami membuat perubahan besar dalam versi mayor baru dari modul cmdlet, dan memiliki pengiriman PowerShell dengan versi lama yang menyediakan kompatibilitas mundur tetapi memungkinkan pengguna untuk memperbarui jika mereka mau .... Namun, memang demikian kerumitan besar untuk memasukkan modul eksternal seperti ini, IMO.

Saya lebih suka kita belajar dari kesalahan kita dengan JSON dan Pester daripada memperlakukan YAML dengan cara yang sama. Ini pasti bukan bagian dari fungsi inti PowerShell, tetapi pasti harus memiliki semacam modul yang didukung secara resmi dengan kepemilikan bersama antara komunitas dan Tim PS.

Saya suka ide itu. Memindahkan Cmdlet JSON keluar akan membantu memunculkan masalah alur kerja yang saat ini ada dengan ketergantungan keras pada modul eksternal.

Tetapi yaml penting bagi administrator sistem, pengembang skrip, Pengguna ini memerlukan perintah yaml.

Mereka mungkin membutuhkannya tetapi itu tidak berarti bahwa mereka perlu disertakan secara langsung dalam PowerShell karena modul eksternal lebih dari yang dapat diterima dan memiliki siklus hidup dukungan yang lebih fleksibel daripada apa pun yang dibundel ke dalam repositori inti.

Saya harus mengatakan bahwa ide @ SteveL-MSFT tentang modul DevOps Meta benar-benar cara yang tepat untuk ini dalam jangka panjang karena ini memungkinkan set pengguna yang berbeda untuk mendapatkan satu set paket yang lebih sederhana yang lebih mudah dikelola sebagai ketergantungan eksternal daripada menjadi internal, yang bagi saya sangat masuk akal ke depan, meskipun mereka harus modul meta berdasarkan tumpukan teknologi karena jika saya menggunakan windows dan tidak menggunakan anisble lalu mengapa saya perlu cmdlet yaml di jendela?

Meskipun ada sejumlah besar pengguna di dunia linux yang menggunakan yml seperti yang disebutkan oleh @ chuanjiao10, ini tidak terjadi di dunia windows, yang dari pemahaman saya tentang penggunaan PowerShell secara keseluruhan sebagian besar masih menempel pada PowerShell 5.1 karena masuk kotak di sistem mereka , dan sementara memaketkan cmdlet Yaml dapat membantu pengguna Linux, bagi saya rasanya seperti item bundel tambahan yang tidak perlu untuk pengguna Windows tetapi untuk memperlakukan kedua kelompok pengguna dengan cara yang sama, sangat masuk akal bahwa itu akhirnya menjadi modul eksternal yang kedua kelompok pengguna dapat memanfaatkan sesuai kebutuhan

Adakah yang ingin menjadi pemilik dan menemani cmdlet ini dalam proyek terpisah?

@iSazonov tampaknya corefx saat ini tidak tertarik dengan dukungan YAML built-in. YamlDotNet tampaknya menjadi perpustakaan paling populer, berlisensi MIT, dikelola secara aktif, jadi saya akan mulai dari sana. Proyek berbasis komunitas akan luar biasa dan mungkin akan terjadi lebih cepat daripada jika Anda menyerahkannya kepada tim PowerShell.

@ SteveL-MSFT tampaknya itu untuk alasan yang baik - https://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255 yang saya harap ini telah menurunkan kepercayaan pada perpustakaan khusus ini.

tampaknya corefx saat ini tidak tertarik dengan dukungan YAML built-in.

Tim CoreFX bertanya tentang kasus penggunaan. Jika proyek PowerShell akan mengatakan bahwa kita membutuhkan API, mereka akan mempertimbangkan untuk menambahkan API.

Proyek berbasis komunitas akan luar biasa dan mungkin akan terjadi lebih cepat daripada jika Anda menyerahkannya kepada tim PowerShell.

Oh, saya hanya tahu satu proyek seperti itu - Pester. Dan saya tidak percaya dengan proyek berbasis komunitas yaml - mengapa tidak muncul dalam beberapa tahun terakhir?
Saya mempertimbangkan untuk memulai proyek tetapi menghentikan saya karena saya tidak pernah dapat mencapai tingkat kualitas, kepatuhan, dan keamanan kode yang dibutuhkan MSFT.
Saya kira MSFT tidak akan pernah bisa mempercayai dan menggunakan proyek tanpa audit keamanan.
Saya hanya punya satu ide untuk membuatnya berhasil. Proyek MSFT GitHub seperti CoreFX dan PowerShell "dimiliki oleh MSFT" dan "digerakkan oleh MSFT". Jenis proyek baru bisa "dimiliki oleh MSFT", "digerakkan oleh Komunitas" dan "dibimbing oleh MSFT". Di bawah "mentored" yang saya maksud adalah implementasi lingkungan di mana proyek akan dipercaya dan berkualitas tinggi.

Microsoft perlu menggabungkan dukungan YAML dalam kotak untuk PowerShell Core. Polos dan sederhana.

@brettjacobson Ya, itu akan sederhana, sederhana dan berkualitas tinggi tetapi tim MSFT tidak memiliki banyak sumber daya. Apakah Anda siap untuk berkontribusi? :-)

@brettjacobson - Microsoft tidak perlu menggabungkan dukungan YAML. Ini mungkin berguna jika mereka melakukannya tetapi tidak ada persyaratan dari mereka untuk melakukannya juga tidak ada kebutuhan untuk melakukannya sama sekali.

Ini adalah permintaan fitur untuk sesuatu yang banyak want dan akan akhirnya use tapi tidak kritis need & karena itu _unlikely_ untuk mendapatkan prioritas yang persis apa @ SteveL-MSFT berusaha keras ketika dia mengatakan hal berikut

Saya hanya akan mengatakan bahwa dukungan YAML adalah sesuatu yang saya ingin tim perhatikan setelah rilis 6.2.

Proyek berbasis komunitas akan luar biasa dan mungkin akan terjadi lebih cepat daripada jika Anda menyerahkannya kepada tim PowerShell.

Tim PowerShell tidak besar dan oleh karena itu melihat ini secara realistis, cara terbaik & tercepat untuk mendapatkan dukungan untuk YAML akan berada di luar rangkaian fitur inti PowerShell, daripada dimasukkan ke dalam produk itu sendiri.

Tim CoreFX bertanya tentang kasus penggunaan. Jika proyek PowerShell akan mengatakan bahwa kita membutuhkan API, mereka akan mempertimbangkan untuk menambahkan API.

@iSazonov IMHO tidak akan pernah ada dukungan YAML built-in di CoreFX, karena belum ada dukungan JSON yang lengkap.

Jadi, apakah Anda akan menunggu perpustakaan pihak ketiga yang "hebat" atau meminta James Newton-King untuk membuat Newtonsoft.Yaml ? :-)

@NextTurn Kami akan mendapatkan
Tim CoreFX selalu menambahkan API baru jika ada permintaan besar dari komunitas. Jika ada banyak proyek yang bisa mendapatkan keuntungan dari YAML, mereka akan menambahkan. Saat ini tidak ada permintaan seperti itu.

Apa yang tidak saya lakukan setiap sistem pwsh baru? Saya melakukan Install-Module -Name powershell-yaml .

Mongo, Kubernetes, Istio, Ansible, sebutkan - saya gunakan. Semua ini adalah YAML dan saya memiliki template dan transformasi YAML. pwsh tampaknya bagus untuk DevOps dan mereka berbicara YAML.

@ dzmitry-lahoda Issue # 5681 mengusulkan untuk memiliki versi 'kaya' dari PowerShell yang dikirimkan dengan satu set modul umum seperti misalnya Pester , dll. Silakan posting dalam terbitan ini tetapi karena tampaknya tidak ada pemenang yang jelas antara 2 modul yaml yang tersedia saat ini dan mereka saling memukuli, mungkin keputusan yang sulit untuk memilih yang favorit.

Saya hanya melihat satu YAML :(

Pester , ya. Terlalu berat untuk mengirimkan kerangka kerja BDD ke jalur utama, tidak seperti pembaca YAML untuk aplikasi kontainer pwsh saya.

Apakah utas ini telah selesai. Modul apa yang direkomendasikan (atau disarankan) untuk digunakan oleh Microsoft?
Pipeline DevOps menggunakan yaml. Semua otomatisasi penerapan saya dibuat dengan PowerShell. Sepertinya yaml dan PowerShell tidak bermain bagus. Apakah PowerShell pilihan yang buruk untuk otomatisasi Azure DevOps?
Perlu memikirkan dengan cermat penggunaan / inovasi saya di masa depan dan akan menghargai beberapa arahan.
Terima kasih sebelumnya!

@dirkslab Anda dapat menggunakan https://github.com/cloudbase/powershell-yaml

GitHub

cloudbase / powershell-yaml

CmdLets PowerShell untuk manipulasi format YAML. Berkontribusi pada pengembangan cloudbase / powershell-yaml dengan membuat akun di GitHub.

Terima kasih @iSazonov , itulah solusi yang saya uji saat ini. Solusi sejauh ini tampaknya berfungsi dengan baik. Mungkin tidak ada yang salah menggunakan solusinya.

Perhatikan bahwa menggunakan PowerShell-yaml Anda perlu mengaktifkan modul yang tidak tepercaya. Ini adalah bagian yang saya perjuangkan untuk dipahami. Microsoft merekomendasikan menggunakan saluran pipa yaml. Microsoft (atau setidaknya utas ini) menyarankan untuk menggunakan modul pihak ketiga sehingga Anda dapat mengintegrasikan konfigurasi yaml dengan PowerShell, tetapi tidak mendukung atau merekomendasikan apa pun. Bagaimana Anda menjelaskannya secara logis kepada perusahaan.
Pengalaman saya sejauh ini selalu bahwa jika Anda tidak menggunakan solusi yang didukung Microsoft, itu akan menonaktifkan dukungan atau pemahaman apa pun dari Microsoft untuk masalah solusi Anda (ini tidak masalah jika bagian yang tidak didukung menyentuh sesuatu yang menyebabkan masalah). Fakta bahwa Anda memiliki bagian yang tidak didukung biasanya menghasilkan tidak ada dukungan / tanggung jawab.
Mungkin banyak hal telah berubah di era OpenSource ini. Tanggapan dan panduan resmi yang sederhana dari Microsoft akan membuat saya nyaman dan membantu saya memahami.

Menghargai tanggapan Anda. Salam.

@dirkslab Saya rasa manajer akun MSFT Anda adalah orang yang tepat untuk bertanya tentang kebijakan dukungan.

Tim CoreFX bertanya tentang kasus penggunaan

Terlepas dari manfaat nyata bahwa yaml ada di sekitar kita di CI / CD saat ini dan jumlah sistem konfigurasi, manfaat tambahan dari ConvertTo-Yaml mewakili HashTable nasted dalam format yang dapat dibaca manusia , tidak seperti ConvertTo-Json yang harus kita gunakan sekarang yang membuat keluaran tidak terlalu mudah dibaca.

Saya menggunakan Write-HashTable untuk sementara waktu, tetapi ini akan sangat bagus untuk memiliki OTB.

Aku benci yaml, aku sangat membencinya. Namun ada beberapa aspek yang patut dipertimbangkan oleh tim MS:

1. Ini menjadi bahasa defacto CI: docker-compose.yaml, ansible, kuber, k8s, github, circle, azure, ... Dan sepertinya merangkak keluar dari CI ke dalam proyek yang menggunakannya.

$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)

Memiliki kapal dengan PowerShell ini akan menjadi transformatif dalam menginjili kelompok CI.
"Jika kita beralih ke ms PowerShell, kita dapat secara otomatis" -> "Ceritakan lebih banyak?"
vs.
"Jika kita beralih ke ms PowerShell dan mengunduh beberapa skrip dari galeri" -> "tidak"

1. Sungguh, ini by-the-by, tetapi yaml adalah superset dari json, sehingga json adalah bentuk singkatan dari yaml, parser yaml yang efisien adalah parser json yang efisien,

Bisakah ini dipertimbangkan kembali untuk 7.1? Saya juga mengalami masalah dengan menggunakan modul yang tidak tepercaya dan sesuatu sehingga DevsOpsy harus benar-benar asli dari PowerShell.

IMHO, YAML sepopuler JSON dan CSV, dan tidak memiliki konverter kotak masuk untuk YAML di PowerShell agak menyedihkan. Memiliki pengonversi YAML kotak masuk juga akan memastikan bahwa perilakunya setara dengan pengonversi JSON, yang tidak terjadi pada modul komunitas.

Jangan salah paham - Saya menghargai bahwa orang-orang membuat modul untuk komunitas, tetapi dalam keadaan dunia saat ini, konversi YAML adalah taruhan tabel - kami tidak mengharapkan orang-orang mengunduh modul pihak ketiga untuk konversi JSON.