الرجاء إضافة معلومات كيف تريد تحسين لغة PowerShell لإضافة الإصدار. في السمة cmdletbinding؟

كان تفكيري أن أفعل شيئًا مثل New-ScriptFileInfo الذي ينشئ رأس تعليق مثل هذا:

<#PSScriptInfo

.VERSION 1.0

.GUID 66c837b7-6478-4571-9dec-0621e13df4c3

.AUTHOR Jeff

.COMPANYNAME

.COPYRIGHT 2020

.TAGS

.LICENSEURI

.PROJECTURI

.ICONURI

.EXTERNALMODULEDEPENDENCIES 

.REQUIREDSCRIPTS

.EXTERNALSCRIPTDEPENDENCIES

.RELEASENOTES


.PRIVATEDATA

#>

<# 

.DESCRIPTION 
 This is a cool function 

#> 
Param()

اجعله PSFunctionInfo واجعل Get-Command يحللها. أو بنفس الطريقة التي يستطيع بها PowerShell تحليل #requires ، اطلب منه تحليل #version. حيث يصبح الأمر صعبًا عندما يكون لديك وظائف متعددة في نفس ملف ps1 ، لذا فإن أي شيء سأفعله كمؤلف وظيفة ، يجب أن يتم تضمينه في الوظيفة. قد يكون هذا عبارة عن كتلة تعليق تم تحليلها ، أو خيار cmdletbinding () جديد ، أو ربما سمة جديدة بالكامل.

Function Get-Awesomeness {

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

 Param ()

 ...
}

لا أرى قيمة من هذه الميزة. يمكننا النشر على PowerShellGet وتوزيع برامج PowerShell النصية كوحدات نمطية فقط ، ولا يمكننا القيام بذلك للملفات. هل يمكنك وصف حالة العمل / سير العمل؟

هناك العديد من الأشخاص الذين قاموا بإنشاء حلول PowerShell التي لم يتم نشرها مطلقًا في المعرض. يتم استخدامها داخليًا ، على سبيل المثال في بيئة الشركات. ولا يتم تجميع كل شيء في وحدة نمطية. قد أعمل في بيئة شركة ولدي ملف نصي مستقل مع وظيفة. أريد القدرة على تتبع الإصدار الخاص بهذه الوظيفة. إذا قمت بتشغيل Get-Command Get-CompanyFoo ، فأنا بحاجة إلى أن أتمكن من رؤية رقم الإصدار. لهذه المسألة ، حتى في الوحدة النمطية ، تشترك جميع الوظائف المصدرة في رقم الإصدار نفسه. أرغب في الحصول على وسيلة لتتبع معلومات الإصدار على أساس كل وظيفة. وطبعًا دون الحاجة إلى الاعتماد على قراءة الكود المصدري. إذا كان أحد فنيي مكتب المساعدة يستخدم إحدى وظائفي ، فيجب أن يكونوا قادرين على استخدام PowerShell لاكتشاف إصدار الأمر.

بالتأكيد ، ليست كل وظيفة تحتاج إلى هذا ، حتى تلك الموجودة في الوحدة. ليست لدي مشكلة مع وظيفة في وحدة نمطية تستخدم إصدار الوحدة النمطية إذا لم يتم اكتشاف إصدار خاص بأمر.

تضمين التغريدة

أرى عنصرين في السيناريو الخاص بك - (1) نظام تتبع الإصدار ، (2) نظام التوزيع.
يمكن أن يكون أول واحد هو GIT (الآخرين؟).
ليس من الواضح كيف تقوم بتوزيع ملفات البرامج النصية.

(أحاول فهم المكان المناسب للسمة المطلوبة.)

أترك الوظائف لدى العملاء بشكل منتظم ، والتي تكون سارية اعتبارًا من آخر مرة استخدمتها لدى هذا العميل المحدد. واحد استخدمته في أحد العملاء اليوم يتبادر إلى الذهن - getWUlog. إنه يعرف كيفية الاتصال بنظام بعيد باستخدام كل من WinRM و psexec (يتحقق لمعرفة ما إذا كان 139 أو 5985 مفتوحًا) ويسترجع سجل WindowsUpdate من هذا الكمبيوتر ، واستعادته إلى الكمبيوتر المحلي ، وفتح المفكرة.

آخر هو getFrameworkVersion. يفعل ذلك بالضبط - يبحث عن إصدار .NET Framework المثبت على جهاز كمبيوتر معين ، باستخدام إما CIM أو خدمة التسجيل عن بعد (مرة أخرى - يتحقق من المنافذ لمعرفة ما يجب فعله) ، ويبلغ عن ذلك ، ويبلغ عن الإصدارات المحظورة ، لو اي.

هذه وظائف قائمة بذاتها. ليس جزءًا من وحدة. لكنهم مروا بتحديثات منتظمة على مدى السنوات القليلة الماضية.

سيكون من الرائع إرفاق نسخة لكل منهم. في الوقت الحالي ، لدي "تاريخ آخر تعديل" أعلى المصدر. ليس مفيدا ...

التوزيع لا علاقة له في ذهني بهذه المناقشة. ونعم ، تلعب git دورًا ولكنها ليست المشكلة. إذا كنت في PowerShell وأنا أستخدم وظيفة قائمة بذاتها. عندما أقوم بتشغيل Get-Command Get-Foo ، أريد رؤية رقم إصدار الوظيفة. انها بسيطة على هذا النحو. لا يهم كيف تم توزيع الوظيفة. أعطني طريقة لإدخال البيانات الوصفية في الوظيفة.

ولكي أكون واضحًا تمامًا ، لا أريد إجبار المستخدم ، أو حتى نفسي ، على تعقب المصدر والبحث عن التعليقات أو الملاحظات.

أنا أكتب / أستخدم بعض الوظائف المستقلة ، لكن معظمها في وحدات. ومعظم هذه الأدوات عبارة عن أدوات طافية عشوائية يمكن استخدامها كوظائف قائمة بذاتها. دائمًا ما أضع الإصدارات الدلالية وسجلات التغيير في .NOTES داخل كتلة التعليقات ، و [version]$Version في كتلة البداية ، لأنني أريد أن أتابع التغييرات التي أجريتها على وظيفة معينة ، وليس فقط إلى الوحدة (التي أقوم بزيادتها عند إجراء تغييرات على الوظائف الداخلية). الحصول على شيء مثل [version()] أو [cmdletbinding(Version='01.00.0000')] سيكون أمرًا مذهلاً ؛ أحبه أفضل من الإصدار. لأنني أعرف أن الكثير من الأشخاص وضعوا وظائف متعددة في ملف psm1 (على الرغم من أنني لا أفعل ذلك).
أستخدم git ، أيضًا ، بالمناسبة ، لكنني لا ألتزم في كل مرة أقوم فيها بإجراء تغيير على وظيفة فردية ؛ أقوم بتجميعها والتزامها عندما أقوم بتغيير الوحدة ، وعادةً ما يكون إصدار الوحدة كرسالة الالتزام. نعم ، أجل ، أعلم ، أنا غريب.

إذا تم العثور على البرنامج النصي في $env:PATH ، فإنه يظهر لـ Get-Command. لذلك يبدو من المعقول تعيين بيانات تعريف ScriptFileInfo الحالية لأعضاء ExternalScriptInfo الذي يتضمن الإصدار.

كن حذرا مع هذا الافتراض ستيف. قد يكون لدي ملف ps1 واحد بوظائف متعددة. لا أريد أن أثق في أن Get-Command يمكنه العثور على ملف البرنامج النصي. هيك ، قد أرغب في تحديد وظيفة ذات إصدار في برنامج نصي لملف تعريف PowerShell.

بالتأكيد لديك وظائف ذات إصدارات في البرنامج النصي لملف التعريف الخاص بي.

لدينا بالفعل نوع System.Management.Automation.FunctionInfo الذي له خاصية الإصدار. نحتاج إلى طريقة بحيث يتم ملء خاصية الإصدار من البيانات الوصفية في الوظيفة عند تحميل الوظيفة.

شكرا لكم جميعا على ردود الفعل الرائعة! لا يزال لدي بعض الأسئلة. ما السلوك الذي تتوقعه إذا عثر PowerShell على بعض الوظائف بنفس الاسم؟ تشغيل الوظيفة بإصدار أعلى؟ هل يجب أن نأخذ في الاعتبار النطاقات (تقوم بتحميل الوظيفة القديمة في النطاق الحالي - هل يجب علينا استدعاء المزيد من الوظائف الجديدة من النطاق العالمي)؟ أم نريد أن يكون لدينا سمة إعلامية فقط؟

لا يتعلق الأمر بتشغيل أو توزيع الوظائف. كل ما أريده هو آلية لتوفير طريقة لتتبع واكتشاف معلومات الإصدار بحيث إذا قمت بتشغيل Get-Command ، أو ربما أمرًا جديدًا مثل Get-Function ، يمكنني رؤية بعض البيانات الوصفية حول الوظيفة. لدي بعض الأفكار التي قد أحاول صنع نموذج أولي لها من خلال برمجة PowerShell النصية.

شكرا لكم جميعا على ردود الفعل الرائعة! لا يزال لدي بعض الأسئلة. ما السلوك الذي تتوقعه إذا عثر PowerShell على بعض الوظائف بنفس الاسم؟ تشغيل الوظيفة بإصدار أعلى؟ هل يجب أن نأخذ في الاعتبار النطاقات (تقوم بتحميل الوظيفة القديمة في النطاق الحالي - هل يجب علينا استدعاء المزيد من الوظائف الجديدة من النطاق العالمي)؟ أم نريد أن يكون لدينا سمة إعلامية فقط؟

لا أعتقد أن أي شخص قد اقترح أي تغيير في طريقة تنفيذ PS للوظائف. نريد فقط أن نضع نسخة عليها. إعلامي وطريقة لاستجواب نفسه.

شكرا! السؤال التالي لدي. يمكن أن يحتوي الملف الذي يحتوي على بعض الوظائف على سمة إصدار مشتركة لجميع الوظائف الموجودة في الملف. هل يجب أن نعتبر هذا؟

لدي بعض الأفكار التي قد أحاول صنع نموذج أولي لها من خلال برمجة PowerShell النصية.

يمكنك مشاركة الأفكار في جوهرها.

هذه خطتي.

هل يجب أن يكون الإصدار الكلاسيكي أم SymVer 2.0؟

لقد أصبحت مقتنعًا بشكل متزايد بأن إصدار الوظائف أمر جيد.

للإجابة على أحدث سؤال iSazonov - إذا أردنا الحصول عليه ، فلماذا لا نستخدم SymVer؟

وفيما يتعلق بملف الوظائف - أود أن أزعم أن السمة لكل دالة بدون سمات لكل ملف. يشبه إلى حد كبير أعمال الربط CMDLET اليوم.

تم سحب النموذج الأولي في ## 11686

يمكنك تنزيل قطعة أثرية من العلاقات العامة واللعب بسمة جديدة.

حلو.

التفكير في الأمر - لماذا لا تقوم بتمديد سمة PSVersionAttribute لتشمل إصدار البرنامج النصي. إذا قمنا بإصدار وحدات ووظائف (نأمل الآن!) ، فلماذا لا نصنع البرامج النصية؟

يمكن أيضًا أن تعمل PSVersionAttribute كقيمة افتراضية للوظائف المحددة في البرنامج النصي.

وقبل أن يسأل أي شخص آخر ... هل يمكن تعديل إصدار تنفيذ الوظيفة؟

يمكننا تحميل إصدارات متعددة من الوظيفة ، وتنفيذ الأحدث بشكل افتراضي ، ولكن لدينا معلمة مشتركة PSFunctionVersion تحدد الإصدار المحدد المطلوب تشغيله.
لا شك أن هناك المزيد من البدائل - ولكن هل ينبغي لنا توفير تنفيذ وظيفة ذات إصدار؟

إذا كانت إحدى السمات ، يمكنك دائمًا إعادة استخدامها ، تمامًا مثل كيفية تطبيق [CmdletBinding()] على كل من الوظائف والنصوص ، يمكنك دائمًا استخدام [PSVersion()] لكلٍ من الوظائف والنصوص. هذا يبدو وكأنه نهج مثير للاهتمام. 🙂

لا أتوقع الكثير من استخدام هذا النوع من الأشياء في الوحدات النمطية ، حيث لدينا بالفعل كود إصدار للجزء الأكبر ، ولكن بالنسبة للنصوص والوظائف المستقلة ، قد يكون هذا مثيرًا للاهتمام حقًا 🙂

لا يتعلق الأمر بتشغيل أو توزيع الوظائف. كل ما أريده هو آلية لتوفير طريقة لتتبع واكتشاف معلومات الإصدار بحيث إذا قمت بتشغيل Get-Command ، أو ربما أمرًا جديدًا مثل Get-Function ، يمكنني رؤية بعض البيانات الوصفية حول الوظيفة. لدي بعض الأفكار التي قد أحاول صنع نموذج أولي لها من خلال برمجة PowerShell النصية.

إذا أردنا إضافة إصدارات الوظيفة ، فلماذا نحصرها في الوثائق البحتة؟ إذا كان بإمكاني تحديد إصدارات الوظائف والاستعلام عنها ، ألن يكون من المعقول السماح بالتنفيذ بناءً على رقم الإصدار؟

إما طريقة لتحميل إصدارات متعددة من الوظيفة وتكون قادرًا على اختيار الإصدار المطلوب تنفيذه ، أو تمكين المستخدم من الاختيار من بين الإصدارات المختلفة لتحميلها في قائمة الوظائف التي نراها مع gcm ثم تنفيذها.

إذن ، هذا دليل على المفهوم الذي عملت عليه بناءً على أوامر ScriptFileInfo:
https://gist.github.com/jdhitsolutions/65070cd51b5cfb572bc6375f67bcbc3d

ما أحاول حقًا أن أصممه أو أنموذج أولي هو التجربة. أفضل عرض البيانات باستخدام Get-Command ، لأن هناك نوعًا مناسبًا بالفعل.

والحصول على مزيج من الملفات.

إذا كانت إحدى الوظائف تنتمي إلى وحدة نمطية ، فلن أزعجني بإصدار الأوامر. يجب التعامل مع ذلك من خلال الوحدة.

جوهر

دليل على المفهوم لإضافة معلومات بيانات تعريف PowerShell والحصول عليها

دليل على المفهوم لإضافة معلومات البيانات الوصفية لـ PowerShell والحصول عليها - PSFunctionInfo.format.ps1xml

لطيف جيف!

إذن كيف نتعامل مع إصدارات متعددة من نفس الوظيفة؟
كيف يمكن للمرء تحميل إصدار وظيفي محدد بشكل صريح؟
كيف يمكن للفرد أن ينفذ صراحةً إصدارًا محددًا من الوظيفة؟

doctordns أنت مسؤول عن معرفة ما يجب تشغيله والتعامل مع إصدارات متعددة. رمز النموذج الأولي الخاص بي هو ببساطة سرد العناصر في FunctIon: Psdrive وعرض معلومات البيانات الوصفية. بقدر ما أعرف ، لا يمكنك الحصول على وظائف مكررة في psdrive. كان هدفي ، إذا كان لدي وظيفة قائمة بذاتها تم تحميلها ، فأنا أريد أن أكون قادرًا على استرداد الإصدار وربما معلومات البيانات الوصفية الأخرى.

بينما أعتقد أنه سيكون من الرائع أن يدعم PowerShell البيانات الوصفية _embedded_ PSScriptInfo لـ _scripts_ ... يرجى عدم القيام بذلك على مستوى _function_.

تكون الإصدارات مفيدة فقط إذا كان بإمكانك فعل شيء حيالها

يقوم PowerShell حاليًا _ بإبلاغ الإصدار الموجود على الأوامر ، ولكن الإصدار الفعلي يأتي من _module_. لن يكون وجود إصدارات منفصلة لكل وظيفة مفيدًا ، سيكون محيرًا فقط. بغض النظر عن كيفية توزيع الكود الخاص بك ، فأنت لا تقوم بتوزيع "مجموعات" الملفات الفرعية ولا يمكن للمستخدم تحميل وظيفة فردية (أو أي شيء باستثناء ملف كامل) - لذلك لا فائدة من محاولة إصدارها.

أعتقد أننا بحاجة إلى إصدارات للوحدات والنصوص. يجب أن ترث الدوال نسختها من _module_ التي تحتوي عليها. البرامج النصية تحتاج إلى نسختها الخاصة.

للتسجيل:

إذا كان لديك ملف .ps1 به وظائف متعددة ، فأنت بحاجة إلى تغيير الامتداد. إذا لم تقم بذلك ، فلن يكون لدى المستخدمين طريقة لاكتشاف هذه الوظائف على أي حال ، لذلك لن يكون تعيين الإصدار مهمًا. يجب أن نثني بشدة أي شخص يحاول توزيع _الوظائف_ في أي شيء عدا الوحدة. 🤨

Jaykul أوافق على أنه إذا كانت الوظيفة

Jaykul أعتقد أن العديد منا قد قالوا بالفعل إنه سيكون مفيدًا لنا بالفعل وأننا نقوم بالفعل بتوزيع وظائف فردية.

IMO ، ليس كل شيء يحتاج إلى وحدة.

قد لا تكون الميزة المقترحة مفيدة لك. وهذا جيد. لكنها للآخرين منا.

تعجبني فكرة تعيين الإصدار للوظيفة. ولكن إذا قمنا بحل ، فيجب أن يكون أكثر من مجرد وثائق صغيرة يمكنك القيام بها في التعليقات دون القدرة على التحكم في تحميل إصدارات مختلفة وما إلى ذلك ، فهذه ميزة قد نتمكن من الاستغناء عنها في الوقت الحالي.

أقترح أن نتخلى عن هذه الفكرة لـ 7.0. نحن قريبون جدًا من RTM لدفع ميزات جديدة إلى هذا المزيج. لدي ذكريات سيئة عن أيام NT 5 !! إذا تمكنا من إعادة هذا إلى 7.1 ، فلنجري محادثة أكمل حول كيفية تنفيذه بالكامل. محاولة دفع هذا الأمر في اللحظة الأخيرة هي طريقة مؤكدة للتسبب في خيبة الأمل.

إذا حدث هذا فهو إضافة 7.1. أعتقد أن مسألة تحميل الإصدار الصحيح متروك للمستخدم. مرة أخرى ، كل ما أطلبه هو طريقة لاسترداد معلومات الإصدار من وظيفة مستقلة محملة دون الحاجة إلى البحث في المصدر.

أوافق على 7.1.

في الوقت نفسه ، أنا أعرف المستخدمين ، وسأراهن بزجاجة أو ثلاثة أن حل التوثيق لن يؤدي إلا إلى إنشاء طلبات لميزات وقت التشغيل القائمة على الإصدار. أود منا أن نفكر في حل كامل وأنيق ومصمم جيدًا. .

لدينا بالفعل حل للوظائف المستقلة - آخر واحد تم تحميله يفوز. :-)

بدون القدرة على التحكم في تحميل الإصدارات المختلفة وما إلى ذلك ، فهذه ميزة قد نتمكن من الاستغناء عنها في الوقت الحالي.

هذا سيجبرنا على التحقق من إصدار الوظيفة في كل مرة يتم استدعاؤها. هذا غير مقبول تمامًا لأسباب تتعلق بالأداء. أفضل حل وسط هو الوحدة - يتم فحص الإصدار مرة واحدة عند تحميل الوحدة.

@ SteveL-MSFT أعتقد أنه جاهز لاستنتاج لجنة PowerShell. النموذج الأولي # 11686.

يبدو أن الجميع متفقون على أن إصدار البرامج النصية مفيد في المحرك.
إصدار الوظائف قيد السؤال لأن مفهوم الوحدة موجود.

القيد الشائع هو أنه يمكننا فقط رؤية إصدارات البرامج النصية والوظائف المحملة ولا يمكننا القيام بذلك - تحميل الإصدار المطلوب ولكن get-module لا يحتوي أيضًا على معلمات إصدار صريحة.

لا تفرط في التفكير في هذا أو تجعله أكثر تعقيدًا مما يجب أن يكون. الوظائف المشحونة مع الوحدات تنتمي إلى الوحدة. نقطة. يجب أن تكون أفضل الممارسات الموصى بها. ومع ذلك ، لا يتم نشر كل وظيفة يمكن استخدامها في الإنتاج مع وحدة نمطية. أنا لا أهتم في الواقع بكيفية نشرها. كل ما أقوله هو أنني أريد طريقة لإلقاء نظرة على دالة محملة في الوظيفة: PSDrive وتكون قادرًا على رؤية رقم الإصدار ، وربما بعض معلومات البيانات الوصفية الأخرى. لا أرغب في إجبار نفسي أو المستخدم النهائي على تعقب رمز المصدر أو المجلد لاكتشاف معلومات الإصدار.

كنت آمل أن تكون Get-Command هي الأداة لجمع هذه المعلومات ، ولكن ربما يحتاج هذا إلى أن يتم تحويله إلى شيء منفصل تمامًا لإدارة الوظائف المستقلة.

وربما يكون الجواب هو أنه من الأفضل ترك هذه المشكلة للمجتمع لحلها. في هذه الحالة ، أعتقد أن لدي بداية جيدة للتوصل إلى حل.

الحقيقة الصادقة هنا هي أن وظائف تحديد مصادر النقاط ليست الطريقة الصحيحة للذهاب ، ولا ينبغي التوصية بها طوال تلك السنوات السابقة عندما جاء نظام الوحدة في الإصدار 2. المرة الوحيدة التي كان فيها الاستخدام معقولاً عن بعد كانت في الإصدار 1.

كما نعلم جميعًا الآن ، يجب وضع جميع الوظائف بشكل واقعي داخل وحدة نمطية ، حتى تلك التي تقوم بتحميلها كجزء من ملف التعريف الخاص بك (والذي يجب عليك تحميل الوحدة التي تحتوي على هذه الوظائف) أو استخدامها كجزء من برنامج نصي أكبر لتسهيل الصيانة ، أو حتى تلك الوظائف الفردية التي تحتاج إلى استخدامها في نصوص xyz.

أستطيع أن أرى فقط أن هذا التغيير سيضيف مزيدًا من الارتباك لأولئك الذين يأتون إلى اللغة أكثر من الفائدة من خلال إضافة السمة المقترحة [Version] لتعريفات الوظائف مع التفكير في أنهم سيُطلب منهم تعيين إصدارات الوحدة والوظيفة عند قيامهم بذلك الأشياء بشكل صحيح وبناء وحدات من التعليمات البرمجية القابلة لإعادة الاستخدام.

نعم ، هذا يعني أنه يجب أن يكون لديك ملف psd1 و psm1 ، لكن ملفين لإمكانية الاكتشاف والصيانة المناسبة ليس طلبًا ضخمًا للإدارة حقًا

كما قد تقول ، أنا شخصياً لا أتفق مع هذا التغيير وأعتقد أن هناك أشياء أفضل يجب التركيز عليها بدلاً من ذلك

نعم ، هذا يعني أنه يجب أن يكون لديك ملف psd1 و psm1 ، لكن ملفين لإمكانية الاكتشاف والصيانة المناسبة ليس طلبًا ضخمًا للإدارة حقًا

نعم ، إنه طلب ضخم. محاولة تحويل برامج نصية المسؤول إلى مطورين ترفع بشكل كبير من حاجز الدخول.

إن قول "عليك نسخ هذا هنا ونسخه هناك ثم استيراده" أكثر تعقيدًا بكثير وأكثر عرضة للخطأ بكثير من قول "انسخ والصق هذا في ملف باسم run.ps1 ثم اكتب ، \ تشغيل .ps1 ".

يعد هذا تغييرًا طفيفًا وسيستفيد منه المبرمجون العرضيون / المسؤولون أكثر بكثير من المشغلين الثلاثي أو الاندماج الصفري (الذي ما زلت لا أفهمه) أو الكثير من التغييرات الحديثة الأخرى التي تم إجراؤها لمن هم مطورو منكم. كما قيل عن هؤلاء ، يمكنني أن أقول عن إصدارات الوظائف: إذا لم تعجبك ، فلا تستخدمها.

@ SteveL-MSFT أعتقد أن لجنة PowerShell يمكنها النظر في الطلب لدعم إصدارات النصوص والوظائف المستقلة. النموذج الأولي في # 11686.

الحقيقة الصادقة هنا هي أن وظائف تحديد مصادر النقاط ليست الطريقة الصحيحة للذهاب ،

لكن الناس يفعلون ذلك ، وهي ليست حالة الاستخدام الوحيدة لهذا الطلب على أي حال.

ولا ينبغي التوصية به طوال تلك السنوات السابقة عندما جاء نظام الوحدة في الإصدار 2. المرة الوحيدة التي كان فيها الاستخدام معقولاً عن بعد كانت في الإصدار 1.

كما نعلم جميعًا الآن ، يجب وضع جميع الوظائف بشكل واقعي داخل وحدة نمطية ، حتى تلك التي تقوم بتحميلها كجزء من ملف التعريف الخاص بك (والذي يجب عليك تحميل الوحدة التي تحتوي على هذه الوظائف) أو استخدامها كجزء من برنامج نصي أكبر لتسهيل الصيانة ، أو حتى تلك الوظائف الفردية التي تحتاج إلى استخدامها في نصوص xyz.

أستطيع أن أرى فقط أن هذا التغيير سيضيف مزيدًا من الارتباك لأولئك الذين يأتون إلى اللغة أكثر من الفائدة من خلال إضافة السمة المقترحة [Version] لتعريفات الوظائف مع التفكير في أنهم سيُطلب منهم تعيين إصدارات الوحدة والوظيفة عند قيامهم بذلك الأشياء بشكل صحيح وبناء وحدات من التعليمات البرمجية القابلة لإعادة الاستخدام.

نعم ، هذا يعني أنه يجب أن يكون لديك ملف psd1 و psm1 ، لكن ملفين لإمكانية الاكتشاف والصيانة المناسبة ليس طلبًا ضخمًا للإدارة حقًا

نعم ، لكن هذا غير مناسب. لا أحد يجادل بأنه لا ينبغي لنا نسخ الوحدات النمطية. ؛-)

كما قد تقول ، أنا شخصيًا _ لا أوافق_ على هذا التغيير وأعتقد أن هناك أشياء أفضل يجب التركيز عليها بدلاً من ذلك

لن تكون مطالبًا باستخدامه. أنت لست مجبرًا على استخدام [CmdletBinding ()] أو مجموعات المعلمات أيضًا.
الأوامر و cmdlets لها إصدارات.
إذا كانت الوظيفة نفسها تحتوي على إصدار ، سواء أكانت الوظيفة المذكورة موجودة أم لا داخل وحدة نمطية ، فهي مجرد نقطة توثيق ثانوية ولكنها مفيدة. لقد أنشأت العديد من الوحدات النمطية بأدوات متنوعة وغير ذات صلة لا تبرر الوحدات الفردية الخاصة بها. إذا كانت الوحدة النمطية الخاصة بي هي MiscStuff 1.1.0002 ، فهذا رائع لجزء التوزيع ؛ أنا أستخدم ذلك. إذا كانت هناك ثلاثون وظيفة بداخلها وأريد أن ألاحظ بسرعة ما إذا كنت أستخدم Do-Thing 7.9.0 وأكون قادرًا على ربطها بعنصر في سجل التغيير الخاص بي (وهو ما أفعله!) ، فأنا أرغب في بعض الطرق الرسمية لـ القيام بذلك ، والذي لن يكون مطلوباً بأي حال من الأحوال من قبل أولئك الذين لا يرغبون في ذلك.

قامت @ PowerShell / بوويرشيل-جنة بمراجعة هذا ، ونعتقد أن الحل المناسب للحصول على إصدار لوظائف البرنامج النصي هو لفها في وحدة نمطية. كما أنه ليس من الواضح ما هو السلوك المتوقع إذا كانت وظيفة البرنامج النصي داخل وحدة نمطية ، ولكن لها سمة الإصدار الخاصة بها. ثم هناك قلق بشأن الأجزاء الأخرى من PowerShell و PowerShellGet و PSGallery التي قد تحتاج إلى تحديث لاحترام هذه السمة الجديدة. إذا كانت الرغبة هي أن تكون قادرًا على تمرير ملف نصي واحد مقابل مجلد (وحدة) ، فسيكون من الأفضل الاستثمار في القدرة على استيراد وحدة zip / nupkg مباشرة ويسهل تحويل ملف .ps1 إلى وحدة نمطية.

بصفتي كاتبًا مشرفًا وليس مطورًا ، لا أعتقد أن # 7259 وهذا الطلب (# 11667) لهما علاقة ببعضهما البعض.

بصفتي كاتبًا مشرفًا ، لن أتعلم كيفية استخدام الوحدات. لا يهمني. إنه لا يوفر لي أي قيمة. انها النفقات العامة للمطورين. الوحدات ليست بداية. (ليس فقط بالنسبة لي ، ولكن معظم المبرمجين في البرامج النصية.)

بالنسبة لمصممي البرامج النصية للمشرفين وليس للمطورين - كيف تقترح اللجنة إجراء إصدار للوظائف / المرشحات؟

لا يجب أن تكون متعارضًا ، ولكن ... إصدار نفسه هو مفهوم مطور ، إلى حد كبير. لست متأكدًا من سبب محاولتك رسم هذا الخط هنا ، من بين جميع الأماكن الممكنة. 😕

لأنني أصدرت العشرات من الوظائف والبرامج النصية المستقلة. بدون وحدات. متأكد تمامًا من أن هذا تمت تغطيته أعلاه في تعليقات سابقة مني والعديد من المدونين / الناشرين المشهورين.

لا أعتقد أن # 7259 وهذا الطلب (# 11667) لهما علاقة ببعضهما البعض.

نعم ، أنا لا أفهم حقًا الاتصال أيضًا لأكون صادقًا.

لن أتعلم كيفية استخدام الوحدات.

FWIW قمت بتغيير الامتداد إلى psm1 و (اختياريًا) قم بتشغيل New-ModuleManifest . ليس هناك الكثير لها.

لا يهمني. إنه لا يوفر لي أي قيمة.

إذا كنت تنشر شيئًا ما ليستهلكه الآخرون ، فمن المؤكد أنه يوفر قيمة. إن الطريقة التي تعمل بها النطاقات للوحدات النمطية تجعل من الصعب جدًا الدخول في حالة الجلسة العالمية لشخص ما والعكس صحيح. هذا يجعل وظيفتك أكثر مرونة بشكل ملحوظ في مواجهة الاختلافات غير المتوقعة في البيئات.

كما أنه أسهل طريقة للاستهلاك. إذا قمت بتحرير وظيفة كبرنامج نصي يحتاج الناس إلى تحديد المصدر ، فإنهم بحاجة إلى معرفة مكانه ، ووضع نقطة في مصدره ، ثم استخدام الأمر. إذا قمت بتحريرها كوحدة نمطية ، فيمكن للأشخاص نشرها مسبقًا والاتصال بها وقتما يريدون.

كيف تقترح اللجنة أن يتم إصدار الوظائف / المرشحات؟

إذا تم تنفيذ تعيين الإصدار للوظائف الفردية ، فهل تتوقع أن يكون إصدارها قابلاً للاستعلام؟

إذا كانت الإجابة بنعم ، فهل يمكنك توضيح السيناريو الذي تتوقع أن يقوم المستخدم بالاستعلام عنه؟ هل تتوقع أن يتم تشغيله في أي أنظمة أخرى مثل علامات #requires ؟

إذا كانت البيانات الوصفية مرئية في المصدر ، فيمكنك وضعها في قسم NOTES للمساعدة القائمة على التعليقات.

استنادًا إلى استنتاج لجنة PowerShell ، أغلقت المشكلة (إيقاف التتبع) ولكن لك مطلق الحرية في مواصلة المناقشة.

نعم ، أستخدم قسم الملاحظات اليوم و $ pVersion / $ pName. أظن أن معظمنا بحاجة إلى القيام بذلك.

عندما كنت أكتب "لن أفعل" كنت أتحدث عن الشخص العام ، وليس عني على وجه التحديد (على الرغم من أنني ضمن هذه الفئة).

و $ pVersion / $ pName

ماذا تفعل مع هؤلاء؟ هل لديك مثال على وظيفة فضفاضة نشرتها؟ قد يساعد ذلك في فهم حالة الاستخدام.

عندما كنت أكتب "لن أفعل" كنت أتحدث عن الشخص العام ، وليس عني على وجه التحديد (على الرغم من أنني ضمن هذه الفئة).

نعم ، هناك بالتأكيد أشخاص يرفضون التعرف على الوحدات. لقد عرفت وأعرف حاليًا الكثير من الأشخاص من هذا القبيل (وقد قيل إنهم قوم منذ بضع سنوات) ، ولا توجد حجج على وجودهم. ومع ذلك ، فإن التداخل بين هؤلاء الأشخاص ، وأولئك الذين يهتمون بالإصدار و 2. لديهم أي رغبة في نشر عملهم - في تجربتي هو صفر تقريبًا . من الناحية الواقعية ، سيستغرق معظم الأشخاص الذين حددوا المربعين 1 و 2 حوالي 10 دقائق في البحث في Google عن كيفية الالتفاف في وحدة نمطية بسرعة حقيقية قبل نشرها. أو في كثير من الأحيان ، لا يهتمون بإصدار الإصدار وسوف يقومون فقط بإغلاقه في جوهر أو منشور مدونة.

و $ pVersion / $ pName

ماذا تفعل مع هؤلاء؟ هل لديك مثال على وظيفة فضفاضة نشرتها؟ قد يساعد ذلك في فهم حالة الاستخدام.

عندما كنت أكتب "لن أفعل" كنت أتحدث عن الشخص العام ، وليس عني على وجه التحديد (على الرغم من أنني ضمن هذه الفئة).

نعم ، هناك بالتأكيد أشخاص يرفضون التعرف على الوحدات. لقد عرفت وأعرف حاليًا الكثير من الأشخاص من هذا القبيل (وقد قيل إنهم قوم منذ بضع سنوات) ، ولا توجد حجج على وجودهم. ومع ذلك ، فإن التداخل بين هؤلاء الأشخاص ، وأولئك الذين يهتمون بالإصدار و 2. لديهم أي رغبة في نشر أعمالهم - في تجربتي هي _ تقريبًا_ صفر. من الناحية الواقعية ، سيستغرق معظم الأشخاص الذين حددوا المربعين 1 و 2 حوالي 10 دقائق في البحث في Google عن كيفية الالتفاف في وحدة نمطية بسرعة حقيقية قبل نشرها. أو في كثير من الأحيان ، لا يهتمون بإصدار الإصدار وسوف يقومون فقط بإغلاقه في جوهر أو منشور مدونة.

أعرف كيفية استخدام الوحدات. أنا أكتبهم طوال الوقت. هيك ، هذه الوظائف موجودة داخل الوحدات النمطية في كثير من الأحيان ، وأنا أستخدم الإصدار الداخلي حتى أتمكن من تتبع آخر تغيير في وظيفة دون الحاجة إلى الانسحاب إلى سجل تغيير خارجي (للوظيفة). لا أرى سبب تداخل .VERSION في إحدى الوظائف مع إصدار الوحدة النمطية. أنا فقط لا أفعل.

أعرف كيفية استخدام الوحدات. أنا أكتبهم طوال الوقت. هيك ، هذه الوظائف _داخلية _ _ وحدات_ كثيرًا من الوقت ، وأنا أستخدم الإصدار الداخلي حتى أتمكن من تتبع آخر تغيير في إحدى الوظائف دون الحاجة إلى الانسحاب إلى سجل تغيير خارجي (للوظيفة). لا أرى سبب تداخل .VERSION في إحدى الوظائف مع إصدار الوحدة النمطية. أنا فقط لا أفعل.

صحيح ولكن الشيء الرئيسي هو: ماذا ستفعل بهذه البيانات الوصفية؟ هل هو مجرد شيء تنظر إليه في مصدر الوظيفة؟ إذا كان الأمر كذلك ، فهل يمكنك توضيح كيف أن قسم .NOTES غير مناسب لذلك؟

كانت هذه المشكلة أيضًا تتعلق بالسماح لدالة مستقلة بإعلان رقم إصدارها في إخراج Get-Command . قد يكون طلب تضمين سجل تغيير كامل تطبيقًا مختلفًا تمامًا وربما يكون أفضل حالًا في مشكلته الخاصة.

من السهل الإجابة. هذا يعني أنه لا بد لي من فتحه في محرر أو إجراء نوع من البحث المحرج عن السلاسل لمعرفة الإصدار المثبت على جهاز كمبيوتر معين / موقع معين على الكمبيوتر المذكور. هذا ليس سهلاً دائمًا مثل هذه الإجابة. :-)

ليس حقيقيا؟

يظهر حقل الملاحظات في إخراج Get-Help إذا كنت تكتبه كمساعدة مناسبة قائمة على التعليق (والتي يجب أن تكون على أي حال).

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

Get-Help test -Full

# or
Get-Help test | % alertSet

نتيجة:

PS> Get-Help test -Full
SYNTAX
    test [<CommonParameters>]


DESCRIPTION


PARAMETERS
    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer, PipelineVariable, and OutVariable. For more information, see
        about_CommonParameters (https://go.microsoft.com/fwlink/?LinkID=113216).

INPUTS

OUTPUTS

NOTES


        Version: 1.5.1


RELATED LINKS

PS> get-help test | % alertset



    Version: 1.5.1

لذا؟ انا لست مندهشا. كانت هناك طرق أخرى أكثر تفصيلاً لإجراء العمليات الثلاثية أيضًا. ومع ذلك ... تم تنفيذ طريقة أكثر إحكاما. لأن (جزء من) المجتمع أراد ذلك. ما زلت لا أعرف ما هي عوامل الاندماج الصفري.

لست متأكدًا حقًا مما تبحث عنه ، إذن. من الواضح أن هذا يتيح لك القيام بما تريده بسهولة نسبيًا. لا أرى أن إضافة حقول إضافية هناك تستحق الوقت.

إذا قمت بذلك ، فلا تتردد في فتح علاقات عامة وسنتحدث عنها أكثر. 🤷

العلاقات العامة من أجل ماذا؟ أنا لست مبرمج C #. لم أكن مطورًا محترفًا لأكثر من 30 عامًا.

أعتقد أن العديد منا كانوا واضحين حقًا بشأن ما نسعى إليه ، وحالات الاستخدام الخاصة بنا ، ورأوا أن هذه المخاوف يتم تقليلها ، كما فعلت مرة أخرى.

أولئك الذين هم خارج البرمجة النصية للمشرف يعتقدون "فقط اجعلها وحدة نمطية". لن يعرف معظم سكريبتات المشرفين كيف سيقولون (وسأوافق على ذلك) أنها مشكلة كبيرة بمجرد أن يروا المتطلبات.

لكن هذا لا طائل منه وكنت أعرف أفضل. تم الوصول إلى استنتاج لجنة PowerShell بالفعل. آسف علقت.

تم الوصول إلى استنتاج لجنة PowerShell بالفعل.

يمكن إعادة النظر في أي استنتاجات حسب التصميم بناءً على التعليقات.

أعتقد أن العديد منا كانوا واضحين حقًا بشأن ما نسعى إليه ، وحالات الاستخدام الخاصة بنا ، ورأوا أن هذه المخاوف يتم تقليلها ، كما فعلت مرة أخرى.

لقد كنت أحاول جاهدًا الوصول إلى حقيقة الهدف الفعلي وحالات الاستخدام ، وقد تم تجاهل أسئلتي في الغالب. أود حقًا أن أفهم.

أولئك منكم الذين هم خارج البرمجة النصية للمشرف

يا رجل ، أنا مسؤول النظام. قضيت معظم مسيرتي المهنية في التفكير في أن تركيب علامة التجزئة كان "بناء جملة الضربات". معظم زملائي في العمل يعرفون فقط الأساسيات المطلقة لـ PowerShell (إن وجد) ، كما هو الحال مع معظم الأشخاص الذين أساعدهم في الخلاف / reddit.

لقد فهمت أن لديك بعض اللحم البقري مع فريق PS dev ، لكن من فضلك لا تتظاهر بأني لا أستطيع فهم وجهة نظرك لأنني أعرف C # الآن. أنا أقاتل باستمرار من أجل هذا المنظور في هذا الريبو.

فكر "فقط اجعلها وحدة نمطية". لن يعرف معظم سكريبتات المشرفين كيف سيقولون (وسأوافق على ذلك) أنها مشكلة كبيرة بمجرد أن يروا المتطلبات.

بالنسبة لأي شخص يصادف هذا الموضوع لاحقًا ويثبط عزيمته عن إنشاء وحدة ، فإليك المتطلبات:

1. أعد تسمية ملفك .ps1 إلى .psm1
2. استخدم Import-Module ./file.psm1 بدلاً من . ./file.ps1

هذا كل شيء ، لقد حصلت على وحدة. كل شيء آخر هو مجرد أفضل الممارسات التي لا داعي للقلق بشأنها حتى الآن. إذا كنت تريد إصداره ، فأنت بحاجة إلى بيان ، فإليك المتطلبات الكاملة لذلك:

1. أعد تسمية ملفك .ps1 إلى .psm1
2. تشغيل New-ModuleManifest -RootModule ./file.psm1 -Path ./file.psd1 -ModuleVersion 1.0.0
3. استخدم Import-Module ./file.psd1 بدلاً من . ./file.ps1

إذا كنت تقوم بشحن وظيفة فضفاضة في PS1 والتي سيحتاجها المستهلك (أو أنت نفسك) إلى تحديد المصدر ، فما عليك سوى رميها في وحدة نمطية بسرعة حقيقية ستجعل حياتك أسهل.

إذا كنت تقوم بشحن نص برمجي قابل للاستدعاء مباشرة ، فيمكنك استخدام New-ScriptFileInfo والذي سينشئ ملفًا نصيًا به تعليق مثل هذا:

<#PSScriptInfo

.VERSION 1.0.0

.GUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

.AUTHOR username

.COMPANYNAME

.COPYRIGHT

.TAGS

.LICENSEURI

.PROJECTURI

.ICONURI

.EXTERNALMODULEDEPENDENCIES 

.REQUIREDSCRIPTS

.EXTERNALSCRIPTDEPENDENCIES

.RELEASENOTES


.PRIVATEDATA

#>

<# 
.DESCRIPTION 
     Quick script description here.
#> 
param()

ويمكنك الاستعلام عن ذلك باستخدام Test-ScriptFileInfo .