مقال كتب في فبراير 2018.

الذهاب يحتاج إلى إضافة إصدار الحزمة.

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

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

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

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

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

يحتفظ هذا الاقتراح بجميع مزايا go get ، لكنه يضيف تصميمات قابلة للتكرار ، ويدعم التحكم في الإصدار الدلالي ، ويزيل التوريد ، ويزيل GOPATH لصالح سير العمل القائم على المشروع ، ويوفر خروجًا سلسًا عن dep وسابقاتها. ومع ذلك ، فإن هذا الاقتراح لا يزال في مرحلة مبكرة. إذا كانت التفاصيل غير صحيحة ، فسنقوم بإصلاحها قبل بدء العمل في توزيع Go الرئيسي.

الوضع العام

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

Makefile ، goinstall go get

في نوفمبر 2009 ، تم إصدار المترجم والرابط وعدة مكتبات بالإصدار الأولي من Go. لتجميع البرامج وربطها ، كان من الضروري تشغيل 6g و 6l ، وقمنا بتضمين عينة makefiles في المجموعة. الحد الأدنى من gobuild shell يمكنه تجميع حزمة واحدة وكتابة ملف التعريف المقابل (في معظم الحالات). لم يكن هناك طريقة ثابتة لمشاركة الكود مع الآخرين. كنا نعلم أن هذا لم يكن كافيًا - لكننا أصدرنا ما لدينا ، ونخطط لتطوير الباقي مع المجتمع.

في فبراير 2010 ، اقترحنا goinstall ، وهو أمر بسيط لتنزيل الحزم من مستودعات أنظمة التحكم في الإصدار مثل Bitbucket و GitHub. قدم Goinstall اصطلاحات حول مسارات الاستيراد التي يتم قبولها الآن بشكل عام. ولكن في ذلك الوقت ، لم تتبع أي كود هذه الاتفاقيات ؛ عملت goinstall في البداية فقط مع الحزم التي لم تستورد أي شيء باستثناء المكتبة القياسية. لكن المطورين انتقلوا بسرعة إلى اتفاقية واحدة نعرفها اليوم ، ونمت مجموعة حزم Go المنشورة إلى نظام بيئي كلي.

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

في ديسمبر 2011 ، استعدادًا لـ Go 1 ، قدمنا ​​الأمر go الذي استبدل goinstall بـ go get .

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

الإصدار و API الاستقرار

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

في تشرين الثاني (نوفمبر) 2013 ، أضاف إصدار من Go 1.2 إدخال الأسئلة المتداولة مع نصيحة بخصوص الإصدار (لم يتغير النص إلى الإصدار Go 1.10):

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

في مارس 2014 ، أطلق Gustavo Niemeyer gopkg.in تحت ستار "واجهات برمجة التطبيقات المستقرة للغة Go". هذا المجال هو إعادة توجيه GitHub gopkg.in/yaml.v1 بالإصدار والتي تسمح لك باستيراد مسارات مثل gopkg.in/yaml.v1 و gopkg.in/yaml.v2 لعمليات مختلفة (ربما في فروع مختلفة) لمستودع Git واحد. وفقًا للإصدار الدلالي ، يجب على المؤلفين ، عند إجراء التغييرات الحرجة ، إصدار نسخة رئيسية جديدة. وبالتالي ، فإن الإصدارات الأحدث من مسار الاستيراد v1 تحل محل الإصدارات السابقة ، ويمكن أن تعطي v2 واجهات برمجة تطبيقات مختلفة تمامًا.

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

أي حجة للإصدار الدلالي ستنتقد حتما بالإشارة إلى قانون Hyrum :

يصبح عقد API الخاص بك غير مهم مع وجود عدد كاف من المستخدمين. شخص ما يعتمد على أي سلوك ملحوظ للنظام.

على الرغم من أن قانون Hyrum صحيح تجريبياً ، إلا أن التحكم في النسخة الدلالية لا يزال وسيلة مفيدة لتوليد توقعات حول العلاقة بين الإصدارات. يجب ألا تؤدي الترقية من 1.2.3 إلى 1.2.4 إلى كسر الشفرة ، وقد تكون الترقية من 1.2.3 إلى 2.0.0 جيدة جدًا. إذا توقفت الشفرة عن العمل بعد التحديث إلى 1.2.4 ، فمن المحتمل أن يقبل المؤلف تقرير الأخطاء ويصلح الخطأ في الإصدار 1.2.5. إذا توقف الرمز عن العمل (أو حتى تم التحويل البرمجي) بعد التحديث إلى 2.0.0 ، فمن المرجح أن يكون هذا التغيير مقصودًا ، وبالتالي ، فمن غير المرجح أن يتم إصلاح شيء ما في 2.0.1.

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

جمعيات بيع وقابلة للتكرار

العيب الرئيسي الثاني في go get هو أنه بدون مفهوم التحكم في الإصدار ، لن يتمكن الفريق من تقديم فكرة عن بنية قابلة للتكرار أو حتى التعبير عنها. لا يمكنك التأكد من قيام المستخدمين بترجمة نفس الإصدار من تبعيات التعليمات البرمجية التي تستخدمها. في نوفمبر 2013 ، تمت إضافة الأسئلة الشائعة التالية إلى FAQ for Go 1.2:

إذا كنت تستخدم حزمة خارجية وتخشى أن تتغير بشكل غير متوقع ، فإن الحل الأسهل هو نسخها إلى المستودع المحلي (تستخدم Google هذا النهج). احفظ نسخة بمسار استيراد جديد يعرّفها كنسخة محلية. على سبيل المثال ، يمكنك نسخ original.com/pkg إلى you.com/external/original.com/pkg . إحدى أدوات هذا الإجراء هي مجموعة Kit Rerik.

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

في سبتمبر 2013 ، قدم Keith godep ، "أداة جديدة لإصلاح تبعيات الحزمة". كان الإنجاز الرئيسي لـ godep هو ما نسميه الآن البائع ، أي نسخ التبعيات في المشروع دون تغيير الملفات المصدر ، دون دعم مباشر للأدوات ، من خلال تكوين معين لـ GOPATH.

في أكتوبر 2014 ، اقترح Keith إضافة دعم لـ "الحزم الخارجية" إلى أدوات Go بحيث تفهم الأدوات بشكل أفضل المشروعات التي تستخدم هذه الاتفاقية. بحلول ذلك الوقت ، كانت قد ظهرت بالفعل العديد من المرافق على غرار godep . نشر مات فارينا مقالًا بعنوان "السفر godep جو مديري godep " يقارن بين godep ، لا سيما glide .

في أبريل 2015 ، قدم Dave Cheney gb ، "أداة إنشاء قائمة على المشاريع ... مع عمليات تكرار متكررة من خلال بيع المصدر" ، مرة أخرى دون إعادة كتابة مسارات الاستيراد (كان الدافع الآخر لإنشاء gb هو تجنب الحاجة إلى تخزين التعليمات البرمجية في أدلة محددة في GOPATH التي ليست مريحة دائما).

في ذلك الربيع ، درس جيسون بوبرلي الموقف من خلال أنظمة إدارة حزم Go ، بما في ذلك تكرار الجهود والعبث على المرافق المماثلة. أوضح مسحه للمطورين أنه يجب إضافة دعم البيع دون إعادة كتابة مسارات الاستيراد إلى أمر go . في نفس الوقت ، بدأ Daniel Theofanes في إعداد مواصفات لتنسيق ملف يصف أصل الشفرة وإصدارها في دليل البائع. في يونيو 2015 ، قبلنا اقتراح Keith كتجربة على البيع في Go 1.5 ، والذي تم تضمينه افتراضيًا في Go 1.6. شجعنا مؤلفي جميع أدوات البيع على العمل مع دانيال لاعتماد تنسيق ملف بيانات تعريف واحد.

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

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

تجربة إدارة الحزمة الرسمية

في GopherCon 2016 في يوم الاختراق (اليوم المجتمعي) ، اجتمعت مجموعة من نشطاء Go لمناقشة قضايا إدارة الحزم على نطاق واسع . كانت إحدى النتائج هي تشكيل لجنة ومجموعة استشارية لإجراء مجموعة من الأنشطة بهدف إنشاء أداة جديدة لإدارة الحزمة . كانت الفكرة هي أن تكون هناك أداة موحدة تحل محل الأدوات الموجودة ، على الرغم من أنه سيتم تنفيذها خارج مجموعة أدوات Go المباشرة باستخدام كتالوجات البائعين. ضمت اللجنة أندرو جيراند وإد مولر وجيسي فريزل وسام بويير بقيادة بيتر بورغون. أعدوا مسودة المواصفات ، ثم نفذ سام ومساعديه شعبة . لفهم الوضع العام ، راجع مقال سام في فبراير 2016 ، "لذا تريد أن تكتب مدير الحزم" ، في مقالته في ديسمبر 2016 بعنوان "Go Dependency Management Saga" ، والخطاب الذي ألقاه في يوليو 2017 في GopherCon ، "عصر جديد لإدارة الحزم في اذهب . "

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

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

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

عرض

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

قاعدة توافق الاستيراد

المشكلة الرئيسية في أنظمة إدارة الحزم هي محاولات حل مشكلة عدم التوافق. على سبيل المثال ، تسمح معظم الأنظمة للحزمة B بالإعلان عن حاجتها إلى الحزمة D من الإصدار 6 أو الأحدث ، ثم السماح للحزمة C بالإعلان أنها تتطلب D الإصدار 2 أو 3 أو 4 ، ولكن ليس الإصدار 5 أو الأحدث. وبالتالي ، إذا كنت ترغب في استخدام B و C في الحزمة الخاصة بك ، فأنت غير محظوظ: لا يمكنك تحديد أي إصدار من D يرضي الشرطين ، ولا يمكنك فعل أي شيء.

بدلاً من نظام يمنع حتماً تجميع البرامج الكبيرة ، يقدم اقتراحنا قاعدة توافق استيراد لمؤلفي الحزم:

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

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

 import "github.com/go-yaml/yaml/v2" 

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

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

اختيار الحد الأدنى للنسخة

, dep cargo , . , . -, « » - , - . , - , , , . -, , , «, X», X .

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

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

يؤدي تحديد الحد الأدنى من الإصدار إلى توفير تجميعات قابلة للتكرار افتراضيًا دون وجود ملف تأمين.

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

تحديد الذهاب وحدات

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

في الملف الجديد ، go.modتحدد الوحدة النمطية متطلبات إصدار الحد الأدنى للوحدات النمطية الأخرى التي يعتمد عليها. على سبيل المثال ، إليك ملف بسيط go.mod:

 // My hello, world. module "rsc.io/hello" require ( "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54 "rsc.io/quote" v1.5.2 ) 

يحدد هذا الملف وحدة نمطية يتم تحديدها بواسطة المسار rsc.io/hello، ويعتمد على وحدتين أخريين: golang.org/x/textو rsc.io/quote. سوف تستخدم مجموعة الوحدة النمطية نفسها دائمًا إصدارات معينة من التبعيات اللازمة المدرجة في الملف go.mod. كجزء من مجموعة أكبر ، يمكن فقط استخدام إصدار أحدث إذا كان جزء آخر من التجميع يتطلب ذلك.

يصنف المؤلفون إصداراتهم بإصدارات دلالات ، vgoويوصون باستخدام الإصدارات المميزة ، بدلاً من الالتزامات التعسفية. الوحدة النمطية rsc.io/quoteالتي تأتي مع github.com/rsc/quoteالإصدارات ملحوظ ، بما في ذلك 1.5.2. ومع ذلك ، لا تحتوي الوحدة النمطية على golang.org/x/textإصدارات تم وضع علامة عليها حتى الآن. لتسمية الإلتزامات غير المميزة ، النسخة الزائفة v0.0.0-yyyymmddhhmmss-الالتزاميحدد التزام محدد في تاريخ معين. في الإصدار الدلالية ، يتوافق هذا السطر مع الإصدار التجريبي v0.0.0 مع معرف yyyymmddhhmmss-الالتزام . تتعرف القواعد الدلالية لأسبقية الإصدار على هذه الإصدارات المسبقة كأقدم من الإصدار v0.0 ، وتجري مقارنات السلسلة. يضمن ترتيب التاريخ في الإصدار الزائف تطابق مقارنة السلسلة مع مقارنة التاريخ.

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

Goinstallوالقديمgo getيتم استدعاء أدوات التحكم في الإصدار ، مثل gitو hg، لتنزيل الكود ، مما يؤدي إلى العديد من المشاكل ، بما في ذلك التجزئة. على سبيل المثال ، لا bzrيمكن للمستخدمين بدون تنزيل الكود من مستودعات Bazaar. على عكس هذا النظام ، يتم إصدار وحدات Go دائمًا عبر HTTP في شكل محفوظات zip. في السابق ، go getكان هناك فرق خاصة لمواقع استضافة الرموز الشائعة. الآن لديهم vgoإجراءات API خاصة لاستقبال الأرشيفات من هذه المواقع.

يسمح العرض التقديمي الموحد للوحدات النمطية في شكل محفوظات zip بتطبيق بروتوكول وخادم وكيل لتحميل الوحدات بشكل تافه. لدى الشركات والمستخدمين الأفراد أسباب مختلفة لبدء تشغيل هذه الخوادم الوكيلة ، بما في ذلك الأمان والرغبة في العمل مع النسخ المخبأة في حالة حذف النسخ الأصلية. مع وجود بروكسي في مكانه ، لضمان إمكانية الوصول go.modوتحديد الكود المطلوب استخدامه ، لم تعد هناك حاجة إلى أدلة البائعين.

الفريق go

go . , , go build , go install , go run go test , . golang.org/x/text Go .

— GOPATH . go.mod , , go.mod , , . git clone , cd , . . GOPATH.

?

لقد قمت أيضًا بنشر جولة Go Versioning مع عرض توضيحي لكيفية استخدامها vgo. توضح لك هذه المقالة كيفية التنزيل والبدء في استخدام اليوم vgo. معلومات أخرى في مقالات أخرى . سأكون سعيدا للتعليق.

يرجى المحاولة vgo . ابدأ وضع علامات على الإصدارات في المستودعات ذات العلامات الدلالية. إنشاء ملفات go.mod. لاحظ أنه إذا ملف فارغ في المستودع go.mod، ولكن هناك dep، glide، glock، godep، godeps، govend، govendorأو ملف التكوين gvt، ثم vgoيستخدمها لتجميع الملف go.mod.

, Go . , Go, — , go get , GOPATH GOPATH. .

- . , , vgo . , Go 1.11 Go, , Go 1.12 . , go get. ولكن هذه هي خطة عدوانية ، وإذا كنت تحتاج للوظائف الصحيحة في انتظار الإصدارات اللاحقة ، فليكن الأمر كذلك.

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