Harap tambahkan info bagaimana Anda ingin meningkatkan bahasa PowerShell untuk menambahkan versi. Dalam atribut cmdletbinding?

Pikiran saya adalah melakukan sesuatu seperti New-ScriptFileInfo yang menghasilkan header komentar seperti ini:

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

Jadikan PSFunctionInfo dan minta Get-Command menguraikannya. Atau dengan cara yang sama seperti PowerShell dapat mengurai #requires, mintalah mengurai #version. Yang menjadi rumit adalah ketika Anda memiliki banyak fungsi dalam file ps1 yang sama, jadi apa pun yang akan saya lakukan sebagai pembuat fungsi, harus disertakan dalam fungsi. Ini bisa berupa blok komentar yang diuraikan, opsi cmdletbinding() baru, atau mungkin atribut yang sama sekali baru.

Function Get-Awesomeness {

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

 Param ()

 ...
}

Saya tidak melihat nilai dari fitur tersebut. Kami dapat mempublikasikan di PowerShellGet dan mendistribusikan skrip PowerShell sebagai modul saja, kami tidak dapat melakukan ini untuk file. Bisakah Anda menjelaskan kasus bisnis/alur kerja?

Ada banyak orang yang membuat solusi PowerShell yang tidak pernah dipublikasikan di galeri. Mereka digunakan secara internal, katakanlah di lingkungan perusahaan. Dan tidak semuanya dikemas menjadi sebuah modul. Saya dapat bekerja di lingkungan perusahaan dan memiliki file skrip mandiri dengan fungsi. Saya ingin kemampuan untuk melacak versi untuk fungsi itu. Jika saya menjalankan Get-Command Get-CompanyFoo, saya harus dapat melihat nomor versi. Dalam hal ini, bahkan dalam sebuah modul, semua fungsi yang diekspor memiliki nomor versi yang sama. Saya ingin fasilitas untuk melacak informasi versi per fungsi. Dan tentu saja, tanpa harus bergantung pada membaca kode sumbernya. Jika teknisi meja bantuan menggunakan salah satu fungsi saya, mereka harus dapat menggunakan PowerShell untuk menemukan versi perintah.

Tentu saja, tidak semua fungsi membutuhkan ini, bahkan yang ada di dalam modul. Saya tidak punya masalah dengan fungsi dalam modul yang menggunakan versi modul jika tidak ada versi khusus perintah yang terdeteksi.

@jdhitsolutions Terima kasih!

Saya melihat dua komponen dalam skenario Anda - (1) sistem pelacakan versi, (2) sistem distribusi.
Yang pertama bisa jadi GIT (yang lain?).
Tidak jelas bagaimana Anda mendistribusikan file skrip.

(Saya mencoba memahami di mana tempat yang tepat untuk atribut yang diminta.)

Saya meninggalkan fungsi di klien secara teratur, yang terkini sejak terakhir kali saya menggunakannya di klien tertentu. Yang saya gunakan di klien hari ini muncul di pikiran - getWUlog. Ia tahu bagaimana menghubungkan ke sistem jarak jauh menggunakan WinRM dan psexec (ia memeriksa untuk melihat apakah 139 atau 5985 terbuka) dan mengambil log WindowsUpdate dari komputer itu, mengambilnya ke komputer lokal, dan membuka notepad.

Lainnya adalah getFrameworkVersion. Apakah hanya itu - terlihat menemukan versi .NET Framework yang diinstal pada komputer tertentu, menggunakan CIM atau layanan registri jarak jauh (sekali lagi - memeriksa port untuk mencari tahu apa yang harus dilakukan), melaporkannya, dan melaporkan versi apa yang diblokir, jika ada.

Ini adalah fungsi yang berdiri sendiri. Bukan bagian dari modul. Tetapi mereka telah melalui pembaruan rutin selama beberapa tahun terakhir.

Akan sangat bagus untuk melampirkan versi ke masing-masing. Saat ini, saya hanya memiliki "tanggal modifikasi terakhir" di bagian atas sumber. Kurang bermanfaat...

Distribusi tidak relevan dalam pikiran saya untuk diskusi ini. Dan ya, git berperan tetapi bukan itu masalahnya. Jika saya di PowerShell dan saya menggunakan fungsi mandiri. Ketika saya menjalankan Get-Command Get-Foo saya ingin melihat nomor versi dari fungsi tersebut. Ini sesederhana itu. Tidak masalah bagaimana fungsinya didistribusikan. Beri saya cara untuk menyuntikkan metadata ke dalam fungsi.

Dan untuk lebih jelasnya, saya tidak ingin memaksa pengguna, atau bahkan saya sendiri, untuk melacak sumbernya dan mencari komentar atau catatan.

Saya pasti menulis/menggunakan beberapa fungsi mandiri, tetapi sebagian besar ada dalam modul. Dan sebagian besar adalah alat flotsam acak yang dapat digunakan sebagai fungsi mandiri. Saya selalu meletakkan versi semantik dan changelog di .NOTES di dalam blok komentar, dan [version]$Version di blok awal, karena saya ingin melacak perubahan apa yang saya buat pada fungsi tertentu, bukan hanya ke modul (yang saya tingkatkan ketika saya membuat perubahan pada fungsi bagian dalam). Memiliki sesuatu seperti [version()] atau [cmdletbinding(Version='01.00.0000')] akan sangat spektakuler; Saya menyukainya lebih baik daripada .VERSION karena saya tahu banyak orang memasukkan banyak fungsi ke dalam file psm1 (walaupun saya tidak).
Saya menggunakan git, juga, tetapi saya tidak melakukan setiap kali saya membuat perubahan pada fungsi individu; Saya menggabungkannya dan melakukan ketika saya mengubah modul, biasanya dengan versi modul sebagai pesan komit. Ya, ya, aku tahu, aku aneh.

Jika skrip ditemukan di $env:PATH , itu muncul untuk Get-Command. Jadi tampaknya masuk akal untuk memetakan metadata ScriptFileInfo yang ada ke anggota ExternalScriptInfo yang menyertakan Versi.

Hati-hati dengan anggapan itu Steve. Saya mungkin memiliki satu file ps1 dengan banyak fungsi. Saya tidak ingin percaya bahwa Get-Command dapat menemukan file skrip. Heck, saya mungkin ingin mendefinisikan fungsi berversi dalam skrip profil PowerShell.

Pasti memiliki fungsi berversi dalam skrip profil saya.

Kita sudah memiliki tipe System.Management.Automation.FunctionInfo yang memiliki properti Version. Kami membutuhkan cara agar ketika fungsi dimuat, properti versi diisi dari metadata dalam fungsi.

Terima kasih semua untuk umpan balik yang bagus! Saya masih memiliki beberapa pertanyaan. Perilaku apa yang Anda harapkan jika PowerShell menemukan beberapa fungsi dengan nama yang sama? Jalankan fungsi dengan versi yang lebih tinggi? Haruskah kami mempertimbangkan cakupan akun (Anda memuat fungsi lama cakupan saat ini - haruskah kami memanggil lebih banyak fungsi baru dari cakupan global)? Atau kita hanya ingin memiliki atribut informasional?

Ini bukan tentang menjalankan atau mendistribusikan fungsi. Yang saya inginkan hanyalah mekanisme untuk menyediakan cara untuk melacak dan menemukan informasi versi sehingga jika saya menjalankan Get-Command, atau mungkin perintah baru seperti Get-Function, saya dapat melihat beberapa metadata tentang fungsi tersebut. Saya punya beberapa ide yang mungkin saya coba buat prototipe melalui skrip PowerShell.

Terima kasih semua untuk umpan balik yang bagus! Saya masih memiliki beberapa pertanyaan. Perilaku apa yang Anda harapkan jika PowerShell menemukan beberapa fungsi dengan nama yang sama? Jalankan fungsi dengan versi yang lebih tinggi? Haruskah kami mempertimbangkan cakupan akun (Anda memuat fungsi lama cakupan saat ini - haruskah kami memanggil lebih banyak fungsi baru dari cakupan global)? Atau kita hanya ingin memiliki atribut informasional?

Saya tidak berpikir ada yang menyarankan perubahan apa pun dalam cara PS menjalankan fungsi. Kami hanya ingin menempatkan versi pada mereka. Informasi dan cara untuk menginterogasi sama.

Terima kasih! Pertanyaan berikutnya yang saya miliki. File dengan beberapa fungsi dapat memiliki atribut versi yang sama untuk semua fungsi dalam file. Haruskah kita mempertimbangkan ini?

Saya punya beberapa ide yang mungkin saya coba buat prototipe melalui skrip PowerShell.

Anda bisa berbagi ide di Gist.

Itu rencanaku.

Haruskah itu Versi klasik atau SymVer 2.0?

Saya menjadi semakin yakin bahwa versi fungsi adalah hal yang baik.

Untuk menjawab pertanyaan terbaru @iSazonov - jika kita ingin memilikinya, mengapa TIDAK menggunakan SymVer?

Dan mengenai file fungsi - saya berpendapat bahwa atributnya adalah per fungsi tanpa atribut per file. Sama seperti CMDLETBinding hari ini bekerja.

Prototipe ditarik ##11686

Anda dapat mengunduh artefak dari PR dan bermain dengan atribut baru.

Manis.

Memikirkannya - mengapa tidak memperluas PSVersionAttribute untuk menyertakan versi skrip. Jika kita membuat versi modul dan (semoga sekarang!) berfungsi, mengapa bukan skrip?

PSVersionAttribute juga dapat berfungsi sebagai nilai default untuk fungsi yang ditentukan dalam skrip.

Dan sebelum orang lain bertanya... Bisakah eksekusi fungsi diversi?

Kami dapat memuat beberapa versi fungsi, menjalankan yang terbaru secara default, tetapi memiliki parameter umum -PSFunctionVersion yang mengatakan versi spesifik mana yang akan dijalankan.
Tidak diragukan lagi ada lebih banyak alternatif - tetapi haruskah kita menyediakan eksekusi fungsi berversi?

Jika itu adalah atribut, Anda selalu dapat menggunakannya kembali, seperti bagaimana [CmdletBinding()] dapat diterapkan pada fungsi dan skrip, Anda selalu dapat menggunakan [PSVersion()] untuk fungsi dan skrip. Ini terlihat seperti pendekatan yang menarik. 🙂

Saya tidak memperkirakan banyak penggunaan hal semacam ini dalam modul, di mana sebagian besar kita sudah memiliki kode berversi, tetapi untuk skrip dan fungsi yang berdiri sendiri, ini memang bisa sangat menarik

Ini bukan tentang menjalankan atau mendistribusikan fungsi. Yang saya inginkan hanyalah mekanisme untuk menyediakan cara untuk melacak dan menemukan informasi versi sehingga jika saya menjalankan Get-Command, atau mungkin perintah baru seperti Get-Function, saya dapat melihat beberapa metadata tentang fungsi tersebut. Saya punya beberapa ide yang mungkin saya coba buat prototipe melalui skrip PowerShell.

Jika kita ingin menambahkan versi fungsi, mengapa membatasinya pada dokumentasi murni? Jika saya dapat menentukan dan menanyakan versi fungsi, bukankah masuk akal untuk mengizinkan eksekusi berdasarkan nomor versi?

Baik dengan cara memuat beberapa versi fungsi dan dapat memilih yang akan dieksekusi, atau memungkinkan pengguna untuk memilih di antara versi yang berbeda untuk dimuat ke dalam daftar fungsi yang kita lihat dengan gcm dan kemudian jalankan yang itu.

Jadi, inilah bukti konsep yang saya kerjakan berdasarkan perintah ScriptFileInfo:
https://Gist.github.com/jdhitsolutions/65070cd51b5cfb572bc6375f67bcbc3d

Apa yang benar-benar saya coba modelkan atau prototipe adalah pengalamannya. Saya lebih suka data diekspos dengan Get-Command, karena sudah ada tipe yang sesuai.

Dan mendapatkan campuran file.

Jika suatu fungsi milik modul, saya tidak akan repot dengan versi perintah. Itu harus ditangani oleh modul.

Inti

Bukti konsep untuk menambah dan mendapatkan informasi meta data PowerShell

Bukti konsep untuk menambah dan mendapatkan informasi meta data PowerShell - PSFunctionInfo.format.ps1xml

Jeff yang baik!

Jadi bagaimana kita menangani beberapa versi dari fungsi yang sama?
Bagaimana cara memuat versi fungsi tertentu secara eksplisit?
Bagaimana seseorang secara eksplisit menjalankan versi tertentu dari suatu fungsi?

@doctordns Anda bertanggung jawab untuk mencari tahu apa yang harus dijalankan dan berurusan dengan beberapa versi. Kode prototipe saya hanya mencantumkan item di FunctIon: Psdrive dan menampilkan informasi metadata. Sejauh yang saya tahu Anda tidak dapat memiliki fungsi duplikat di psdrive. Tujuan saya adalah, jika saya memiliki fungsi yang berdiri sendiri dimuat, saya ingin dapat mengambil versi dan mungkin informasi meta data lainnya.

Meskipun saya pikir akan sangat bagus jika PowerShell mendukung metadata _embedded_ PSScriptInfo untuk _scripts_ ... tolong jangan lakukan ini di level _function_.

Versi hanya berguna jika Anda dapat melakukan sesuatu tentangnya

PowerShell saat ini _melaporkan_ versi pada perintah, tetapi versi sebenarnya berasal dari _module_. Memiliki versi terpisah untuk setiap fungsi tidak akan membantu, itu hanya akan membingungkan. Terlepas dari bagaimana Anda mendistribusikan kode Anda, Anda tidak mendistribusikan sub-file "bak" dan pengguna tidak dapat memuat fungsi individu (atau apa pun kecuali file lengkap) -- jadi tidak ada gunanya mencoba versi mereka.

Saya pikir kita membutuhkan versi untuk modul dan skrip. Fungsi harus mewarisi versinya dari _module_ yang memuatnya. Script membutuhkan versi mereka sendiri.

Untuk catatan:

Jika Anda memiliki file .ps1 yang memiliki banyak fungsi di dalamnya, Anda perlu mengubah ekstensinya. Jika tidak, maka pengguna tidak memiliki cara untuk menemukan fungsi-fungsi itu, jadi pembuatan versi tidak masalah. Kita harus secara aktif mencegah siapa pun yang mencoba mendistribusikan _functions_ dalam apa pun selain modul. 🤨

@Jaykul Saya setuju bahwa jika suatu fungsi dikirimkan dengan modul, yang seharusnya menjadi tujuannya, versi modul itu penting. Namun, ada banyak penggunaan yang menggunakan fungsi yang berdiri sendiri. Mungkin dimuat dalam profil atau sumber titik untuk memenuhi kebutuhan tertentu. Tidak semua yang saya lakukan perlu dimuat dan dibangun ke dalam modul. Fungsi non-modul inilah yang ingin saya kelola. Saya ingin cara untuk menangkap versi dan informasi metadata lainnya seperti yang kami lakukan untuk perintah yang dimuat dari modul. Mungkin jawabannya adalah perintah baru seperti prototipe saya.

@Jaykul Saya pikir beberapa dari kita telah mengatakan bahwa itu akan, memang, berguna bagi kita dan bahwa kita, memang, mendistribusikan fungsi tunggal.

IMO, tidak semuanya membutuhkan modul.

Fitur yang diusulkan mungkin tidak berguna bagi Anda. Dan itu bagus. Tapi itu untuk orang lain dari kita.

Saya suka ide versi fungsi. Tetapi jika kami melakukan solusi, itu harus lebih dari sekadar dokumentasi kecil yang dapat Anda lakukan di komentar Tanpa kemampuan untuk mengontrol pemuatan versi yang berbeda, dll. Ini adalah fitur yang mungkin dapat kami lakukan tanpa untuk saat ini.

Saya sarankan kita membuang ide ini untuk 7.0. Kami TERLALU dekat dengan RTM untuk memasukkan fitur baru ke dalam campuran. Saya memiliki kenangan buruk tentang NT 5 hari!! Jika kita dapat mendorong ini kembali ke 7.1, MAKA mari kita bicara lebih lengkap tentang bagaimana menerapkannya sepenuhnya. Mencoba untuk mendorong ini keluar pada menit terakhir adalah cara pasti untuk menyebabkan kekecewaan.

Jika ini terjadi, itu adalah tambahan 7.1. Saya pikir masalah memuat versi yang tepat terserah pengguna. Sekali lagi, yang saya minta adalah cara untuk mengambil info versi dari fungsi mandiri yang dimuat tanpa harus menggali sumber.

Saya setuju dengan 7.1.

Pada saat yang sama, Saya tahu pengguna, dan saya berani bertaruh satu atau tiga botol bahwa solusi dokumentasi hanya akan menghasilkan permintaan untuk fitur runtime berbasis versi. Saya ingin kita mempertimbangkan solusi yang lengkap dan elegan serta direkayasa dengan baik. .

Kami sudah memiliki solusi untuk fungsi mandiri - yang terakhir dimuat menang. :-)

Tanpa kemampuan untuk mengontrol pemuatan versi yang berbeda, dll. Ini adalah fitur yang mungkin tidak dapat kami lakukan untuk saat ini.

Ini akan memaksa kita untuk memeriksa versi fungsi setiap kali dipanggil. Ini benar-benar tidak dapat diterima karena alasan kinerja. Modul adalah kompromi terbaik - pemeriksaan versi dilakukan sekali saat memuat modul.

@SteveL-MSFT Saya yakin sudah siap untuk kesimpulan Komite PowerShell. Prototipe #11686.

Tampaknya semua setuju bahwa versi untuk skrip berguna untuk dimiliki di mesin.
Versi untuk fungsi dipertanyakan karena konsepsi modul ada.

Batasan umum adalah bahwa kita hanya dapat melihat versi untuk skrip dan fungsi yang dimuat dan tidak dapat melakukan itu impor-modul - memuat versi yang diperlukan tetapi get-module juga tidak memiliki parameter versi eksplisit.

Jangan terlalu memikirkan ini atau membuatnya lebih rumit dari yang seharusnya. Fungsi yang dikirimkan dengan modul adalah milik modul. Titik. Itu harus menjadi praktik terbaik yang direkomendasikan. Namun, tidak setiap fungsi yang mungkin digunakan dalam produksi di-deploy dengan modul. Saya sebenarnya tidak peduli tentang bagaimana itu digunakan. Yang saya katakan adalah bahwa saya ingin cara untuk melihat fungsi yang dimuat di Fungsi: PSDrive dan dapat melihat nomor versi, dan mungkin beberapa informasi metadata lainnya. Saya tidak ingin memaksa diri saya atau pengguna akhir untuk melacak kode sumber atau folder untuk menemukan informasi versi.

Saya berharap Get-Command akan menjadi alat untuk mengumpulkan informasi ini, tetapi mungkin ini perlu dipisahkan menjadi sesuatu yang benar-benar terpisah untuk manajemen fungsi yang berdiri sendiri.

Dan mungkin jawabannya adalah masalah ini sebaiknya diserahkan kepada masyarakat untuk diselesaikan. Dalam hal ini, saya pikir saya memiliki awal yang baik untuk sebuah solusi.

Kebenaran yang jujur ​​​​di sini adalah bahwa fungsi sumber titik bukanlah cara yang benar, dan seharusnya tidak direkomendasikan bertahun-tahun yang lalu ketika sistem modul datang di v2. Satu-satunya waktu yang masuk akal untuk digunakan adalah di v1.

Seperti yang kita semua tahu sekarang, semua fungsi harus ditempatkan secara realistis di dalam modul, bahkan yang Anda muat sebagai bagian dari profil Anda (yang harus Anda muat modul yang berisi fungsi-fungsi ini) atau gunakan sebagai bagian dari skrip yang lebih besar untuk perawatan yang lebih mudah, atau bahkan fungsi tunggal yang perlu Anda gunakan dalam skrip xyz.

Saya hanya dapat melihat perubahan ini akan menambah lebih banyak kebingungan bagi mereka yang datang ke bahasa daripada manfaat dengan menambahkan atribut [Version] disarankan ke definisi fungsi dengan banyak pemikiran bahwa mereka akan diminta untuk mengatur versi Modul dan Fungsi ketika mereka melakukannya hal-hal dengan benar dan benar-benar membangun modul kode yang dapat digunakan kembali.

Ya ini berarti Anda harus memiliki psd1 dan psm1 tetapi 2 file untuk dapat ditemukan dan dirawat dengan benar bukanlah permintaan besar untuk dikelola

Seperti yang mungkin Anda katakan, saya pribadi tidak setuju dengan perubahan ini & berpikir ada hal-hal yang lebih baik untuk difokuskan sebagai gantinya

Ya ini berarti Anda harus memiliki psd1 dan psm1 tetapi 2 file untuk dapat ditemukan dan dirawat dengan benar bukanlah permintaan besar untuk dikelola

Ya, itu adalah pertanyaan besar. Mencoba membuat skrip admin menjadi pengembang menimbulkan hambatan masuk yang signifikan.

Mengatakan "oh Anda harus menyalin ini di sini dan menyalinnya di sana dan kemudian mengimpornya" jauh lebih rumit dan jauh lebih rentan terhadap kesalahan daripada mengatakan "salin dan tempel ini ke file bernama run.ps1 lalu ketik ,\run .ps1".

Ini adalah perubahan kecil dan lebih menguntungkan skrip kasual/admin daripada operator ternary atau penggabungan nol (yang saya masih tidak mengerti) atau banyak perubahan terbaru lainnya yang dibuat untuk Anda yang adalah pengembang. Seperti yang dikatakan tentang itu, saya dapat mengatakan tentang versi fungsi: jika Anda tidak menyukainya, jangan gunakan itu.

@SteveL-MSFT Saya percaya komite PowerShell dapat melihat permintaan untuk mendukung versi untuk skrip dan fungsi mandiri. Prototipe ada di #11686.

Kebenaran yang jujur ​​di sini adalah bahwa fungsi sumber titik bukanlah cara yang benar,

Tetapi orang-orang melakukannya, dan itu bukan satu-satunya kasus penggunaan untuk permintaan ini.

dan seharusnya tidak direkomendasikan bertahun-tahun yang lalu ketika sistem modul datang di v2. Satu-satunya waktu yang masuk akal untuk digunakan adalah di v1.

Seperti yang kita semua tahu sekarang, semua fungsi harus ditempatkan secara realistis di dalam modul, bahkan yang Anda muat sebagai bagian dari profil Anda (yang harus Anda muat modul yang berisi fungsi-fungsi ini) atau gunakan sebagai bagian dari skrip yang lebih besar untuk perawatan yang lebih mudah, atau bahkan fungsi tunggal yang perlu Anda gunakan dalam skrip xyz.

Saya hanya dapat melihat perubahan ini akan menambah lebih banyak kebingungan bagi mereka yang datang ke bahasa daripada manfaat dengan menambahkan atribut [Version] disarankan ke definisi fungsi dengan banyak pemikiran bahwa mereka akan diminta untuk mengatur versi Modul dan Fungsi ketika mereka melakukannya hal-hal dengan benar dan benar-benar membangun modul kode yang dapat digunakan kembali.

Ya ini berarti Anda harus memiliki psd1 dan psm1 tetapi 2 file untuk dapat ditemukan dan dirawat dengan benar bukanlah permintaan besar untuk dikelola

Ya, tapi ini tidak relevan. Tidak ada yang berpendapat bahwa kita seharusnya tidak membuat modul versi. ;-)

Seperti yang mungkin Anda katakan, saya pribadi _tidak setuju_ dengan perubahan ini & berpikir ada hal-hal yang lebih baik untuk difokuskan sebagai gantinya

Anda tidak akan diminta untuk menggunakannya. Anda sebenarnya tidak dipaksa untuk menggunakan [CmdletBinding()] atau set parameter.
Perintah, dan cmdlet, memiliki versi.
Jika suatu fungsi itu sendiri memiliki versi, _apakah fungsi tersebut berada di dalam modul_ atau tidak, itu hanyalah titik dokumentasi kecil, tetapi berguna. Saya telah membuat banyak modul dengan alat yang bervariasi dan tidak terkait di dalamnya yang tidak membenarkan modul masing-masing. Jika modul saya MiscStuff 1.1.0002 , itu bagus untuk bagian distribusi; saya menggunakan itu. Jika ada tiga puluh fungsi di dalamnya dan saya ingin segera mencatat apakah saya menggunakan Do-Thing 7.9.0 dan dapat menghubungkannya ke item di changelog saya (yang saya lakukan!), Saya ingin beberapa metode formal untuk melakukan ini, yang sama sekali tidak diperlukan oleh mereka yang tidak menginginkannya.

@PowerShell/powershell-committee meninjau ini, kami yakin solusi yang tepat untuk memiliki versi untuk fungsi skrip adalah dengan membungkusnya dalam sebuah modul. Juga tidak jelas seperti apa perilaku yang diharapkan jika fungsi skrip ada di dalam modul, tetapi memiliki atribut versinya sendiri. Kemudian ada kekhawatiran tentang bagian lain dari PowerShell, PowerShellGet, dan PSGallery yang perlu diperbarui untuk menghormati atribut baru ini. Jika keinginan adalah untuk dapat menyebarkan file skrip tunggal vs folder (modul), maka akan lebih baik untuk berinvestasi dalam kemampuan untuk mengimpor modul zip/nupkg secara langsung dan lebih mudah untuk mengubah .ps1 menjadi modul.

Sebagai penulis skrip admin dan bukan pengembang, menurut saya #7259 dan permintaan ini (#11667) tidak ada hubungannya satu sama lain.

Sebagai penulis skrip admin, saya TIDAK AKAN belajar cara menggunakan modul. Itu tidak relevan bagi saya. Ini memberi saya NO NILAI. Ini overhead UNTUK PENGEMBANG. Modul adalah non-starter. (Bukan hanya untuk saya, tetapi sebagian besar skrip admin.)

Untuk skrip admin dan bukan pengembang - bagaimana komite menyarankan agar pembuatan versi untuk fungsi/filter dilakukan?

Bukan untuk menentang, tapi... pembuatan versi itu sendiri adalah konsep pengembang, pada umumnya. Saya tidak yakin mengapa Anda mencoba menggambar garis ini di sini, dari semua tempat yang memungkinkan. 😕

Karena saya telah merilis lusinan fungsi dan skrip yang berdiri sendiri. Tanpa modul. Cukup yakin ini tercakup di atas dalam komentar sebelumnya dari saya, dan beberapa blogger/penerbit populer lainnya.

Saya tidak berpikir bahwa #7259 dan permintaan ini (#11667) ada hubungannya satu sama lain.

Ya saya juga tidak benar-benar mendapatkan koneksi jujur.

SAYA TIDAK AKAN belajar bagaimana menggunakan modul.

FWIW Anda cukup mengubah ekstensi menjadi psm1 dan (opsional) jalankan New-ModuleManifest . Tidak ada banyak untuk itu.

Itu tidak relevan bagi saya. Ini memberi saya NO NILAI.

Jika Anda menerbitkan sesuatu untuk dikonsumsi orang lain, itu pasti memberikan nilai. Cara kerja lingkup untuk modul membuatnya jauh lebih sulit untuk menginjak status sesi global seseorang dan sebaliknya. Itu membuat fungsi Anda secara signifikan lebih tahan terhadap perbedaan tak terduga di lingkungan.

Cara mengkonsumsinya juga lebih mudah. Jika Anda merilis fungsi sebagai skrip, orang perlu titik sumber, mereka perlu tahu di mana itu, sumber titik, lalu gunakan perintah. Jika Anda merilisnya sebagai modul, orang-orang dapat menerapkannya terlebih dahulu dan memanggilnya kapan pun mereka mau.

bagaimana komite menyarankan agar pembuatan versi untuk fungsi/filter dilakukan?

Jika pembuatan versi diterapkan untuk masing-masing fungsi, apakah Anda mengharapkan versi mereka dapat ditanyakan?

Jika ya, dapatkah Anda menjelaskan sedikit tentang skenario apa yang Anda harapkan dari pengguna untuk menanyakannya? Apakah Anda mengharapkannya untuk dimainkan di sistem lain seperti tag #requires ?

Jika itu hanya metadata yang terlihat di sumbernya maka Anda bisa meletakkannya di bagian NOTES dari bantuan berbasis komentar.

Berdasarkan kesimpulan Komite PowerShell, saya menutup masalah (hentikan pelacakan) tetapi Anda bebas untuk melanjutkan diskusi.

Ya, saya menggunakan bagian CATATAN hari ini dan $pVersion/$pName. Saya menduga sebagian besar dari kita dengan kebutuhan, melakukan itu.

Ketika saya sedang menulis "Saya tidak akan" saya berbicara tentang orang generik, bukan saya secara khusus (walaupun saya termasuk dalam kategori itu).

dan $pVersion/$pName

Apa yang Anda lakukan dengan itu? Apakah Anda memiliki contoh fungsi longgar yang telah Anda terbitkan? Itu dapat membantu dalam memahami use case.

Ketika saya sedang menulis "Saya tidak akan" saya berbicara tentang orang generik, bukan saya secara khusus (walaupun saya termasuk dalam kategori itu).

Ya pasti ada orang yang menolak untuk belajar tentang modul. Saya telah mengenal dan saat ini mengenal banyak orang seperti itu (dan telah dikatakan beberapa tahun yang lalu), tidak ada argumen bahwa mereka ada. Yang mengatakan, tumpang tindih antara orang-orang itu, dan mereka yang 1. peduli tentang versi dan 2. memiliki keinginan untuk mempublikasikan karya mereka - menurut pengalaman saya hampir nol. Secara realistis, sebagian besar orang yang mencentang kotak 1 dan 2 akan meluangkan waktu ~10 menit untuk mencari di google cara membungkus modul dengan sangat cepat sebelum mereka mempublikasikannya. Atau lebih sering, mereka tidak peduli tentang versi dan mereka hanya akan membantingnya di inti atau posting blog.

dan $pVersion/$pName

Apa yang Anda lakukan dengan itu? Apakah Anda memiliki contoh fungsi longgar yang telah Anda terbitkan? Itu dapat membantu dalam memahami use case.

Ketika saya sedang menulis "Saya tidak akan" saya berbicara tentang orang generik, bukan saya secara khusus (walaupun saya termasuk dalam kategori itu).

Ya pasti ada orang yang menolak untuk belajar tentang modul. Saya telah mengenal dan saat ini mengenal banyak orang seperti itu (dan telah dikatakan beberapa tahun yang lalu), tidak ada argumen bahwa mereka ada. Yang mengatakan, tumpang tindih antara orang-orang itu, dan mereka yang 1. peduli dengan pembuatan versi dan 2. memiliki keinginan untuk mempublikasikan karya mereka - menurut pengalaman saya _hampir_ nol. Secara realistis, sebagian besar orang yang mencentang kotak 1 dan 2 akan meluangkan waktu ~10 menit untuk mencari di google cara membungkus modul dengan sangat cepat sebelum mereka mempublikasikannya. Atau lebih sering, mereka tidak peduli tentang versi dan mereka hanya akan membantingnya di inti atau posting blog.

Saya tahu cara menggunakan modul. Saya menulis mereka sepanjang waktu. Heck, fungsi-fungsi ini sering berada di dalam modul , dan saya menggunakan versi internal sehingga saya dapat melacak apa yang terakhir diubah dalam suatu fungsi tanpa harus menarik keluar ke changelog eksternal (ke fungsi). Saya tidak mengerti mengapa .VERSION dalam suatu fungsi akan mengganggu versi modul. Aku hanya tidak.

Saya tahu cara menggunakan modul. Saya menulis mereka sepanjang waktu. Heck, fungsi-fungsi ini adalah _inside_ _modules_ banyak waktu, dan saya menggunakan versi internal sehingga saya dapat melacak apa yang terakhir diubah dalam suatu fungsi tanpa harus menarik keluar ke changelog eksternal (ke fungsi). Saya tidak mengerti mengapa .VERSION dalam suatu fungsi akan mengganggu versi modul. Aku hanya tidak.

Benar tetapi yang utama adalah: apa yang akan Anda lakukan dengan metadata itu? Apakah itu hanya sesuatu yang Anda lihat di sumber fungsi? Jika demikian, dapatkah Anda menguraikan bagaimana bagian .NOTES tidak cocok untuk itu?

Juga masalah ini adalah untuk mengizinkan fungsi mandiri untuk mendeklarasikan nomor versinya di Get-Command output. Permintaan untuk memasukkan log perubahan penuh akan menjadi implementasi yang sangat berbeda dan mungkin lebih baik dalam masalah itu sendiri.

itu mudah untuk dijawab. itu berarti saya harus membukanya di editor atau melakukan beberapa jenis pencarian string yang canggung untuk mengetahui versi yang diinstal pada komputer tertentu/lokasi tertentu di komputer tersebut. itu tidak selalu mudah seperti jawaban ini. :-)

Tidak juga?

Bidang Catatan ditampilkan di keluaran Get-Help jika Anda menulisnya sebagai bantuan berbasis komentar yang tepat (yang memang seharusnya begitu).

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

Get-Help test -Full

# or
Get-Help test | % alertSet

Hasil:

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

Jadi? Aku tidak terkesan. Ada cara lain yang lebih verbose untuk melakukan operator ternary juga. Namun ... cara yang lebih kompak diterapkan. Karena (sebagian) masyarakat menginginkannya. Saya masih tidak tahu apa itu operator penggabungan nol.

Tidak begitu yakin apa yang Anda cari, kalau begitu. Itu cukup jelas memungkinkan Anda melakukan apa yang Anda cari dengan relatif mudah. Saya tidak melihatnya sepadan dengan waktu untuk menambahkan bidang tambahan di sana.

Jika ya, silakan buka PR dan kita akan membicarakannya lebih lanjut. 🤷

PR untuk apa? Saya bukan pembuat kode C#. Saya belum menjadi pengembang profesional selama lebih dari 30 tahun.

Saya pikir beberapa dari kami sangat jelas tentang apa yang kami cari, dan kasus penggunaan kami, dan melihat kekhawatiran itu diminimalkan, seperti yang baru saja Anda lakukan lagi.

Anda yang berada di luar admin scripting berpikir "jadikan saja modul". Kebanyakan skrip admin tidak akan tahu caranya dan mereka akan mengatakan (dan saya akan setuju) bahwa itu terlalu banyak masalah setelah mereka melihat persyaratannya.

Tapi ini tidak ada gunanya dan saya tahu lebih baik. Kesimpulan Komite PowerShell sudah tercapai. Maaf saya berkomentar.

Kesimpulan Komite PowerShell sudah tercapai.

Kesimpulan sampingan apa pun dapat dipertimbangkan kembali berdasarkan umpan balik.

Saya pikir beberapa dari kami sangat jelas tentang apa yang kami cari, dan kasus penggunaan kami, dan melihat kekhawatiran itu diminimalkan, seperti yang baru saja Anda lakukan lagi.

Saya telah berusaha sangat keras untuk memahami apa tujuan sebenarnya dan kasus penggunaan dan pertanyaan saya sebagian besar diabaikan. Saya sangat ingin mengerti.

Anda yang berada di luar admin scripting

Saya seorang sysadmin. Sebagian besar karir saya dihabiskan dengan berpikir bahwa sintaks hashtable adalah "sintaks percikan". Sebagian besar rekan kerja saya hanya mengetahui dasar-dasar mutlak PowerShell (jika ada), sama dengan sebagian besar orang yang saya bantu di discord/reddit.

Saya mengerti bahwa Anda memiliki beberapa daging sapi dengan tim pengembang PS, tapi tolong jangan berpura-pura seperti saya tidak mungkin memahami perspektif Anda karena kebetulan saya tahu C# sekarang. Saya terus berjuang untuk perspektif itu pada repo ini.

berpikir "jadikan saja modul". Kebanyakan skrip admin tidak akan tahu caranya dan mereka akan mengatakan (dan saya akan setuju) bahwa itu terlalu banyak masalah setelah mereka melihat persyaratannya.

Bagi siapa saja yang menemukan utas ini nanti dan enggan membuat modul, berikut adalah persyaratannya:

1. Ganti nama file .ps1 menjadi .psm1
2. Gunakan Import-Module ./file.psm1 sebagai ganti . ./file.ps1

Itu saja, Anda punya modul. Yang lainnya hanyalah praktik terbaik yang belum perlu Anda khawatirkan. Jika Anda ingin membuat versi, Anda memerlukan manifes, berikut persyaratan lengkapnya:

1. Ganti nama file .ps1 menjadi .psm1
2. Jalankan New-ModuleManifest -RootModule ./file.psm1 -Path ./file.psd1 -ModuleVersion 1.0.0
3. Gunakan Import-Module ./file.psd1 sebagai ganti . ./file.ps1

Jika Anda mengirimkan fungsi longgar di ps1 yang konsumen (atau diri Anda sendiri) perlu sumber titik, masukkan saja ke dalam modul dengan sangat cepat itu akan membuat hidup Anda lebih mudah.

Jika Anda mengirimkan skrip yang dapat dipanggil secara langsung, Anda dapat menggunakan New-ScriptFileInfo yang akan menghasilkan file skrip dengan komentar seperti ini:

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

Dan Anda dapat menanyakannya dengan Test-ScriptFileInfo .