Go: cmd / go: إضافة دعم إصدار الحزمة إلى Go toolchain

أسئلة مكررة

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

لماذا الاقتراح ليس " قسم الاستخدام"؟

في بداية الرحلة التي أدت إلى هذا الاقتراح ، منذ ما يقرب من عامين ، اعتقدنا جميعًا أن الإجابة ستكون اتباع نهج إصدار الحزمة المتمثل في Ruby's Bundler ثم Rust's Cargo: الإصدارات الدلالية ذات العلامات ، ملف قيد التبعية تم تحريره يدويًا يُعرف باسم البيان ، وهو وصف تبعية متعدية منفصل يتم إنشاؤه آليًا يُعرف باسم ملف القفل ، وهو حلال إصدار لحساب ملف قفل يلبي البيان ، والمستودعات كوحدة للإصدار. يتبع Dep هذه الخطة التقريبية تقريبًا تمامًا وكان يُقصد به في الأصل أن يكون بمثابة نموذج لتكامل أوامر go. ومع ذلك ، كلما فهمت تفاصيل نهج Bundler / Cargo / Dep وما الذي تعنيه لـ Go ، خاصةً المضمنة في أمر go ، وكلما ناقشت هذه التفاصيل مع الآخرين في فريق Go ، بعض التفاصيل بدا أقل ملاءمة لجو. يقوم الاقتراح بتعديل تلك التفاصيل على أمل شحن نظام يسهل على المطورين فهمه واستخدامه. راجع قسم الأساس المنطقي للاقتراح لمزيد من التفاصيل حول التفاصيل المحددة التي أردنا تغييرها ، وكذلك منشور المدونة الذي يعلن عن الاقتراح .

لماذا يجب أن تظهر أرقام الإصدارات الرئيسية في مسارات الاستيراد؟

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

لماذا تم حذف الإصدارات الرئيسية v0 و v1 من مسارات الاستيراد؟

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

تم حذف v0 من مسارات الاستيراد لأنه - وفقًا لـ semver - لا توجد ضمانات توافق على الإطلاق لهذه الإصدارات. إن طلب عنصر صريح v0 لن يفعل الكثير لضمان التوافق ؛ يجب أن تقول v0.1.2 لتكون دقيقًا تمامًا ، وتقوم بتحديث جميع مسارات الاستيراد في كل تحديث للمكتبة. هذا يبدو وكأنه مبالغة. بدلاً من ذلك ، نأمل أن ينظر المطورون ببساطة إلى قائمة الوحدات التي يعتمدون عليها وأن يكونوا حذرين بشكل مناسب من أي إصدارات v0.xy يجدونها.

هذا له تأثير عدم التمييز بين v0 و v1 في مسارات الاستيراد ، ولكن عادةً ما يكون v0 عبارة عن سلسلة من التغييرات الفاصلة تؤدي إلى v1 ، لذلك من المنطقي التعامل مع v1 كخطوة أخيرة في تسلسل القطع هذا ، وليس شيئًا يحتاج إلى التمييز عن v0 . كما قال ميروفيوس (https://github.com/golang/go/issues/24301#issuecomment-376213693):

باستخدام v0.x ، فأنت تقبل أن v0. (x + 1) قد يجبرك على إصلاح التعليمات البرمجية الخاصة بك. لماذا تعتبر مشكلة إذا كان v0. (x + 1) يسمى v1.0 بدلاً من ذلك؟

أخيرًا ، يعد حذف الإصدارات الرئيسية v0 و v1 أمرًا إلزاميًا - وليس اختياريًا - بحيث يكون هناك مسار استيراد أساسي واحد لكل حزمة.

لماذا يجب أن أقوم بإنشاء فرع جديد لـ v2 بدلاً من الاستمرار في العمل على المستوى الرئيسي؟

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

ألن يمنع الحد الأدنى من اختيار الإصدار المطورين من الحصول على تحديثات مهمة؟

هذا خوف شائع ، لكنني أعتقد حقًا أنه إذا حدث أي شيء عكس ذلك. نقلاً عن قسم "سرعة الترقية" في https://research.swtch.com/vgo-mvs :

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

على سبيل المثال ، لنفترض أنك تكتب برنامجًا يعتمد على عدد قليل من الوحدات الأخرى ، وكلها تعتمد على وحدة نمطية شائعة جدًا ، مثل gopkg.in/yaml.v2. سيستخدم بناء برنامجك أحدث إصدار من YAML من بين تلك التي تطلبها الوحدة النمطية الخاصة بك وحفنة من التبعيات. حتى مجرد تبعية ضميرية واحدة يمكنها إجبار جهازك على تحديث العديد من التبعيات الأخرى. هذا هو عكس مشكلة عميل Kubernetes Go التي ذكرتها سابقًا.

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

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

راجع أيضًا الرد https://github.com/golang/go/issues/24301#issuecomment -375992900 بواسطةMerovius.

إذا تم إهمال $ GOPATH ، فأين يعيش الرمز الذي تم تنزيله؟

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

يحتاج Vgo إلى بعض المساحة للاحتفاظ بكود المصدر الذي تم تنزيله وتثبيت الثنائيات ، ولهذا لا يزال يستخدم $ GOPATH ، والذي اعتبارًا من Go 1.9 يتم تعيينه افتراضيًا على $ HOME / go. لذلك لن يحتاج المطورون أبدًا إلى تعيين $ GOPATH إلا إذا كانوا يريدون أن تكون هذه الملفات في دليل مختلف. لتغيير موقع التثبيت الثنائي فقط ، يمكنهم تعيين $ GOBIN (كما هو الحال دائمًا).

لماذا تقدم التعليق // import ؟

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

ملخص المناقشة (آخر تحديث 2017-04-25)

يحمل تعليق القضية هذا ملخصًا للمناقشة أدناه.

كيف يمكننا التعامل مع الهجرة؟

[ https://github.com/golang/go/issues/24301#issuecomment -374739116 بواسطةChrisHines.]

الرد https://github.com/golang/go/issues/24301#issuecomment -377529520 منrsc. يفترض الاقتراح الأصلي أن الترحيل تتم معالجته من قبل المؤلفين الذين ينتقلون إلى الدلائل الفرعية عندما يكون التوافق مهمًا بالنسبة لهم ، ولكن بالطبع هذا الدافع خاطئ. التوافق هو الأكثر أهمية للمستخدمين ، الذين لديهم تأثير ضئيل على المؤلفين الذين ينتقلون. ولا يساعد الإصدارات القديمة. التعليق المرتبط ، الآن أيضًا # 25069 ، يقترح تغييرًا طفيفًا على "go build" القديم لتتمكن من استهلاك وبناء كود مدرك للوحدة.

كيف يمكننا التعامل مع التسجيلات الفردية؟

[ https://github.com/golang/go/issues/24301#issuecomment -374791885 بواسطةjimmyfrasche.]

الرد https://github.com/golang/go/issues/24301#issuecomment -377527249 بواسطةrsc. لا تتأثر حالات تضارب التسجيل الفردي (مثل http.Handle من نفس المسار) بين وحدات مختلفة تمامًا بالاقتراح. بالنسبة للتصادمات بين الإصدارات الرئيسية المختلفة لوحدة واحدة ، يمكن للمؤلفين كتابة الإصدارات الرئيسية المختلفة التي يتوقع تنسيقها ، عادةً عن طريق إجراء مكالمة v1 إلى v2 ، ثم استخدام دورة المتطلبات للتأكد من عدم استخدام v2 مع الإصدار 1 الأقدم الذي لا يحتوي على ' لا أعرف عن التنسيق.

كيف يجب أن نقوم بتثبيت أمر ذي إصدار؟

[ https://github.com/golang/go/issues/24301#issuecomment -375106068 بواسطةleonklingele.]

الرد https://github.com/golang/go/issues/24301#issuecomment -377417565 بواسطةrsc. باختصار ، استخدم Go get. ما زلنا نستخدم $ GOPATH / bin لموقع التثبيت. تذكر أن $ GOPATH يتم تعيينه افتراضيًا الآن على $ HOME / go ، لذلك ستنتهي الأوامر في $ HOME / go / bin ، ويمكن لـ $ GOBIN تجاوز ذلك.

لماذا تم حذف v0 و v1 في مسارات الاستيراد؟ لماذا يجب أن يظهر الآخرون؟ لماذا يجب ألا تظهر v0 و v1 أبدًا؟

[ https://github.com/golang/go/issues/24301#issuecomment -374818326 بواسطةjustinian.]
[ https://github.com/golang/go/issues/24301#issuecomment -374831822 بواسطةjayschwa.]
[ https://github.com/golang/go/issues/24301#issuecomment -375437150 بواسطةmrkanister.]
[ https://github.com/golang/go/issues/24301#issuecomment -376093912 بواسطةmrkanister.]
[ https://github.com/golang/go/issues/24301#issuecomment -376135447 بواسطةkaikuehne.]
[ https://github.com/golang/go/issues/24301#issuecomment -376141888 بواسطةkaikuehne.]
[ https://github.com/golang/go/issues/24301#issuecomment -376213693 بواسطةMerovius.]
[ https://github.com/golang/go/issues/24301#issuecomment -376247926 بواسطةkaikuehne.]

تمت الإضافة إلى الأسئلة الشائعة أعلاه.

لماذا تم ذكر الملفات المضغوطة في الاقتراح؟

[ https://github.com/golang/go/issues/24301#issuecomment -374839409 بواسطةnightlyone.]

سيستفيد النظام البيئي من تحديد تنسيق تبادل ملموس. سيؤدي ذلك إلى تمكين الوكلاء والأدوات الأخرى. في الوقت نفسه ، نتخلى عن الاستخدام المباشر للتحكم في الإصدار (انظر الأساس المنطقي في أعلى هذا المنشور ). كل من هذا الدافع يصف الشكل المحدد. لن يحتاج معظم المطورين إلى التفكير في ملفات zip على الإطلاق ؛ لن يحتاج أي مطورين إلى النظر بداخلهم ، إلا إذا كانوا يبنون شيئًا مثل godoc.org.

راجع أيضًا # 24057 حول zip vs tar.

ألا يؤدي وضع الإصدارات الرئيسية في مسارات الاستيراد إلى انتهاك DRY؟

[ https://github.com/golang/go/issues/24301#issuecomment -374831822 بواسطةjayschwa.]

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

أيضًا ، إذا جفت كثيرًا ينتهي بك الأمر بأنظمة هشة. يمكن أن يكون التكرار شيئًا جيدًا. لذا فإن عبارة "Violat [ing] DRY" - أي ، تكرار نفسك بشكل محدود - ليست دائمًا سيئة. على سبيل المثال ، نضع جملة الحزمة في كل ملف .go في الدليل ، وليس ملفًا واحدًا فقط. اكتشف ذلك أخطاءً صادقة في وقت مبكر وتحولت لاحقًا إلى طريقة سهلة للتمييز بين حزم الاختبار الخارجية (الحزمة x مقابل الحزمة x_test). هناك توازن يجب تحقيقه.

ما المنطقة الزمنية المستخدمة للطابع الزمني في الإصدارات الزائفة؟

[ https://github.com/golang/go/issues/24301#issuecomment -374882685 بواسطةtpng.]

التوقيت العالمي. لاحظ أيضًا أنك لن تضطر أبدًا إلى كتابة نسخة زائفة بنفسك. يمكنك كتابة تجزئة git الالتزام (أو بادئة التجزئة) وسيقوم vgo بحساب واستبدال الإصدار الزائف المناسب.

هل سيتعامل vgo مع التبعيات غير المرتبطة بـ Go ، مثل المخازن المؤقتة للبروتوكول C أو البروتوكول؟ رمز تم إنشاؤه؟

[ https://github.com/golang/go/issues/24301#issuecomment -374907338 بواسطةAlexRouSg.]
[ https://github.com/golang/go/issues/24301#issuecomment -376606788 بواسطةstevvooe.]
[ https://github.com/golang/go/issues/24301#issuecomment -377186949 بواسطة @ nim-nim.]

يستمر تطوير Non-Go في كونه ليس هدفًا للأمر go ، لذلك لن يكون هناك دعم لإدارة مكتبات C وما شابه ، ولن يكون هناك دعم صريح للمخازن المؤقتة للبروتوكول.

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

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

ألن يمنع الحد الأدنى من اختيار الإصدار المطورين من الحصول على تحديثات مهمة؟

[ https://github.com/golang/go/issues/24301#issuecomment -375090551 بواسطةTocarIP.]
[ https://github.com/golang/go/issues/24301#issuecomment -375985244 بواسطة @ nim-nim.]
[ https://github.com/golang/go/issues/24301#issuecomment -375992900 بواسطةMerovius.]

تمت الإضافة إلى التعليمات.

### هل يمكنني استخدام master لتطوير الإصدار 1 ثم إعادة استخدامه لتطوير الإصدار 2؟

[ https://github.com/golang/go/issues/24301#issuecomment -375248753 بواسطةmrkanister.]
[ https://github.com/golang/go/issues/24301#issuecomment -375989173 بواسطة @ aarondl.]

نعم. تمت الإضافة إلى التعليمات.

ما هو الجدول الزمني لهذا؟

[ https://github.com/golang/go/issues/24301#issuecomment -375415904 بواسطةflibustenet.]

الرد في https://github.com/golang/go/issues/24301#issuecomment -377413777 بواسطةrsc. باختصار ، الهدف هو الحصول على "معاينة تقنية" في Go 1.11 ؛ قد يستمر العمل بعد أسابيع قليلة من التجميد ولكن ليس أكثر. من المحتمل ألا ترسل ملفات PR تضيف go.mod إلى كل مكتبة يمكنك العثور عليها حتى يتم وضع علامة قبول الاقتراح وتحديث نسخة تطوير cmd / go.

كيف يمكنني إجراء تغيير أمني غير متوافق مع الإصدارات السابقة؟

[ https://github.com/golang/go/issues/24301#issuecomment -376236546 بواسطة @ buro9.]

الرد في https://github.com/golang/go/issues/24301#issuecomment -377415652 بواسطةrsc. باختصار ، تسمح إرشادات توافق Go 1 بتعطيل التغييرات لأسباب أمنية لتجنب الاصطدام بالإصدار الرئيسي ، ولكن من الأفضل دائمًا القيام بذلك بطريقة تحافظ على عمل الكود الحالي قدر الإمكان. على سبيل المثال ، لا تقم بإزالة دالة. بدلاً من ذلك ، اجعل الوظيفة تصيب بالذعر أو تسجل. لا تكون قاتلة إلا إذا تم استدعاؤها بشكل غير صحيح.

إذا كان أحد الريبو يحتوي على وحدات مختلفة في الدلائل الفرعية (على سبيل المثال ، v2 ، v3 ، v4) ، فهل يمكن لـ vgo المزج والمطابقة من التزامات مختلفة؟

[ https://github.com/golang/go/issues/24301#issuecomment -376266648 بواسطةjimmyfrasche.]
[ https://github.com/golang/go/issues/24301#issuecomment -376270750 بواسطةAlexRouSg.]

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

ماذا لو اساءت المشاريع استخدام semver؟ هل يجب أن نسمح بإصدارات ثانوية في مسارات الاستيراد؟

[ https://github.com/golang/go/issues/24301#issuecomment -376640804 بواسطة @ pbx0.]
[ https://github.com/golang/go/issues/24301#issuecomment -376645212 بواسطةpowerman.]
[ https://github.com/golang/go/issues/24301#issuecomment -376650153 بواسطة @ pbx0.]
[ https://github.com/golang/go/issues/24301#issuecomment -376660236 بواسطةpowerman.]

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

هل يمكنك تحديد ما إذا كان لديك أكثر من حزمة في البناء؟

[ https://github.com/golang/go/issues/24301#issuecomment -376640804 بواسطة @ pbx0.]

أسهل ما يمكن فعله هو استخدام goversion -m في الملف الثنائي الناتج. يجب أن نجعل خيار go لإظهار نفس الشيء بدون إنشاء الثنائي.

مخاوف بشأن اعتماد vgo على الوكيل مقابل البائع ، وخاصة المصدر المفتوح مقابل المؤسسة.

[ https://github.com/golang/go/issues/24301#issuecomment -376925845 بواسطةjoeshaw.]
[ https://github.com/golang/go/issues/24301#issuecomment -376936614 بواسطةkardianos.]
[ https://github.com/golang/go/issues/24301#issuecomment -376947621 بواسطةMerovius.]
[ https://github.com/golang/go/issues/24301#issuecomment -376979054 بواسطةjoeshaw.]
[ https://github.com/golang/go/issues/24301#issuecomment -376988873 بواسطةjamiethermo.]
[ https://github.com/golang/go/issues/24301#issuecomment -377134575 بواسطةMerovius.]

الرد: [ https://github.com/golang/go/issues/24301#issuecomment -377411175 بواسطةrsc.] سيتم دعم كل من الوكيل والمورد. الوكيل مهم جدًا للمؤسسة ، والبائع مهم جدًا لفتح المصدر. نريد أيضًا بناء شبكة متطابقة موثوقة ، ولكن بمجرد أن يتم تشغيل vgo.

مخاوف بشأن البناء البدائي اعتمادًا على دلالات GOPATH.

[ https://github.com/golang/go/issues/24301#issuecomment -377601170 بواسطةstevvooe.]

طلب الرد [ https://github.com/golang/go/issues/24301#issuecomment -377602765 بواسطةrsc] الحصول على مزيد من التفاصيل في إصدار جديد ، ولكن يبدو أنه لم يتم تقديم هذه المشكلة.

اقتراح إضافة علامة خاصة vgo-v1-lock .

[ https://github.com/golang/go/issues/24301#issuecomment -377662150 بواسطةkybin.]

يبدو الأمر جذابًا في البداية ولكنه يؤدي إلى حالات خاصة ربما لا تستحق المتابعة. الرد الكامل في https://github.com/golang/go/issues/24301#issuecomment -384344659.

كيف يمكن تصحيح تبعية عميقة دون بيع؟

[ https://github.com/golang/go/issues/24301#issuecomment -378255833 بواسطةchirino.]

الرد [ https://github.com/golang/go/issues/24301#issuecomment -378261916 بواسطةkardianos.] باستخدام توجيه الاستبدال.

ماذا سنفعل حيال تغيير أسماء الوحدات؟

[ https://github.com/golang/go/issues/24301#issuecomment -379020339 بواسطةjimmyfrasche.]

رد [ https://github.com/golang/go/issues/24301#issuecomment -379307176 بواسطةrsc.]
هذه مشاكل حقيقية موجودة مسبقًا ولا يحاول اقتراح vgo معالجتها بشكل مباشر ، ولكن من الواضح أنه يجب علينا معالجتها في النهاية. الجواب على اختفاء الكود هو أن يكون لديك وكلاء مؤقت (مرايا) مع سبب للثقة بهم ؛ هذا العمل في المستقبل. (أو استخدم البيع في مشروع المستوى الأعلى إذا كنت تفضل ذلك). الإجابة على نقل الكود هي إضافة مفهوم واضح للوحدة أو إعادة توجيه الحزمة ، مثل الأسماء المستعارة النوع هي إعادة توجيه النوع ؛ هذا أيضًا عمل مستقبلي.

ماذا عن الاتصال بخوادم Git المحلية؟

[ https://github.com/golang/go/issues/24301#issuecomment -383168012 بواسطةkorya.]

تمت إضافة الوصول المباشر إلى الخطة مرة أخرى. انظر # 24915.

ماذا عن الحزم الثنائية فقط؟

[ https://github.com/golang/go/issues/24301#issuecomment -382793364 بواسطةsdwarwick.]

لم يتم دعم الحزم الثنائية فقط إلا في ظروف محدودة لنوع من التثبيت خارج النطاق في GOPATH / pkg. لم يدعم Go get مطلقًا جلب حزمة ثنائية فقط وتثبيتها ، وسيستمر في عدم دعم ذلك. تعمل الحزمة الثنائية فقط مع مترجم واحد معين ونسخة واحدة معينة من التبعيات ، مما يحد بشدة من مدى جودة دعمها على الإطلاق. الإجابة الصحيحة هي دائمًا استخدام شفرة المصدر بدلاً من ذلك.

هل يجب استخدام صيغة المسار @ version في ملف go.mod؟

[ https://github.com/golang/go/issues/24301#issuecomment -382791513 بواسطةsdwarwick.]

هذا هو # 24119. بدت وكأنها فكرة جيدة في البداية ولكن بعد دراسة متأنية ، لا.

.

.

تغيير https://golang.org/cl/101678 يذكر هذه المشكلة: design: add 24301-versioned-go

هذا الاقتراح مثير للإعجاب وأنا أحب معظم كل شيء عنه. ومع ذلك ، قمت بنشر القلق التالي في القائمة البريدية ، لكنني لم أتلق أي ردود. في غضون ذلك ، رأيت هذه المشكلة أثارها آخرون في قناة Gophers Slack لـ vgo ولم أر إجابة مرضية هناك أيضًا.

من: https://groups.google.com/d/msg/golang-dev/Plc42fslQEk/rlfeNlazAgAJ

أنا قلق للغاية بشأن مسار الهجرة بين عالم ما قبل vgo وعالم vgo الذي يسير بشكل سيء. أعتقد أننا نجازف بإلحاق آلام كبيرة بمجتمع Go إذا لم يكن هناك مسار انتقال سلس. من الواضح أن الترحيل لا يمكن أن يكون ذريًا عبر المجتمع بأكمله ، ولكن إذا فهمت كل ما كتبته عن vgo حتى الآن ، فقد تكون هناك بعض المواقف حيث لن تكون الحزم الحالية المستخدمة على نطاق واسع قابلة للاستخدام بواسطة كل من أدوات pre-vgo و post أدوات vgo.

على وجه التحديد ، أعتقد أن الحزم الحالية التي تحتوي بالفعل على إصدارات مميزة بإصدارات رئيسية> = 2 لن تعمل مع vgo حتى يكون لديها ملف go.mod ويتم استيرادها أيضًا بمسار استيراد / vN المعزز. ومع ذلك ، بمجرد إجراء هذه التغييرات على المستودع ، سيتم تعطيل الاستخدامات السابقة لـ vgo للحزمة.

يبدو أن هذا يخلق نوعًا مختلفًا من مشكلة استيراد الماس حيث تستورد حزمتا الأخوان في منتصف الماس حزمة مشتركة v2 +. أنا قلق من أن حزم الأخوة يجب أن تتبنى مسارات استيراد vgo بشكل ذري لمنع الحزمة الموجودة أعلى الماس من أن تكون في حالة غير قابلة للإنشاء سواء كانت تستخدم أدوات vgo أو pre-vgo.

لم أر حتى الآن أي شيء يشرح مسار الترحيل في هذا السيناريو.

ينص الاقتراح على ما يلي:

يمكن للبنيات المدركة للوحدات النمطية استيراد الحزم غير المدركة للوحدة النمطية (تلك الموجودة خارج شجرة بملف go.mod) بشرط أن يتم تمييزها بإصدار دلالي v0 أو v1. يمكنهم أيضًا الإشارة إلى أي التزام محدد باستخدام "نسخة زائفة" من النموذج v0.0.0-yyyymmddhhmmss-الالتزام. يسمح نموذج الإصدار الزائف بالإشارة إلى الالتزامات غير المميزة بالإضافة إلى الالتزامات التي تم تمييزها بإصدارات دلالية في الإصدار 2 أو أعلى ولكنها لا تتبع اصطلاح إصدار الاستيراد الدلالي.

لكني لا أرى طريقة للحزم غير المدركة للوحدة النمطية لاستيراد حزم مدركة للوحدة ذات تبعيات متعدية> = v2. يبدو أن هذا يتسبب في تجزئة النظام الإيكولوجي بطريقة لم تتم معالجتها بعد. بمجرد أن يكون لديك تبعية مدركة للوحدة تحتوي على حزمة> = v2 في مكان ما في تبعياتها المتعدية التي يبدو أنها تجبر جميع التابعين لها على تبني vgo أيضًا للحفاظ على عمل البناء.

تحديث: راجع أيضًا https://github.com/golang/go/issues/24454

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

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

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

إذا كان الإصدار الرئيسي هو v0 أو v1 ، فيجب حذف عنصر رقم الإصدار ؛ وإلا يجب تضمينه.

لماذا هذا؟ في المنشور المرتبط ، أرى فقط الأساس المنطقي بأن هذا هو ما يفعله المطورون حاليًا لإنشاء مسارات بديلة عند إجراء تغييرات متقطعة - ولكن هذا حل بديل لحقيقة أنهم لا يخططون مبدئيًا للأدوات التي لا تتعامل مع الإصدارات الخاصة بهم . إذا كنا ننتقل إلى ممارسة جديدة ، فلماذا لا نسمح ونشجع (أو حتى التفويض) بأن الحزم الجديدة التي تدعم vgo تتضمن v0 أو v1 ؟ يبدو أن المسارات التي تفتقر إلى الإصدارات هي مجرد فرص للارتباك. (هل هذه حزمة vgo-style؟ أين حدود الوحدة؟ إلخ.)

يعجبني الاقتراح عمومًا ، لكنني أتعلق بطلب إصدارات رئيسية في مسارات الاستيراد:

1. إنه ينتهك مبدأ DRY عندما يكون الإصدار الرئيسي معروفًا بالفعل من go.mod . من الصعب أيضًا فهم ما سيحدث إذا كان هناك عدم تطابق بين الاثنين.
2. عدم انتظام السماح بتغيب v0 و v1 هو أمر غير بديهي أيضًا.
3. قد يبدو تغيير جميع مسارات الاستيراد عند ترقية التبعية مملاً.

أتفهم أن السيناريوهات مثل المثال moauth يجب أن تكون قابلة للتطبيق ، ولكن آمل ألا تكون على حساب إبقاء الأمور بسيطة للسيناريوهات الأكثر شيوعًا.

بادئ ذي بدء: عمل مثير للإعجاب!

شيء واحد غير واضح تمامًا بالنسبة لي ويبدو أنه غير محدد قليلاً:

لماذا يوجد ملفات مضغوطة في هذا الاقتراح؟

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

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

تتيح مناقشة هذا لاحقًا أيضًا لجماهير مختلفة المساهمة بشكل أفضل هنا.

ما المنطقة الزمنية المستخدمة للطابع الزمني في النسخة الزائفة (v0.0.0-yyyymmddhhmmss-الالتزام)؟

تعديل:
إنه بالتوقيت العالمي المنسق كما هو مذكور في https://research.swtch.com/vgo-module.

rsc هل ستتناول تبعيات C؟

يبدو أن تحديد الإصدار الأدنى يجعل نشر التغييرات غير المنقسمة بطيئًا للغاية. لنفترض أن لدينا مكتبة Foo شائعة ، والتي تستخدمها المشاريع A و B و C. شخص ما يحسن أداء Foo دون تغيير واجهة برمجة التطبيقات. تلقي التحديثات حاليًا هو عملية إلغاء الاشتراك. إذا لم يكن المشروع "أ" مورّدًا للمشروع "أ" ، ولكن "ب" و "ج" ، يحتاج المؤلف فقط إلى إرسال العلاقات العامة مع التحديث إلى التبعية الموردة إلى "أ" ، لذلك لن يكون للمساهمات غير المنفصلة عن واجهة برمجة التطبيقات تأثير كبير على المجتمع وستكون محبطة إلى حد ما مقارنة بالمساهمات الحالية قارة. هذا هو أكثر إشكالية بالنسبة للتحديثات الأمنية. إذا أعلن بعض المشاريع المهجورة / الصغيرة / غير النشطة للغاية (وليس مكتبة) الاعتماد المباشر على الإصدار القديم من على سبيل المثال x / crypto ، فسيكون جميع مستخدمي هذا المشروع عرضة للعيوب في x / crypto حتى يتم تحديث المشروع ، ومن المحتمل إلى الأبد. سيتلقى مستخدمو هذه المشاريع حاليًا أحدث إصدار ثابت ، مما يجعل الوضع الأمني ​​أسوأ. IIRC كانت هناك بعض الاقتراحات حول كيفية إصلاح هذا في مناقشة maillist ، ولكن بقدر ما أستطيع أن أقول أن هذا الاقتراح لا يذكره.

IIRC كانت هناك بعض الاقتراحات حول كيفية إصلاح [الحصول على تصحيحات أمنية] في مناقشة maillist ، ولكن بقدر ما أستطيع أن أقول أن هذا الاقتراح لا يذكره.

انظر الإشارة إلى go get -p .

انظر ذكر go get -p.

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

إذا تم إهمال دعم go get كما نعرفه اليوم وإزالته في النهاية ، فما هي الطريقة الموصى بها لجلب ثنائيات Go وتثبيتها (بدون علامات)؟ هل يتطلب الأمر git clone 'في المشروع أولاً ، متبوعًا بدليل go install لتثبيت البرنامج الثنائي؟
إذا تم إهمال $GOPATH ، فأين سيتم تثبيت هذه الثنائيات؟

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

أتساءل كيف سيؤثر هذا على تدفق العمل مع مستودع Git بشكل عام ، وكذلك البناء على هذه الجملة من الاقتراح:

إذا كان الإصدار الرئيسي هو v0 أو v1 ، فيجب حذف عنصر رقم الإصدار ؛ وإلا يجب تضمينه.

في الوقت الحالي ، يبدو من الشائع العمل على المستوى الرئيسي (بالنسبة لي ، يشمل ذلك فروع الميزات قصيرة العمر) ووضع علامة على الالتزام بإصدار جديد بين الحين والآخر. أشعر أن سير العمل هذا أصبح أكثر إرباكًا مع وحدات Go النمطية بمجرد إصدار الإصدار 2 من مكتبتي ، لأن لدي الآن فرع $ # $ master v2 . أتوقع أن يكون master هو الفرع الحالي و v2 سيكون فرع صيانة ، لكن العكس هو الصحيح.

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

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

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

الآن لدي ماجستير وفرع v2

يمكنك بدلاً من ذلك إنشاء دليل فرعي v2/ رئيسي.

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

أفضل أن يكون لدي فرع رئيسي وفرع v1 ، لكني لست متأكدًا من مدى ملاءمة ذلك للاقتراح.

وفقًا لفهمي لـ https://research.swtch.com/vgo-module ، تستخدم vgo العلامات وليس الفروع لتحديد الإصدارات. لذا يمكنك الاستمرار في التطوير على المستوى الرئيسي والتفرع v1 طالما أن العلامات تشير إلى الفرع الصحيح وتلتزم به.

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

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

إن مواجهة اتفاقيات سير عمل المبرمج الشائعة ليست تكلفة بسيطة على الإطلاق.

أحيانًا يكون عدم اتباع المسار التقليدي شرطًا ضروريًا للابتكار.

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

أعتقد أن mrkanister ، بالنسبة إلى dev ، استنساخ سيدك (أو أي فرع من فروع dev) واستخدم التوجيه "replace" (انظر vgo-tour) للإشارة إليه. (إذا فهمت ما تعنيه ، لست متأكدًا).

rsc ، أود أن أطلب منك أن تكون أكثر دقة بشأن خريطة الطريق وما يجب أن نفعله الآن.
هل ستتبع سياسة Go وميزة Freeze vgo في 3 أشهر (2 الآن)؟
هل يجب أن نذهب الآن مع عصا الحاج ونطلب من كل مشرف ليبس إضافة ملف go.mod أم يجب أن ننتظر حتى يتم قبول الاقتراح رسميًا (للتأكد من أن الاسم والصيغة لن يتغير)؟

أدوات flibustenet غير مشمولة بسياسة 1.0 لذا يمكن تغيير أي شيء.

https://golang.org/doc/go1compat

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

أيضا من الاقتراح

الخطة ، التي تخضع لموافقة الاقتراح ، هي إصدار دعم الوحدة النمطية في Go 1.11 كميزة اختيارية قد لا تزال تتغير. سيعطي إصدار Go 1.11 للمستخدمين فرصة لاستخدام الوحدات "الحقيقية" وتقديم ملاحظات نقدية. على الرغم من أن التفاصيل قد تتغير ، إلا أن الإصدارات المستقبلية ستكون قادرة على استهلاك أشجار المصدر المتوافقة مع Go 1.11. على سبيل المثال ، سوف يفهم Go 1.12 كيفية استهلاك بنية ملف Go.mod Go 1.11 ، حتى لو تم تغيير بناء جملة الملف أو حتى اسم الملف. في إصدار لاحق (على سبيل المثال ، Go 1.12) ، سنعلن اكتمال دعم الوحدة. في إصدار لاحق (على سبيل المثال ، Go 1.13) ، سننهي دعم go get of non-modules. سيستمر دعم العمل في GOPATH إلى أجل غير مسمى.

شكرا على ملاحظاتك.

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

وفقًا لفهمي لـ https://research.swtch.com/vgo-module ، تستخدم vgo العلامات وليس الفروع لتحديد الإصدارات. لذا يمكنك الاستمرار في التطوير على المستوى الرئيسي والتفرع v1 طالما أن العلامات تشير إلى الفرع الصحيح وتلتزم به.

أنت على صواب ، سيستمر هذا في العمل كما كان من قبل (فقط تحقق مرتين للتأكد) ، صيد جيد!

مع هذا بعيدًا ، الشيء الذي لا أفهمه (والآخرون على ما يبدو) هو السبب وراء عدم السماح بوجود حزمة v1 . حاولت استيراد واحد باستخدام /v1 في نهاية عملية الاستيراد وإضافة ذلك أيضًا إلى go.mod للحزمة التي يتم استيرادها ، ولكن vgo سيبحث عن مجلد باسم v1 بدلاً من ذلك.

تضمين التغريدة
أعتقد أن السبب الرئيسي لعدم السماح لـ v1 أو v0 في مسار الاستيراد هو التأكد من وجود مسار استيراد واحد فقط لكل إصدار متوافق من الحزمة.
استخدام مسار الاستيراد العادي بدلاً من / v1 لتسهيل الانتقال ، لذلك لا يتعين عليك تحديث جميع مسارات الاستيراد لإضافة / v1 في النهاية.

مرحبا،

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

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

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

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

تم نسخ سؤالي الذي لم يتم الرد عليه من القائمة البريدية:

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

يبدو أن هناك أدلة فرعية واصطلاح الفرع الرئيسي هذا مدعوم من vgo. في تجربتي القصصية ، لا تتبع أي مستودعات هذه الاتفاقية في Go أو لغات أخرى (لا يمكنني في الواقع التفكير في واحدة أخرى غير تلك التي فرضها gopkg.in والتي تبدو غير مستخدمة نسبيًا هذه الأيام). الفرع الرئيسي هو الأحدث ولديه علامات v2.3.4 في تاريخه. توجد العلامات لفصل كل شيء (وليس فقط النسخ الثانوية). إذا كان من الضروري تصحيح إصدار قديم ، فسيتم إنشاء فرع مؤقتًا من آخر علامة v1 ، والالتزامات المدفوعة ، ودفع علامة جديدة ، وحذف الفرع مؤقتًا. لا يوجد فرع للإصدارات ، إنه مجرد فروع رئيسية / مطورة / مميزة + علامات الإصدار. أعلم أن "كل شيء عبارة عن مرجع" في Git ، ولكن بالنسبة إلى VCS الأخرى ، قد لا يكون التمييز غامضًا.

بعد قولي هذا ، لقد اختبرت سير العمل الموصوف أعلاه باستخدام vgo (مجرد وجود علامات تقول v2.0.0 و v2.0.1 ولا توجد فروع) ويبدو أنها تعمل. إذن سؤالي هو: على الرغم من أن هذا يعمل الآن ، فهل هو مقصود؟ نظرًا لأنه لا يبدو موصوفًا تمامًا مثل عمليتي سير العمل الآخرين في المدونة ، وأريد التأكد من أن العمل بدون v2 / v3 ... الفرع ليس وظيفة عرضية ستختفي لأنني كما أوضحت أعلاه لم أقم أبدًا رأيت هذا (أو غيره) سير العمل الموصوف في المنشور ليتم تبنيه على نطاق واسع من قبل أي شخص (خاصة خارج مجتمع Go).

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

شكرا جميعا على جهودكم.

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

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

نموذج MVS المقترح كما أفهمه هو

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

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

من الواضح أنني أفتقد شيئًا (وسأشعر بالغباء بعد حوالي 5 أمتار) ، ما هذا؟

tpng

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

هذا في الواقع لا ينبغي أن يكون ضروريا. اسمحوا لي أن أقدم مثالا على ذلك:

يستخدم المستخدم حاليًا على سبيل المثال v1.0.0 من مكتبة ، مثبت بواسطة مدير التبعية والعلامة في المستودع الرئيسي. الآن قرر المنبع إنشاء go.mod واستدعاء الوحدة أيضًا /v1 . يجب أن ينتج عن ذلك التزام جديد وعلامة جديدة (مثل v1.0.1 ). نظرًا لأن vgo لن يحاول أبدًا تحديث التبعيات من تلقاء نفسه ، فلا ينبغي أن يؤدي ذلك إلى كسر أي شيء للمستخدم ، ولكن يمكنه / يمكنها التحديث بوعي أيضًا عن طريق تغيير مسار الاستيراد (يمكن لـ pr vgo القيام بذلك له / لها).

أعتقد أن السبب الرئيسي لعدم السماح لـ v1 أو v0 في مسار الاستيراد هو التأكد من وجود مسار استيراد واحد فقط لكل إصدار متوافق من الحزمة.

نعم ، أعتقد أنه يمكنني بالفعل رؤية هذه النقطة لعدم إرباك المستخدمين الجدد للمكتبة.

إذا كان الإصدار الرئيسي هو v0 أو v1 ، فيجب حذف عنصر رقم الإصدار ؛ وإلا يجب تضمينه.

هل يمكن لأحد أن يشرح السبب وراء ذلك؟ ماذا أفعل ، كمستخدم لمكتبة ، عندما لا أرغب في استخدام الإصدار 1 حتى الآن ، لأنه أدخل تغييرًا مفاجئًا ، والذي سيكون جيدًا تمامًا مع الإصدار الدلالي (إصدار رئيسي جديد)؟

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

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

ماذا أفعل ، كمستخدم لمكتبة ، عندما لا أرغب في استخدام الإصدار 1 حتى الآن ، لأنه أدخل تغييرًا مفاجئًا ، والذي سيكون جيدًا تمامًا مع الإصدار الدلالي (إصدار رئيسي جديد)؟

بقدر ما فهمت ، لن يقوم vgo أبدًا بتحديث التبعيات من تلقاء نفسه ، ولا حتى إلى إصدار التصحيح ، ولكن بدلاً من ذلك اترك هذا كقرار واعٍ لتتخذه. لذلك إذا كنت تعتمد على الإصدار 0.4.5 من مكتبة (التي تحتوي على وسم لها) ، فيمكنك نظريًا الاستمرار في استخدامها إلى الأبد. ستتمكن أيضًا من تثبيت الإصدار يدويًا في ملف go.mod .

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

إذا أردنا أن يكون الإصدار 1 أيضًا جزءًا من مسار الاستيراد ، فسيتم التعامل مع كليهما كحزم مختلفة ، وهو نوع من أنواع الحزم.

kaikuehne ثم سيتم تحديثه إلى الحد الأدنى من الإصدار المشترك الذي يعمل. (على فهمي)

kaikuehne أنا لا أفهم تفكيرك. أنت تستخدم v0 ، لذلك من المفترض أنك على ما يرام مع كسر التغييرات ؛ لماذا قد تكون مشكلة إذا تعطل الإصدار 1 ، نظرًا لأنك تستخدم بالفعل إصدارًا لا يضمن الاستقرار؟ علاوة على ذلك ، لنقل بدلاً من الانتقال من v0.1-> v1.0 مع تغيير كسر ، فإن upstream سيضيف الفاصل إلى v0.2 ثم يطلق (غير قابل للكسر) v1.0. قد يبدو هذا ضمن التوقعات حول الإصدارات الدلالية ، ولكنه قد يصل إلى نفس القدر من الكدح بالنسبة لك (بغض النظر عن مدير الحزم المستخدم). أي لا أفهم حقًا كيف تشكل "توقف المؤلف فجأة عن كسر واجهة برمجة التطبيقات الخاصة به" مشكلة لا تنتج عن استخدام إصدار ما قبل 1.0.

بعبارة أخرى: باستخدام v0.x ، فأنت تقبل أن v0. (x + 1) قد يجبرك على إصلاح التعليمات البرمجية الخاصة بك. لماذا تعتبر مشكلة إذا كان v0. (x + 1) يسمى v1.0 بدلاً من ذلك؟

حول نقطة المناقشة 4: اعتماد قاعدة توافق الاستيراد صراحة و "يجب أن تكون الحزمة الجديدة متوافقة مع الإصدارات السابقة للحزمة القديمة" ...

في حالتي ، لدي حزمة أمان https://github.com/microcosm-cc/bluemonday وأنا مؤخرًا (أواخر العام الماضي) كان لدي سيناريو علمت فيه أن الوظيفة العامة لم تكن مناسبة بشكل أساسي للغرض. لذا أزلته.

بموجب هذا الاقتراح ، إذا قمت بإزالة func ، فسوف تصطدم بالإصدار ولن تتم إزالة الشفرة غير الآمنة / غير الآمنة.

لتجنب ذلك ، ربما سأقوم بدلاً من ذلك بتسجيل الدخول.

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

لأولئك الذين يرغبون في رؤية الالتزام بهذا: https://github.com/microcosm-cc/bluemonday/commit/a5d7ef6b249a7c01e66856b585a359970f03502c

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

@ buro9 يقترح الاقتراح اتباع ضمانات التوافق go1 تقريبًا ، والتي تحتوي على استثناءات لأعطال API المتعلقة بالأمان.

kaikuehne شكرا ، هذا يوضح قلقك.

هناك تفاعل بين الميزات التي أشعر بالقلق حيالها (على افتراض أنني أفهم الأشياء بشكل صحيح).

إذا كان لديك وحدة نمطية M تستخدم إصدارات مُحددة (أدلة vN الحرفية في المصدر ، وليس عناصر مسار استيراد اصطناعية مشتقة من العلامات) ، وكنت تقوم ببناء برنامج P يعتمد على إصدارات رئيسية متعددة من M بشكل عابر ، فلن يفعل ذلك يجب أن تنتهك الحد الأدنى من اختيار الإصدار في بعض السيناريوهات؟

أي ، لنفترض أن P تعتمد على الإصدارات الرئيسية 2 و 3 و 4 من M. لكل إصدار رئيسي من M ، هناك حد أدنى من الإصدار الكامل المحدد. نظرًا لأن إصدارات M share source للغرض الصريح المتمثل في القدرة على القيام بأشياء مثل استخدام نفس تعريف النوع بشفافية مع الأسماء المستعارة للنوع ، فيمكن عندئذٍ تضمين نسخة واحدة فقط من M لجميع الإصدارات الرئيسية الثلاثة بدلاً من نسخة واحدة لكل إصدار رئيسي. أي اختيار لإصدار كامل لإصدار رئيسي واحد يعمل على إصلاح خيار الإصدار الكامل للإصدارين الرئيسيين الآخرين ويمكن أن يؤدي إلى تحديد إصدار غير مبسط لأحد الإصدارين الرئيسيين الآخرين أو كليهما.

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

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

إذا كنت تستخدم أدلة الإصدارات الرئيسية ، فستظل vgo تستخدم العلامات ثم تحصل فقط على مجلد الإصدار المطابق لتلك العلامة. على سبيل المثال ، أنت تعتمد على الإصدارات 2 و 3 و 4. vgo سوف تحقق من علامة v2.nm و v3.nm و v4.nm
وبعد ذلك من العلامة v2.nm احصل فقط على المجلد v2 وما إلى ذلك. لذلك في النهاية لا يزال كل شيء يتبع العلامات.

لقد طرحت سؤالاً في منشور القائمة البريدية هذا ، لكني لم أر إجابة محددة. سأكررها هنا:

ماذا سيحدث مع موارد non-Go ، مثل ملفات protobufs أو c؟ نأسف إذا تمت الإجابة على هذا بالفعل في مشاركاتك ، لكننا نستخدم مسار البائع لتوزيع وتعيين مسار الاستيراد لملفات protobuf. بينما سنقوم بتجميع Go pacakges مقابل إخراج protobuf المُجمَّع مسبقًا ، علينا أيضًا أن نأخذ في الاعتبار حالة تجميع حزم Go جديدة من ملفات protobuf التي تعتمد على التبعيات الموردة (أي مراجع rpc.Status من ملف protobuf آخر). يمكنني تقديم بعض الأمثلة الملموسة إذا كان هذا الوصف كثيفًا جدًا.

على وجه التحديد ، لدي مشروع يسمى protobuild الذي يسمح للشخص بتعيين استيراد ملف protobuf إلى مواقع GOPATH. لا أرى كيف سيتعامل هذا الاقتراح مع تحليل الموارد في GOPATH وكيف يمكننا تعيين ذلك في مساحات استيراد المترجم الأخرى.

كانت هذه نقطة ألم كبيرة للعمل مع protobufs بالنسبة لنا وهذا المشروع خفف الكثير من تلك المشاكل. سيكون من العار إذا كان هذا غير متوافق تمامًا مع الاقتراح.

مرة أخرى ، أعتذر إذا فاتني شيء.

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

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

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

كسر التغيير هو تغيير جذري. لا يمكن أن تكون صغيرة أو كبيرة. أفترض أن مثل هذه الحزم سيتم رفضها في النهاية من قبل المجتمع باعتبارها غير موثوقة للغاية ولا تتبع semver. حتى لو اتبعوا semver ووصلوا بسرعة إلى رقم رئيسي كبير مثل 42.xx ، فسيكون استخدامها غير مريح على أي حال. لذا ، إذا كنت تريد إجراء الكثير من التغييرات الفاصلة ، فما عليك سوى الاستمرار في استخدام الرقم الرئيسي 0. وبهذه الطريقة سيستمر العمل تمامًا مثل go get الحالي ، مع نفس المشكلات. إذا كنت تريد تجربة واجهة برمجة التطبيقات (API) بعد إصدار إصدار رئيسي غير 0 - انقل هذه التجارب لفصل الحزمة "التجريبية" مع 0 رئيسي للأبد وزيادة رئيسية للحزمة الرئيسية عند الانتهاء من "تغييرات كسر صغيرة" وأخيراً الحصول على واجهة برمجة تطبيقات مستقرة تالية.

تضمين ثانوي في مسار الاستيراد ينتهك أيديولوجية semver ولا يوفر أي ميزات جديدة فوق تضمين الرئيسي.

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

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

من المحتمل إنشاء بيانات أفضل هنا من go corpus (وأداة تبحث عن تغييرات كسر واضحة) لتحديد عدد المرات التي يُقال فيها semver غالبًا بين المشاريع الشائعة الحالية التي تستخدم علامات semver.

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

يسمح اقتراح vgo لإصدار رئيسي واحد بالإشارة إلى إصدار رئيسي آخر ، مما يسمح بإعادة استخدام التعليمات البرمجية بشكل رشيق. لا تفعل شيئا لفرض ذلك.

يسمح اقتراح vgo MVS بالتحديث إلى الحزم الأحدث. لا يجبرك على التحديث.

فيما يلي بعض الأشياء التي يمكننا بناؤها بسهولة أكبر في عالم vgo:

1. الأدوات اللازمة للقبض على تغييرات الكبح API قبل الدفع إلى مضيف الوحدة. كل إصدار في ملف مضغوط ويمكن مقارنته بدون العديد من أدوات وأوامر vcs المختلفة.
2. تسجيل قضية الأمان. استضف جنبًا إلى جنب من استضافة الوحدة للحصول على قيمة مضافة. يمكن للأدوات الاستعلام عنها بطريقة مماثلة لـ go list إما يدويًا أو تلقائيًا والحصول على إشعار بالمشكلات التي تمت تصفيتها بواسطة استعلام.

يجعل vgo هذه أسهل من خلال:

• تقييد مساحة المشكلة (العمل فقط مع ملفات مضغوطة ، لا حاجة لتخزين سجل git / hg / svn التعسفي لإجراء مقارنات API).
  
  
  
  • تحديد مساحة المشكلة (MVS ، تعريف الإصدار)
  
  
• تجهيز جزء البناء.

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

يجب ألا نخلط بين ما يسمح به vgo وما هو vgo.

@ pbx0 لست متأكدًا من أن هذا هو المكان المناسب لمثل هذه المناقشة ، فربما يكون maillist أكثر ملاءمة. في أي حال ، يحدث كسر التغييرات دون تغيير الرقم الرئيسي. حتى في بعض الأحيان. تم الرد على هذه الحالة من Semver في الأسئلة الشائعة:

بمجرد أن تدرك أنك قد كسرت مواصفات Semantic Versioning ، أصلح المشكلة وأصدر نسخة ثانوية جديدة تصحح المشكلة وتستعيد التوافق مع الإصدارات السابقة.

لكني أعتقد أن هناك مكانًا للتحسين هنا. أفترض أنه يجب أن يكون الأمر سهلاً بدرجة كافية لتنفيذ مدقق API الآلي (ربما يوجد واحد بالفعل) ، والذي سيأخذ جميع الحزم المدرجة في godoc.org ويتحقق دوريًا من الإصدارات الجديدة ، وفي حالة اكتشاف الإصدار الجديد ، تحقق من الإصدار الجديد المتوافق مع السابق الإصدار API في حالة استخدام علامات semver ولم يتم تغيير التخصص. ثم حاول الاتصال بالمؤلف في حالة اكتشاف تغيير غير متوافق - ربما مشكلات الفتح التلقائي على جيثب أو استخدام البريد الإلكتروني من حساب جيثب. لن يغطي هذا جميع الحالات المحتملة ، ولكنه قد يكون مفيدًا جدًا للمجتمع.

أنا أؤمن بشدة باستخدام المسارات لتحديد نطاق الإصدارات الرئيسية وأردت التعبير عن دعمي ، FWIW.

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

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

من الاقتراح:

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

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

المشروع الذي يستخدم البيع اليوم لا يتطلب سوى سلسلة أدوات Go و Git (أو أي نظام آخر للتحكم في الإصدار). توجد نقطة فشل واحدة فقط: مستودع git. بمجرد سحب الرمز ، يمكن بناؤه وإعادة بنائه بشكل مثالي دون الحاجة إلى لمس الشبكة مرة أخرى - وهو اعتبار أمني مهم. بالنسبة لمعظمنا ، لا يتطلب مشروع البائع أي بنية تحتية إضافية - فقط الكمبيوتر المحلي وحساب GitHub المجاني.

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

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

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

joeshaw ستظل قادرًا على استخدام دليل البائع لإنشاء بنية قائمة بذاتها.

من الاقتراح:

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

المشروع الذي يستخدم البيع اليوم لا يتطلب سوى سلسلة أدوات Go و Git (أو أي نظام آخر للتحكم في الإصدار). توجد نقطة فشل واحدة فقط: مستودع git.

اليوم ، إذا كنت تستضيف حزمًا ضمن نطاقك الخاص ، فأنت بحاجة إلى أ) استضافة مستودع git و ب) تقديم علامات <meta> الضرورية لـ go-get للعثور عليها. في المستقبل ، تحتاج إلى أ) تقديم ملفات .zip و .json اللازمة لـ vgo لجلب الكود. يبدو أن هناك نقاط فشل أقل وبنية تحتية أقل مطلوبة للاستضافة المحضة. بالطبع ما زلت بحاجة إلى استضافة المستودع من أجل التطوير ، ولكن هذا لا يرفعنا في أسوأ الأحوال إلى نفس المستوى كما كان من قبل ، بل يتطلب المستودع نفسه أيضًا استضافة أقل قابلية للتطوير وموثوق بها ، لأنه يستخدم فقط من قبل الأشخاص الذين يطورون بالفعل.

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

إذا كنت ، OTOH ، لا تستخدم عمليات استيراد الغرور ، فأنت تتجاهل كل البنية التحتية التي يعمل جيثب عليها من أجلك. لذلك لا يبدو أن هذه مقارنة من تفاح إلى تفاح: الطريقة الوحيدة التي تظهر بها هي أنك تسمح للآخرين بحل المشاكل الصعبة. لكن لا يوجد ما يمنعك من القيام بذلك في المستقبل. AIUI لقد تطوعت Microsoft وغيرها بالفعل لاستثمار ساعات هندسية وخدمة القدرات في هذه المهمة. أتوقع أنه في المستقبل ، ستقل جهود استضافة حزم Go تقريبًا عن طريق استضافة الحزم أو الأحجار الكريمة أو الصناديق npm: لديك مستودع github ثم انقر فوق الزر "إتاحة هذا" في بعضها مركزيًا خدمة مُدارة لاستضافة الكود البريدية.

اعتماد vgo على الوكلاء

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

تسمح اللغات الأخرى باستخدام وكلاء التخزين المؤقت.

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

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

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

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

إذا ، OTOH ، لا تستخدم عمليات استيراد الغرور ، فأنت تتجاهل كل البنية التحتية التي يعمل جيثب عليها من أجلك.

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

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

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

المشكلة هي أن هذا يضيف نقاط فشل واحدة (SPOFs) لبناء مشروع. سيعيش الرمز في VCS بغض النظر عن أي شيء (وربما GitHub) ، لذلك هذا هو SPOF واحد. في اللغات الأخرى ، يكون المستودع المركزي هو SPOF الثاني. بالنسبة إلى Go ، كل مسار استيراد هو SPOF إضافي (github.com و golang.org و honnef.co و rsc.io وما إلى ذلك) وتؤدي زيادة SPOF إلى تقليل التوفر العام.

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

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

أنا سعيد لأن "المستوى الأعلى vendor " سيظل تكوينًا مدعومًا لأنني أحب git grep كثيرًا.

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

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

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

jamiethermo هل البيع لا يعالج ذلك من أجلك اليوم؟

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

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

هل البيع لا يعالج ذلك من أجلك اليوم؟

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

فيما يتعلق بـ "كيف يجب أن أنظم الكود الخاص بي" ، فإن هذه الصفحة ، How to Write Go Code ، تقدم تعليمات حول بنية الدليل ، لكنها لا تذكر البائعين.

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

الحزم التي تم استيرادها كـ my / thing / sub / pkg و my / thing / v2 / sub / pkg و my / thing / v3 / sub / pkg تأتي من الإصدارات الرئيسية v1 و v2 و v3 من الوحدة my / thing ، ولكن يعاملهم الإصدار ببساطة على أنهم ثلاث حزم مختلفة.

يمكن أيضًا أن يكون my / thing / sub / pkg v0.0.

تابعت الجولة . تم بناء المثال خارج شجرة GOPATH ، وهو يعمل ، بينما dep init barfs في هذه الحالة. أعتقد أنني أعمل مع 80 فريقًا الآن ، وسيكون من الجيد حقًا ألا تضطر إلى امتلاك شجرة عملاقة واحدة. (بينما كنت أكتب هذا ، سار شخص ما بحاسوبه المحمول ووجهه عابس ، و "لدي هذا الخطأ الغريب حقًا ...")

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

يمكنك الحصول على كل هذا العمل الرائع على البنية التحتية والحفاظ على الجهوزية مجانًا أو بتكلفة معقولة.

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

لذلك سيتم معالجة مخاوفك في ما أعتبره السيناريو الأكثر احتمالا: أن هيئة ممولة (حاليا Microsoft تتشكل لتكون كذلك) تقوم باستضافة الملفات المضغوطة.

على الرغم من أنني أحب أناقة إحضار Git واحد - إجراء ذري من منظور المستخدم

vgo get هو إجراء ذري بنفس القدر ويقوم بعمل أقل ، من نفس الطبيعة (طلبات HTTP) التي يسهل فهمها.

المشكلة هي أن هذا يضيف نقاط فشل واحدة (SPOFs) لبناء مشروع.

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

في اللغات الأخرى ، يكون المستودع المركزي هو SPOF الثاني. بالنسبة إلى Go ، كل مسار استيراد هو SPOF إضافي (github.com و golang.org و honnef.co و rsc.io وما إلى ذلك) وتؤدي زيادة SPOF إلى تقليل التوفر العام.

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

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

و FTR ، في الوقت الحالي ، يعد git-hosting الخاص بك هو SPOF: إذا كان مضيف git الخاص بك معطلاً ، فلن يتمكن المستخدمون من التثبيت ولا يمكنك التطوير.

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

وكانت نقطتي (التي تمت صياغتها بشكل سيء) أعلاه ، هي أن الأمر كذلك بالفعل :) أنت ببساطة أ) تتجاهل حدوث ذلك الآن و ب) تفترض أنه لن يحدث في المستقبل :)

لإعطاء منظور مختلف:

• نحن نبني العديد من مشاريع Go باستخدام مدير مكونات البرامج متعدد اللغات على مستوى النظام (rpm / dnf في Fedora و Centos و RHEL)
• يسمح لنا باستخدام الكثير من نفس الحيل مثل اقتراح vgo ، من خلال اللعب على مساحة اسم مكون طبقة rpm (عادةً ، إعادة تسمية مشروع على مستوى مساحة الاسم rpm من المشروع إلى التوافقية مع المشروع x للسماح بالتمييز بين الإصدارات غير المتوافقة من نفس مسار الاستيراد ، تمامًا مثل vgo الذي سيفعله).
• هذه الحيل مفيدة بالتأكيد في المساعدة في بناء مشاريع Go المعقدة
• على الرغم من أنها ليست كاملة وقوية مثل القيام بذلك على مستوى اللغة
• نفضل ترحيل قيود اللغة إلى rpm / dnf بدلاً من إضافة تراكب rpm / dnf للقيود على الكود الأصلي.
• لقد سئمنا تمامًا من جميع حلول نظام الملفات اللازمة حاليًا لإقناع أدوات go بالاطلاع على مصادر مشروع Go. لن تفوت GOPATH المادية على الإطلاق.

لذلك نحن سعداء للغاية بشأن vgo ونأمل أن يتم نشره قريبًا (كنا في حاجة إليه منذ سنوات).

ومع ذلك ، فإن استخدامنا لمهام سير العمل الشبيهة بـ vgo كشف عن الصعوبات التالية.

يهنئ اقتراح vgo نفسه على جعل ملفات makefiles غير ضرورية. هذا ليس صحيحا تماما.

• وقعت الكثير من مشاريع Go في حب ملفات go التي تم إنشاؤها تلقائيًا ولا توجد طريقة قياسية للمطالبة بتجديدها أو للتعبير عما يحتاجه الجيل ليكون ناجحًا
• إنه لأمر سيء للغاية أن العديد من المشاريع يجب أن يتم شحنها مع ملفات مُنشأة مسبقًا (في بعض الأحيان تشكل مستودعات كاملة منفصلة للملفات التي تم إنشاؤها مسبقًا)
• هذه الملفات هي مصدر كبير لعدم توافق الإصدار. يحرص البشر على كتابة تعليمات برمجية لا تحتاج إلى تغيير كل يوم عند تعرضهم لإصدارات تبعية جديدة. غالبًا ما تكون الملفات التي يتم إنشاؤها تلقائيًا OTOH مرتبطة ارتباطًا وثيقًا ببيئة التوليد الدقيقة ، لأن مؤلفي أدوات التوليد يفترضون أنك ستقوم بإعادة إنشائها حسب الحاجة.
• لكي يكون vgo ناجحًا ، يحتاج إلى طريقة لتحديد تلك الملفات ، وتجريدها من وحدات .zip ، والتعبير عن كيفية إعادة إنشائها لمستخدمي الوحدات النمطية .zip

ومما زاد الطين بلة القاعدة الحالية "كل شيء يجب أن يكون في GOPATH"

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

استغلت الكثير من المشاريع قاعدة "كل دليل Go عبارة عن حزمة منفصلة" لنشر مشاريع ذات تعليمات برمجية غير متوافقة أو معطلة تمامًا في أدلة فرعية منفصلة

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

إن الممارسة الحالية المتمثلة في تعريض قاعدة بيانات Go بالكامل في شجرة GOPATH واحدة مع وجود حدود قليلة بين المشاريع قد أدت إلى آثار جانبية ضارة من أسير حرب في هندسة البرمجيات

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

الاختبار / التركيبات ، المثال وبيانات الاختبار عبارة عن علبة أخرى كاملة من الديدان ، مع احتياجات التبعية والاعتماد الخاصة بهم

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

ربما نسيت الكثير من الأشياء ، لكنها الأكثر أهمية.

أخيرا:

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

على الخوادم الوكيلة:

لتصحيح الأخطاء بسهولة ، يمكن أن يكون $ GOPROXY ملفًا: /// URL يشير إلى شجرة محلية.

يرجى جعله يعمل مع ملف: /// من https: /// URL يشير إلى دليل يحتوي على وحدات طرف ثالث في شكل مضغوط (واستبعد كل شيء آخر)

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

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

لا أوافق علىMerovius ، لكنني أعتقد أننا نبتعد عن الموضوع ولا نريد أن نتسبب في تعثر مناقشة القضية. ومع ذلك ، يسعدني المتابعة بطريقة مختلفة. (بريدي الإلكتروني موجود في ملفي الشخصي على جيثب وأنا جوشو في Gophers Slack.)

https://github.com/golang/go/issues/24301#issuecomment -374882685، tpng :

ما المنطقة الزمنية المستخدمة للطابع الزمني في النسخة الزائفة (v0.0.0-yyyymmddhhmmss-الالتزام)؟

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

https://github.com/golang/go/issues/24301#issuecomment -374907338 ، AlexRouSg :

هل ستتناول تبعيات C؟

https://github.com/golang/go/issues/24301#issuecomment -376606788 ، stevvooe :

ماذا سيحدث مع موارد non-Go ، مثل ملفات protobufs أو c؟

https://github.com/golang/go/issues/24301#issuecomment -377186949 ، @ nim-nim:

يهنئ اقتراح vgo نفسه على جعل ملفات makefiles غير ضرورية. هذا ليس صحيحا تماما. [مناقشة التعليمات البرمجية التي تم إنشاؤها.]

يستمر تطوير Non-Go في كونه ليس هدفًا للأمر go ، لذلك لن يكون هناك دعم لإدارة مكتبات C وما شابه ، ولن يكون هناك دعم صريح للمخازن المؤقتة للبروتوكول.

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

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

https://github.com/golang/go/issues/24301#issuecomment -375248753 ، mrkanister :

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

كما أشارAlexRouSg وربما آخرون ، يمكنك القيام بذلك. أردت فقط أن أؤكد إجاباتهم. سأضيف هذا أيضًا إلى التعليمات.

https://github.com/golang/go/issues/24301#issuecomment -375989173 ، @ aarondl :

على الرغم من أن هذا يعمل الآن ، فهل هو المقصود؟

بكل تأكيد نعم.

jamiethermo ، شكرًا جزيلاً على التعليق حول Perforce والفروع في الدلائل المختلفة. لقد نسيت هذه الميزة ، ولكن ربما هذا ما أقنعني أنه من المهم السماح بـ vgo.

كانت هناك مناقشة لطيفة بدأت على https://github.com/golang/go/issues/24301#issuecomment -376925845 حول البيع مقابل الوكلاء. من الواضح أن هناك مجموعتين متميزتين من المخاوف هنا.

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

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

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

https://github.com/golang/go/issues/24301#issuecomment -377220411 ، @ nim-nim:

يرجى جعله يعمل مع ملف: /// من https: /// URL يشير إلى دليل يحتوي على وحدات طرف ثالث في شكل مضغوط (واستبعد كل شيء آخر)

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

https://github.com/golang/go/issues/24301#issuecomment -377186949 ، @ nim-nim:

واو ، هذا تعليق طويل. أعتقد أنني أتفق مع معظم ما كتبته. أريد الرد على آخر رصاصة في منشورك:

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

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

https://github.com/golang/go/issues/24301#issuecomment -375415904، flibustenet :

rsc ، أود أن أطلب منك أن تكون أكثر دقة بشأن خريطة الطريق وما يجب أن نفعله الآن.
هل ستتبع سياسة Go وميزة Freeze vgo في 3 أشهر (2 الآن)؟

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

هل يجب أن نذهب الآن مع عصا الحاج ونطلب من كل مشرف ليبس إضافة ملف go.mod أم يجب أن ننتظر حتى يتم قبول الاقتراح رسميًا (للتأكد من أن الاسم والصيغة لن يتغير)؟

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

https://github.com/golang/go/issues/24301#issuecomment -376640804، @ pbx0 :

هل من السهل (اليوم) باستخدام vgo تحديد ما إذا كان لديك أكثر من إصدار واحد من الحزمة في الإنشاء؟

أسهل ما يمكنك فعله اليوم هو إنشاء الثنائي ثم تشغيل goversion -m عليه (راجع https://research.swtch.com/vgo-repro). عندما يكون لدينا قائمة انتقال أكثر عمومية للوحدة النمطية ، يجب أن تكون قادرة على فعل الشيء نفسه دون إنشاء الملف الثنائي أولاً.

https://github.com/golang/go/issues/24301#issuecomment -376236546، @ buro9 :

[هل يمكنني إجراء تغيير أمني غير متوافق مع الإصدارات السابقة ، مثل microcosm-cc / bluemonday @ a5d7ef6؟ ]

كما قال Merovius ، إذا اعتمدنا إرشادات توافق Go 1 ، فسيُسمح صراحةً بتغييرات الأمان دون الإضرار بالإصدار الرئيسي.

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

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

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

وبعد ذلك ، يبدو أن القلق كان أن نوع المستند لم يتم فحصه تمامًا ، لكن من المحتمل أن أضع حدًا أدنى من التحقق للحفاظ على الاستخدامات الأكثر شيوعًا تعمل ، ثم أرفض الآخرين بحذر. على سبيل المثال ، على الأقل ، كنت سأستمر في السماح وربما أزعجت نفسي أيضًا للسماح بسلاسل مقتبسة بدون & # <> \ chars.

https://github.com/golang/go/issues/24301#issuecomment -375090551، TocarIP :

[مخاوف بشأن عدم الحصول على التحديثات على الفور.]

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

ما كتبه Merovius في https://github.com/golang/go/issues/24301#issuecomment -375992900 يبدو مناسبًا تمامًا بالنسبة لي. النقطة الأساسية هي أنك لا تحصل على التحديثات إلا عندما تطلبها ، لذلك (من المحتمل) أن تتعطل الأشياء فقط عندما تتوقع ذلك وتكون جاهزًا للاختبار والتصحيح وما إلى ذلك. عليك أن تسأل عنهم ، ولكن ليس أكثر بكثير من الأنظمة الأخرى ذات ملفات القفل. ونريد أيضًا أن نجعل من السهل إظهار تحذيرات مثل "أنت تبني إصدارًا مهملاً / غير آمن". لكن من المهم عدم التحديث بصمت كأثر جانبي لعمليات عدم التحديث.

تمت إضافته أيضًا إلى التعليمات.

شكرًا للجميع على المناقشة الرائعة حتى الآن وعلى الإجابة على أسئلة بعضهم البعض. إجابات رائعة حقًا من الكثير من الأشخاص ، لكن شكر خاص لـ @ Merovius و @ kardianos. لقد قمت بتحديث الأسئلة الشائعة https://github.com/golang/go/issues/24301#issuecomment -371228664 وملخص المناقشة https://github.com/golang/go/issues/24301#issuecomment -371228742. هناك ثلاثة أسئلة مهمة لم تتم الإجابة عليها بعد (يقولون TODO في الملخص) ، والتي سأعمل عليها بعد ذلك. :-)

rsc ، # 24057 بعض المناقشات حول استخدام tar بدلاً من zip.

https://github.com/golang/go/issues/24301#issuecomment -375106068 ، leonklingele :

إذا تم إيقاف دعم go كما نعرفه اليوم وإزالته في النهاية ، فما هي الطريقة الموصى بها لجلب ثنائيات Go وتثبيتها (بدون علامات)؟

سوف يستمر الحصول عليه. إذا لم يتم وضع علامة على الريبو الخاص بالثنائي ، فستستخدم go get آخر التزام. ولكن يجب تشجيع الأشخاص الذين ينشرون الثنائيات على وضع علامات على repos المحتوية مثل repos التي تحتوي على مكتبات (أو مزيج).

إذا تم إهمال $ GOPATH ، فأين سيتم تثبيت هذه الثنائيات؟

لست مضطرًا للعمل في $ GOPATH بعد الآن ، ولكن لا تزال تتم كتابة التعليمات البرمجية في الدليل الأول المدرج في $ GOPATH - إنها ذاكرة التخزين المؤقت المصدر ، راجع $ GOPATH / src / v بعد استخدام vgo. يتم تثبيت الثنائيات على $ GOPATH / bin. اعتبارًا من الإصدارات القليلة الماضية ، لن تضطر إلى تعيين $ GOPATH - فهو يحتوي على الإعداد الافتراضي ، $ HOME / go. لذا ما يجب أن يحدث هو أن يتوقف المطورون عن القلق بشأن تعيين $ GOPATH أو حتى معرفة ماهيته ، ويتعلمون فقط أن ثنائياتهم موجودة في $ HOME / go / bin. يمكنهم استخدام GOBIN $ لتجاوز هذا الموقع.

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

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

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

على الرغم من أن قيود القائمة لا تنطبق على الملفات ، فقد تمكنت مواقع مثل lftp من سرد أدلة http للأعمار (لا يهم إذا كانت غير قياسية إذا كانت تعمل على خوادم http الرئيسية). لذلك من المحتمل أن تكون العملية بدون مؤشر ممكنة ومفضلة للكيانات الصغيرة التي لا ترغب في الاستثمار في البنية التحتية. تعتمد yum / dnf / zipper أيضًا على فهارس مخصصة والحصول على دليل مشترك مفهرس ليس دائمًا بالبساطة التي قد تعتقدها في بعض المؤسسات.

يميل مطورو البرامج مفتوحة المصدر إلى تجنب الاعتماد على البنية التحتية ، لذلك يريدون البيع ، كما كتب joeshaw

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

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

لا يواجه مطورو المؤسسات مشكلة في الاعتماد على البنية التحتية - هذه مجرد تكلفة أخرى

يجب أن يكون العمل في Google أمرًا رائعًا: :(. باستثناء عدد قليل من الشركات التي لديها عملية Go كبيرة حالية حيث يكون الاستثمار في Go infra أمرًا لا يحتاج إلى تفكير ، وسيتعين على أي شخص آخر المرور بعمليات موافقة طويلة ومملة ، إذا كان هذا فقط لتبرير دفع شخص ما للنظر في المشكلة ، لذا فإن أي تكلفة للبنية التحتية ستقلل من الوصول إلى Go وتمنع اعتمادها من خلال الهياكل الجديدة.

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

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

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

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

بالنسبة للكود الذي تم إنشاؤه بشكل عام ، فإن الجواب هو نظام بناء حقيقي متعدد اللغات ،

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

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

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

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

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

https://github.com/golang/go/issues/24301#issuecomment -374791885 ، jimmyfrasche :

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

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

أفهم أن بعض الأشخاص يجادلون بأن vgo يجب أن يتبنى قاعدة Dep بأنه لا يمكن حتى أن يكون هناك 1.x و 2.x معًا ، ولكن من الواضح جدًا أن هذا لا يتناسب مع قواعد الكود الكبيرة التي نستهدفها باستخدام Go. من غير العملي توقع ترقية البرامج الكبيرة بالكامل من واجهة برمجة تطبيقات إلى أخرى دفعة واحدة ، كما يظهر في منشور استيراد vgo . أعتقد بشكل أساسي أن جميع مديري الحزم الآخرين يسمحون بـ 1.x و 2.x معًا لنفس السبب. بالتأكيد Cargo يفعل ذلك.

بشكل عام ، يقلل vgo من الازدواجية مقارنة بالبيع. مع البيع ، من السهل الحصول على 1.2 و 1.3 و 1.4 من حزمة معينة كلها في ثنائي واحد ، دون أن تدرك ذلك ، أو ربما حتى ثلاث نسخ من 1.2. على الأقل تقطع vgo التكرار المحتمل إلى 1.x واحد و 2.x واحد وهكذا.

إنه بالفعل الحال أن مؤلفي الحزم المختلفة بحاجة إلى التأكد من عدم محاولة تسجيل نفس الشيء. على سبيل المثال ، يقوم expvar بعمل http.Handle ("/ debug / vars") وقد قدم بشكل أساسي مطالبة بهذا المسار. آمل أن نتفق جميعًا على أن حزمة الطرف الثالث مثل awesome.io/supervars يجب ألا تحاول تسجيل نفس المسار. هذا يترك تعارضات بين إصدارات متعددة من حزمة واحدة.

إذا قدمنا ​​expvar / v2 ، فسيكون ذلك حزمة ثانية مختلفة ، تمامًا مثل awesome.io/supervars ، وقد يتعارض مع expvar في بنية كبيرة. على عكس المشرفين ، على الرغم من ذلك ، فإن expvar / v2 مملوكة لنفس الشخص أو الفريق مثل expvar ، لذلك يمكن التنسيق بين الحزمتين لمشاركة التسجيل. هذا من شأنه أن يعمل على النحو التالي. لنفترض أن expvar v1.5.0 هو الأخير قبل أن نقرر كتابة v2 ، لذلك يحتوي الإصدار 1.5.0 على http.Handle فيه. نريد أن يكون الإصدار 2 هو البديل للإصدار 1 ، لذلك سننقل http.Handle إلى الإصدار 2.0.0 ونضيف API في الإصدار 2 الذي يسمح لـ v1 بإعادة توجيه استدعاءاته إلى الإصدار 2. ثم سننشئ v1.6.0 الذي يتم تنفيذه مع إعادة التوجيه هذه. الإصدار 1.6.0 لا يستدعي http.Handle ؛ يقوم بتفويض ذلك إلى v2.0.0. الآن يمكن أن يتعايش expvar v1.6.0 و expvar / v2 ، لأننا خططنا له بهذه الطريقة. المشكلة الوحيدة المتبقية هي ماذا يحدث إذا كان البناء يستخدم expvar v1.5.0 مع expvar / v2؟ نحن بحاجة للتأكد من عدم حدوث ذلك. نقوم بذلك عن طريق جعل expvar / v2 يتطلب expvar في الإصدار 1.6.0 (أو أحدث) ، على الرغم من عدم وجود استيراد في هذا الاتجاه ، وبالطبع يتطلب expvar v1.6.0 أيضًا expvar / v2 في الإصدار 2.0.0 أو ما بعده لاستدعاء واجهات برمجة التطبيقات الخاصة به . تتيح لنا دورة المتطلبات هذه التأكد من عدم خلط الإصدار 1.5.0 و v2 أبدًا. التخطيط لهذا النوع من التنسيق عبر الإصدارات الرئيسية هو بالضبط السبب في أن الحد الأدنى من اختيار الإصدار يسمح بالدورات في الرسم البياني للمتطلبات.

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

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

https://github.com/golang/go/issues/24301#issuecomment -374739116، ChrisHines :

أنا قلق للغاية بشأن مسار الهجرة بين عالم ما قبل vgo وعالم vgo الذي يسير بشكل سيء. [تفاصيل اكثر]

أنا سعيد حقًا أن هذا كان التعليق الأول على الاقتراح. من الواضح أنه أهم شيء يجب القيام به بشكل صحيح.

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

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

• github.com/godbus/dbus الإصدار 4.1.0 (مستورد بـ 462 حزمة).
• github.com/coreos/etcd/clientv3 موجود في v3.3.3 (مستورد بواسطة 799 حزمة).
• k8s.io/client-go/kubernetes هو الإصدار 6.0.0 (مستورد بواسطة حزم 1928).

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

خيار آخر للعب خدعة مع وحدات git الفرعية. يفضل الأمر old go get علامة أو فرعًا باسم "go1" على الفرع الافتراضي لـ repo ، لذا فإن المشروع الذي يريد تمكين انتقال سلس يمكن أن ينشئ التزامًا في فرع "go1" الذي يحتوي فقط على دليل فرعي "v2" تم إعداده كوحدة فرعية git تشير إلى جذر الريبو الحقيقي. عندما يقوم "go get" بسحب فرع go1 والوحدات الفرعية المأهولة ، فسيحصل على تخطيط شجرة الملف الصحيح. هذا نوع من الفظاعة ، ومع ذلك ، ستحتاج مؤشرات الوحدة الفرعية إلى التحديث في كل مرة يتم فيها إصدار إصدار جديد.

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

ولكن هذه هي الطرق الوحيدة التي يمكنني التفكير فيها للحفاظ على عدم تعديلها ، فالعمل القديم نبدأ في العمل بينما ننتقل إلى عالم الوحدات النمطية. إذا لم يكن الأمر كذلك ، فإن البديل هو تعديل تطبيق go get القديم ، وهو ما يعني حقًا تعديل بنية go القديمة.

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

التغيير المقترح: قم بتعريف الكود "الجديد" على شكل كود بملف go.mod في نفس الدليل أو في دليل أصلي. يجب أن يستمر الإصدار القديم في تنزيل الكود تمامًا كما كان دائمًا. أقترح أن تقوم خطوة "go build" بضبط معالجتها للواردات في الكود "new". على وجه التحديد ، إذا كان الاستيراد في رمز جديد يشير إلى x / y / v2 / z ولكن x / y / v2 / z غير موجود وكان x / y / go.mod يقول "الوحدة النمطية x / y / v2" ، فسيقوم go build بقراءة الاستيراد كـ x / y / z بدلاً من ذلك. سنقوم بدفع هذا التحديث كإصدار نقطي لـ Go 1.9 و Go 1.10.

التحديث : تم نسخه إلى رقم 25069.

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

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

https://github.com/golang/go/issues/24301#issuecomment -377527249، rsc :

ثم سننشئ v1.6.0 الذي يتم تنفيذه مع إعادة التوجيه هذه. الإصدار 1.6.0 لا يستدعي http.Handle ؛ يقوم بتفويض ذلك إلى v2.0.0. الآن يمكن أن يتعايش expvar v1.6.0 و expvar / v2 ، لأننا خططنا له بهذه الطريقة.

هذا يبدو أسهل مما هو عليه. في الواقع ، في معظم الحالات ، يجب أن يكون هذا المتوسط ​​v1.6.0 عبارة عن إعادة كتابة كاملة لـ v1 في شكل غلاف v2 _ (الاستدعاء المعاد توجيهه إلى http.Handle سينتج عنه تسجيل معالج آخر - واحد من الإصدار 2 - والذي بدوره يعني جميع يجب أن يكون الكود أيضًا من v2 للتفاعل بشكل صحيح مع hander المسجل) _.

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

powerman ، أنا لا أقول على الإطلاق أن هذا تافه. وتحتاج فقط إلى التنسيق إلى الحد الذي تتقاتل فيه v1 و v2 على بعض الموارد المشتركة مثل تسجيل http. لكن المطورين الذين يشاركون في نظام التغليف هذا يحتاجون تمامًا إلى فهم أن الإصدارين 1 و v2 من حزمهم سيحتاجون إلى التعايش في برامج كبيرة. العديد من الحزم لن تحتاج إلى أي عمل - yaml و blackfriday ، على سبيل المثال ، كلاهما يعملان على الإصدار 2 اللذين يختلفان تمامًا عن الإصدار 1 ولكن لا توجد حالة مشتركة للقتال ، لذلك ليست هناك حاجة للتنسيق الواضح - لكن الآخرين سيفعلون ذلك.

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

• لا تملك سوى إصدار v0 / v1 لذا من المستحيل استيراد نسختين أو أكثر

• لديك رمز عام في مجلد إصدار api الخاص به ، على سبيل المثال v1 / v2 بافتراض أن vgo يسمح بذلك أو ربما api1 / api2.

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

في https://github.com/golang/go/issues/24301#issuecomment -377529520 ، يعرّف التغيير المقترح الكود "الجديد" كرمز مع ملف go.mod في نفس الدليل أو دليل رئيسي. هل يشمل ذلك ملفات go.mod "المركبة" التي تم إنشاؤها من القراءة في التبعيات من ملف Gopkg.toml على سبيل المثال؟

zeebo ، نعم. إذا كان لديك ملف go.mod في شجرتك ، فإن الافتراض هو أن التعليمات البرمجية الخاصة بك يتم إنشاؤها بالفعل باستخدام vgo. إذا لم يكن كذلك ، إذن rm go.mod (أو على الأقل لا تضعه في الريبو الخاص بك حيث قد يجده الآخرون).

AlexRouSg ، خطتك لحزمة واجهة المستخدم الرسومية تبدو منطقية بالنسبة لي.

rsc hmm .. لست متأكدًا من فهمي وآسف إذا كنت غير واضح. هل تعتبر الحزمة التي تحتوي على Gopkg.toml فقط في شجرة الملف على أنها "جديدة" بالنسبة للتعريف؟

rsc

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

تمكنا من حل هذا عن طريق تعيين protobuf في GOPATH. نعم ، لدينا ذلك بحيث لا يحتاج المستخدمون العاديون إلى الأدوات للتحديث ، ولكن بالنسبة لأولئك الذين يقومون بتعديل وتجديد protobufs ، فإن الحل في protobuild يعمل بشكل جيد للغاية.

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

هل يُعلن vgo إفلاس أولئك الذين أحبوا GOPATH وتبنوه وعملوا على حل مشاكله؟

zeebo ، لا ، لا يعتبر وجود ملف Gopkg.toml جديدًا ؛ هنا تعني كلمة "جديد" من المتوقع أن تستخدم عمليات استيراد نمط vgo (تعيين إصدارات الاستيراد الدلالي).

stevvooe :

تمكنا من حل هذا عن طريق تعيين protobuf في GOPATH. ...
هل تعلن vgo عن إفلاس من أحبوا GOPATH وتبنوه وعملوا على حل مشاكله؟

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

stevvooe أعطى تعليقات rsc في https://github.com/golang/go/issues/24301#issuecomment -377602765 لقد أشرت عبر https://github.com/golang/protobuf/issues/526 في الحالة تنتهي هذه المشكلة بتغطية الزاوية vgo . إذا انتهى الأمر بالتعامل مع الأمور في مكان آخر ، فأنا متأكد من أن dsnet et al سوف يوقعوننا.

ملحوظة: لم أشاهد التعليقات السابقة عن كثب ، يبدو أن المشكلة تم حلها بنهج مختلف. كانت فكرتي أدناه.

مجرد فكرة.

ماذا عن جعل vgo get على علم بعلامة معينة مثل vgo-v1-lock؟
عندما يحتوي المستودع على العلامة ، فقد يتجاهل علامات الإصدار الأخرى ، ويتم تثبيته بالعلامة.

لذلك ، عندما وضع المستودع علامة v2.1.3 كإصدار أخير ،
ولكن أيضًا يدفع المالك علامة vgo-v1-lock إلى نفس الالتزام الذي تم وضع علامة v2.1.3 عليه
يمكنه كتابة go.mod

require (
    "github.com/owner/repo" vgo-v1-lock
)

يجب ألا يتم تحديثها حتى لو كان vgo get -u ، حتى يغير مالك المستودع العلامة أو يزيلها.
يمكن أن يجعل من السهل على المستودعات الكبيرة تحضير نقلها.

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

كيف نتعامل مع الحالة التي تحتاج فيها إلى تصحيح تبعية عميقة (على سبيل المثال ، لتطبيق إصلاح CVE الذي لم يصدره المؤلف الأصلي بعد في علامة). يبدو أن استراتيجية البائع يمكن أن تتعامل مع هذا لأنه يمكنك تطبيق تصحيح على إصدار المؤلفين الأصليين. لا ترى كيف يمكن لـ vgo التعامل مع هذا.

chirino ، يمكنك استخدام توجيه الاستبدال في ملف go.mod للإشارة إلى الحزمة المصححة.

rsc

بنظرة سريعة ، يبدو أن protobuild يعتمد على افتراض أنه يمكنه إسقاط الملفات (pb.go) في حزم أخرى لا تمتلكها.

هذا ليس ما يفعله المشروع على الإطلاق. يقوم بإنشاء مسار استيراد من GOPATH ودير البائع. سيتم بعد ذلك إنشاء أي ملفات protobuf في مشروعك باستخدام مسار الاستيراد هذا. كما أنه يقوم بأشياء مثل استيراد الخرائط لحزم Go معينة.

وتتمثل فائدة ذلك في أنه يسمح للفرد بتوليد protobufs في مشروع أوراق يعتمد على protobufs الأخرى المحددة في التبعيات دون إعادة إنشاء كل شيء. يصبح GOPATH بشكل فعال مسارات الاستيراد لملفات protobuf.

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

stevvooe أنا آسف ولكن أعتقد أنني ما زلت في حيرة من أمري حول ما يفعله protobuild. هل يمكنك تقديم مشكلة جديدة "x / vgo: غير متوافق مع protobuild" وإعطاء مثال عملي بسيط لشجرة ملفات موجودة اليوم ، ما الذي يضيفه protobuild إلى الشجرة ، ولماذا لا يعمل مع vgo؟ شكرا.

ماذا لو كان يجب تغيير اسم الوحدة (المجال المفقود ، تغيير الملكية ، نزاع العلامة التجارية ، وما إلى ذلك)؟

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

كمستخدم:
ثم كإصلاح مؤقت ، يمكنك تحرير ملف go.mod لاستبدال الوحدة القديمة بوحدة جديدة مع الاحتفاظ بنفس مسارات الاستيراد. https://research.swtch.com/vgo-tour

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

بصفته المسؤول عن صيانة الحزمة:
ما عليك سوى تحديث ملف go.mod لتغيير مسار استيراد الوحدة وإخبار المستخدمين بالتغيير.

jimmyfrasche ،

ماذا لو كان يجب تغيير اسم الوحدة (المجال المفقود ، تغيير الملكية ، نزاع العلامة التجارية ، وما إلى ذلك)؟

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

الجواب على رمز الاختفاء هو أن يكون لديك وكلاء التخزين المؤقت (المرايا)

IMO هو حقا للمؤسسات. ستكون معظم الشركات الصغيرة وغيرها على ما يرام تمامًا مع البيع والتزام جميع التبعيات في نفس الريبو

قدم # 24916 للتوافق الذي ذكرته في التعليق أعلاه.
قدم أيضًا # 24915 مقترحًا العودة إلى استخدام git وما إلى ذلك مباشرةً بدلاً من الإصرار على وصول HTTPS. يبدو من الواضح أن إعدادات استضافة الكود ليست جاهزة لواجهة برمجة التطبيقات فقط حتى الآن.

اقتراح ثانوي لإنشاء تناسق في ملفات التعديل باستخدام الأمر vgo get المخطط له

في مستند "vgo-tour" ، يظهر الأمر vgo get على النحو التالي:

vgo get rsc.io/[email protected]

ماذا عن عكس هذا التنسيق في ملف mod؟ فمثلا:

module "github.com/you/hello"
require (
    "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54
    "rsc.io/quote" v1.5.2
)

يمكن أن يكون ببساطة:

module "github.com/you/hello"
require (
    "golang.org/x/[email protected]"
    "rsc.io/[email protected]"
)

• يحسن التناسق مع سطر الأوامر
• يحدد المعرف الفردي العنصر تمامًا
• بنية أفضل لدعم العمليات المحددة في ملف mod التي تتطلب معرفات حزمة ذات إصدارات متعددة

السعي لمزيد من الوضوح حول كيفية تعامل هذا الاقتراح مع توزيع الحزم "الثنائي فقط".

لا يبدو أن إصدارات / توزيع المكتبة الثنائية يظهر في أي من وثائق الوصف حول vgo. هل هناك حاجة للنظر في هذا بعناية أكبر؟

الطريقة التي تعمل بها اليوم ، إذا كان بإمكاني استخدام أداة عادية git ، فإن go get سيعمل بشكل جيد. لا يهم ما إذا كان مستودع Github خاصًا أم خادم Git الخاص بي. لقد أحببته حقا.

وفقًا لما أفهمه ، سيكون من المستحيل الاستمرار في العمل بهذه الطريقة. هل هذا صحيح؟ إذا كانت الإجابة بنعم ، فهل من الممكن الاحتفاظ بخيار استخدام ثنائي git مثبت محليًا من أجل سحب الرمز؟ (إذا كان يستخدم علامة CLI صريحة)

korya يرجى الاطلاع على المشكلة المقدمة مؤخرًا https://github.com/golang/go/issues/24915

sdwarwick ، re https://github.com/golang/go/issues/24301#issuecomment -382791513 (بناء جملة go.mod) ، راجع # 24119.

إعادة https://github.com/golang/go/issues/24301#issuecomment -382793364 ، من المحتمل أنني لا أفهم ما تقصده ، لكن go get لم يدعم أبدًا الحزم الثنائية فقط ، ونحن لا نخطط لإضافة الدعم. من الصعب جدًا تعداد كل الثنائيات المختلفة المحتملة التي قد يحتاجها المرء. من الأفضل طلب المصدر والقدرة على إعادة التحويل البرمجي عندما تتغير التبعيات أو المترجم.

rsc أعتقد أن https://github.com/golang/go/issues/24301#issuecomment -382793364 يشير إلى
https://golang.org/pkg/go/build/#hdr -Binary_Only_Packages

AlexRouSg نعم. هؤلاء غير مدعومين بواسطة "go get" (لكن "go build" يدعمهم كنوع بناء) ، وهو ما يشير إليه rsc . يجب أن يتم توزيع هذه الأنواع من الحزم خارجيًا إلى أدوات "go get" ، وبالتالي من المحتمل أن يكون الشيء نفسه بالنسبة لهذا الاقتراح الجديد.

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

لقد قمت بتحديث ملخص المناقشة مرة أخرى. لقد قدمت أيضًا # 25069 لاقتراحي سابقًا حول الحد الأدنى من الوعي بالوحدة النمطية في cmd / go القديم.

kybin ، re https://github.com/golang/go/issues/24301#issuecomment -377662150 وعلامة vgo-v1-lock ، أرى الاستئناف ولكن إضافة حالة خاصة لذلك يعني إضافة المزيد من الحالات الخاصة طوال الوقت بقية دعم الوحدة. لا أعتقد أن الفائدة تتناسب مع التكلفة في هذه الحالة. يمكن للناس بالفعل استخدام النسخ الزائفة للحصول على تأثير مماثل. أشعر بالقلق أيضًا من أن العلامة ستتحرك و / أو لن يحترم الأشخاص التوافق مع الإصدارات السابقة (على سبيل المثال ، نقل vgo1-v1-lock من v2.3.4 إلى v3.0.0 فقط لتجنب إصدار الاستيراد الدلالي). لذا بشكل عام ، أعتقد أننا ربما لا ينبغي لنا القيام بذلك.

أعتقد أن الوقت قد حان لإعلان قبول هذا الاقتراح.

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

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

ملخص المناقشة والأسئلة الشائعة محدثان اعتبارًا من الآن. دفعت المناقشة هنا وخارج الموضوع التغييرات المهمة التالية:

• الحد الأدنى من الوعي بالوحدة النمطية في cmd / go القديم ، # 25069.
• استعادة الحد الأدنى من دعم البائع ، # 25073.
• استعادة الدعم للوصول المباشر إلى Git ، # 24915.
• قم بإسقاط علامات الاقتباس في go.mod ، # 24641.
• دعم أفضل لـ gopkg.in، # 24099، others.
• دعم تسمية الالتزامات بمعرفات الفروع ، # 24045.

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

تلاشت المناقشة ، كما أنها أصبحت طويلة بما يكفي لتكون مؤلمة جدًا للتحميل على GitHub (يبدو أن 100 تعليقًا كثيرة جدًا!). من خلال وضع علامة على الاقتراح الذي تم قبوله ، يمكننا التركيز على استخدام vgo وتجهيزه للتضمين في Go 1.11 كـ "معاينة" ، ويمكننا الانتقال إلى المشكلات التي يمكن لـ GitHub تحميلها بسرعة أكبر.

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

شكرا لكم جميعا.

rsc ما هي الطريقة لمحاولة vgo الآن؟ هل يجب علينا جلب وبناء github.com/golang/vgo أو github.com/golang/go؟

ngrilly استمر في استخدام go get -u golang.org/x/vgo .

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

أعتقد أن الوقت قد حان لإعلان قبول هذا الاقتراح.

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

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

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

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

theckman يبدو أن طريقة تفكيرك هي:

1. يتم اتخاذ القرارات بشأن Go بواسطة فريق صغير يتألف بشكل أساسي من مهندسي Google.
2. يتم عزل مهندسي Google عن بقية المجتمع ، لأن احتياجات Google محددة للغاية.
3. يؤدي هذا إلى قرارات تفضل منظور Google ولا يتم تكييفها مع مستخدمي Go الآخرين.
4. هذا يمكن أن يضر ويشتت مجتمع Go.
5. لحل هذه المشكلة ، يجب أن تتبنى Go عملية اتخاذ قرار رسمية حيث يتم اتخاذ القرارات بشكل جماعي من قبل مجموعة تعكس تنوع مجتمع Go (شيء "ديمقراطي").

من الناحية النظرية ، سأميل إلى الإعجاب بأي شيء "ديمقراطي" ، لكن من الناحية العملية:

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

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

theckman ، بينما كان ngrilly يحاول أن يكون مهذبًا ، سأكون ملموسًا: إذا رأيت أي مشكلات فنية لماذا لا يكون اقتراح vgo جاهزًا لقبول - أخبرنا في أسرع وقت ممكن ومن هنا! إذا كنت تعتقد أن بعض المشكلات المعروفة لم تتم معالجتها بشكل كافٍ - فأخبرنا. إذا لم تكن هناك مثل هذه الحالات - ما الفرق من سيقول "حان وقت قبول الاقتراح"؟ كان لدينا شهران لمناقشته ، إذا كنت تعتقد أن هناك سببًا تقنيًا لعدم كفايته - أخبرنا.

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

آسف لتعليق آخر خارج الموضوع ، الجميع!

powerman آسف على أن أعرج واقتبس تعليقي السابق:

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

أعلم أن هناك مقترحات بديلة قادمة ، وكان طلبي هو وضع kibosh على قبول هذا حتى يحين الوقت من اليوم. لم يكن لدينا إدارة التبعية لبعض الوقت الآن ، لذلك أعتقد أنه ليس من غير المعقول طلب إقامة قصيرة مع السماح بلمسات نهائية على المقترحات الأخرى.

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

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

تحرير: للتوضيح ، بإقامة قصيرة لا أقصد شهرين أو أي شيء من هذا القبيل. أعني بضعة أسابيع.

ngrilly آسف ، لم أقصد تجاهل تعليقك. لقد خططت لمخاطبته إلى الإصدار السابق ، لكن انتهى بي الأمر إلى الإسهاب أكثر مما أردت.

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

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

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

للتوضيح ، لم أضع علامة على الاقتراح الذي تم قبوله ، على الرغم مما ذكرته جولانج ويكلي وربما آخرون. قلت فقط أعتقد أن الوقت قد حان للقيام بذلك. أي ، لم أقم بتطبيق ملصق "موافق على الاقتراح" ، بالضبط لأنني أردت التحقق من وجود إجماع عام على القيام بذلك أولاً. ويبدو أن الإجماع العام يؤيد القبول ، على الأقل بناءً على المناقشة العامة هنا بالإضافة إلى عدادات الرموز التعبيرية على https://github.com/golang/go/issues/24301#issuecomment -384349642.

أعلم أن هناك مقترحات بديلة قادمة

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

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

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

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

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

تحرير: الرسالة الأصلية بها حذف مؤسف للغاية كان يجب أن يكون النص record of *not* making decisions on a whim ، وللأسف كان الجزء "ليس" مفقودًا. اعتذاري لذلك.

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

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

(عدل: هذه هي "البدائل" التي كان يشير إليها @ checkman )

sdboyer لقد ذكرت أن لديك مخاوف متعددة. هل يمكنك على الأقل نشر قائمتهم الآن؟
أنا أعمل مع العديد من الأنظمة التي تنقل التبعية إلى مستوى آخر (chef، go، npm، composer) ومن التجربة فإن هذا الاقتراح هو الحل لكل منهم فيما يتعلق بالانطلاق.

theckman ، هل يمكنك تأكيد أنك كنت تشير فقط إلى ملاحظاتsdboyer ؟ هذا ليس سرا. ذكره سام حرفياً في اليوم الأول الذي تم فيه إصدار vgo ("أنا أكتب مستندات أكثر تفصيلاً حول مخاوفي" - https://sdboyer.io/blog/vgo-and-dep/). لكن هذا هو رد الفعل ، وليس اقتراحًا ، وقد أشرت عدة مرات إلى "مقترحات أخرى" ، بصيغة الجمع. هل هناك المزيد الذي تعرفه؟

ما هي الآثار المترتبة على vgo بالنسبة لمستخدمي go / type API؟ ما هو الوضع الحالي لدعم go / Types؟

لقد تلقيت PR mdempsky / gocode # 26 لإضافة go / types. تطبيق المستورد ، لكن ليس من الواضح بالنسبة لي ما إذا كان هذا ضروريًا / لماذا.

بافتراض أن ذلك ضروري ، هل يمكننا إضافة أنواع / go / أنواع متعارف عليها من vgo. مستورد في مكان آخر (على سبيل المثال ، x / vgo أو x / tools repo) بحيث لا تحتاج الأدوات المستندة إلى go / type إلى إعادة تنفيذ هذا الدعم ؟

لم أتبع تفاصيل vgo حقًا ، لذلك ربما يكون هذا ببساطة "ليس له تأثير" ، لكني لا أرى أي ذكر لـ go / type أعلاه. كما أن عمليات البحث في Google عن "vgo go / types golang" غير مفيدة بالمثل.

شكرا.

mdempsky ، تتمثل الخطة في الحصول على أداة تحميل حزم مدركة لـ vgo (ولهذه المسألة قم ببناء ذاكرة التخزين المؤقت) ، على الأرجح golang.org/x/tools/go/packages ، لكنها غير موجودة بعد. يجب على الأشخاص انتظار هذه الحزمة بدلاً من كتابة التعليمات البرمجية التي يجب التخلص منها. لا تدمج العلاقات العامة. لقد علقت على ذلك.

mdempsky كان سيرد في https://github.com/mdempsky/gocode/pull/26 لكنني سأرد هنا الآن.

https://github.com/mdempsky/gocode/pull/26 رمي تمامًا ؛ مجرد إثبات لمفهوم يستخدم CL مهجور الآن مقابل vgo .

لقد رأيت للتو رد rsc ، لذا سأشير ببساطة إلى أن هناك أيضًا مناقشة تجري في https://github.com/golang/go/issues/14120#issuecomment -383994980.

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

باعتباري مستخدم فريق صغير من Go يتمتع بخبرة كبيرة في استخدام NPM ، فأنا أحب اقتراح vgo كثيرًا. FWIW ، أتطلع إلى تطبيق vgo في go المناسب وكلما كان ذلك أفضل لفريقي وأنا.

لا يعني ذلك أنني شخص مميز ، فقط منذ أن رأيت مناقشة حول مشاكل الفريق الصغيرة اعتقدت أنني سأشارك فيها.

هنا تقييمي.

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

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

يقول قسم _Implementation_: "في إصدار لاحق (على سبيل المثال ، Go 1.13) ، سننهي دعم go get of non-modules. سيستمر دعم العمل في GOPATH إلى أجل غير مسمى ". هذا أمر مزعج. أولاً ، هناك الكثير من المشاريع الجيدة التي لم يتم تحديثها منذ سنوات. لا يزالون يعملون بفضل وعد التوافق مع Go 1 ، لكن العديد منهم لن يضيف ملفات go.mod . ثانيًا ، يفرض على مطوري المشاريع بدون تبعيات أو أولئك الذين لا يهتمون بالإصدارات إضافة ملفات الوحدة أو الامتناع عن النظام البيئي الجديد go get . قد يكون لديك ما يبرر رغبتك في ذلك ، ولكن يرجى توضيح السبب. (بالنسبة لي ، يبدو الأمر مرهقًا بلا داعٍ ؛ أفضل استخدام مفترق go get القديم. أوافق على أن مديري الحزم للغات أخرى أكثر تعقيدًا ، وأنا متأكد من أن vgo أفضل منهم ، لكنه لا يتعامل مع حالات الاستخدام الخاصة بي بشكل أفضل من go get الحالي ، مع مساعدة عرضية من الحاكم ).

قلقي الرئيسي بشأن vgo vs go هو سير العمل الذي يدعمونه. لقد عبرت عن ذلك في vgo-intro post. قد ينتمي هذا على نطاق واسع إلى القسم _Compatibility_ من الاقتراح ، أو قد يكون خارج نطاقه ، ولكنه يتوافق مع الأسئلة والقضايا الأخرى التي أثيرت هنا.

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

في حين أن الجوانب الأخرى للاقتراح تبدو جيدة ، إلا أن هذا أمر مؤسف. (لدرجة أنه إذا اضطررت إلى الاختيار بين دمج الإصدار في سلسلة أدوات go والاستمرار في العمل باستخدام أدوات التحكم في الإصدار ، فسأختار الأخير.) تتمثل ميزة vgo في أنها تسهل عمليات الإنشاء القابلة للتكرار وتؤخر تعطل مشروعك بسبب التحديثات غير المتوافقة حتى ترغب في مواجهته بصفتك مؤلف المشروع (مع ملف go.mod) ؛ لكن ميزة go get هي أنه يجلب فوائد monorepo إلى عالم المستودعات المتعددة: نظرًا لاستنساخ كامل من التبعيات ، يمكنك العمل معهم بسهولة كما هو الحال مع مشروعك (فحص السجل ، تحرير ، تغييرات فرق ؛ انتقل إلى تعريف أي شيء وإلقاء اللوم عليه) ، فهو يسهل التعاون (ببساطة تدفع وتقترح تغييراتك) وتفرض عمومًا وجهة النظر القائلة بأنه في أي وقت توجد حالة حالية واحدة فقط في العالم - طرف كل مشروع - وكل شيء آخر هو التاريخ. أعتقد أن هذا النهج الفريد (خارج monorepos الفعلي) هو نعمة مميزة لنظام Go البيئي الذي حقق نتائج جيدة أكثر من السيئة ، ولا ينبغي التخلي عنه.

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

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

للتلخيص ، فإن go get الحالي (مع الأدوات المساعدة ، على سبيل المثال godef ) يدعم سير العمل الذي يتميز:

• كود مصدر قابل للتحرير من التبعيات
• الكود المصدري للتبعيات تحت VCS الخاصة بهم
• أحدث المراجعات من التبعيات

أعتقد أنني أستطيع أن أفترض أن الكود المصدري للتبعيات سيظل قابلاً للتحرير ، أي أن godef سيرتبط بـ _الملفات _ غير المحمية للكتابة _ والمستخدمة أثناء الإنشاء _. ومع ذلك ، فإن vgo سيتراجع عن النقطتين الأخريين. فيما يتعلق بالنقطة الثانية ، أطال # 24915 دعم أدوات VCS ، لكنه لا يزال يعلن عن هدف إسقاطه ؛ ويتطلب سير العمل ليس فقط أن يتم سحب التبعيات من VCS ، ولكن أيضًا أن يكون الخروج مفيدًا للمطورين (على سبيل المثال ، ليس الخروج الضحل ، وليس git checkout مع .git إزالته) ويتم استخدامه أثناء الإنشاء ، ولكن vgo قد لا يفي بهذا المطلب. فيما يتعلق بالنقطة الثالثة ، فقد بررت قيمتها في تعليق vgo-intro ، ولكن يبدو أن vgo قد تخلى عنها تمامًا.

لا يتعين على أداة إصدار Go إسقاط الدعم لسير العمل الحالي ، ويجب ألا تسقطه للحفاظ على المزايا الفريدة للعمل في النظام البيئي Go وتكون بديلاً مناسبًا لـ go get . تصميم vgo يجعل هذا صعبًا ، لكن من الواضح أنه ليس غير قابل للتنفيذ. من ناحية أخرى ، يبدو أن قسم "الاقتراح" من الاقتراح متوافق تقريبًا مع سير العمل الحالي. التحدي الوحيد الذي يقدمه لدعم النقطة الثالثة (التحقق من أحدث مراجعة) - وهي كبيرة - هو أنه يجعل من الصعب تحديد الوحدات ≥v2.0.0 ما إذا كان يمكن سحبها بسعر master ، أو ما إذا كان يجب سحبها كما هو محدد لأن master في إصدار رئيسي آخر. هذا ليس تحديًا لـ go get الحالي مع gopkg.in لأنه يتم سحب كل شيء عند master افتراضيًا ، ويتم سحب العناصر الموجودة في gopkg.in في العلامة أو الفرع المطابق ؛ لكن vgo يطمس هذا التمييز وينشر نموذج gopkg.in على جميع الحزم. (علاوة على ذلك ، فإنه يتوقف عن مطابقة الفروع.) في الواقع يصبح من المستحيل التأكد بشكل مؤكد وضروري لتخمين كيفية الحصول على أحدث مراجعة للإصدار الرئيسي المحدد.

ربما فاتني ذلك ، لكن كيف سيعمل vgo في هذا السيناريو؟

• أنا أعمل على الخدمة A والخدمة B على حد سواء اعتمادًا على lib X (الذي أعمل عليه أيضًا)
• أحتاج إلى تغيير كبير في lib X.

مع الطرق الحالية للقيام بذلك ، أقوم فقط بإجراء تغييراتي ، وتجميع الخدمة A والخدمة B ، فهم يلتقطون كل ما هو موجود في GOPATH $ الخاص بي لـ lib X ، وأقوم بإصلاح الأشياء ، ثم أقوم بدفع lib X مع نتوء كبير ، ثم دفع كلا الخدمتين يطلب منهم A و B استخدام التخصص الجديد لـ lib X في Gopkg.toml .

الآن عندما تتولى vgo المسؤولية ، سيحاول go build على خدماتي العثور على إصدار جديد غير موجود من lib X من github ، ويمكنني توقع كل أنواع المشاكل.

إذن ، هل أفتقد شيئًا واضحًا؟

يمكنك استخدام توجيه الاستبدال لهذا النوع من الأشياء.

في الإثنين ، 30 أبريل 2018 ، 12:15 كتب Antoine [email protected] :

ربما فاتني ذلك ، لكن كيف سيعمل vgo في هذا السيناريو؟

• أنا أعمل على الخدمة A والخدمة B على حد سواء اعتمادًا على lib X (أنا
  تعمل أيضا على)
• أحتاج إلى تغيير كبير في lib X.

باستخدام الطرق الحالية للقيام بذلك ، أقوم فقط بإجراء التغييرات الخاصة بي ، وتجميع الخدمة A و
الخدمة B ، فهم يلتقطون كل ما هو موجود في GOPATH $ الخاص بي لـ lib X ، وأصلح الأشياء ،
ثم أقوم بدفع lib X مع نتوء نصف رئيسي ، ثم أدفع كلا الخدمتين A و B
يطلب منهم استخدام التخصص الجديد لـ lib X في Gopkg.toml.

الآن عندما يتولى vgo المسؤولية ، سيحاول البناء على خدماتي العثور على غير
الإصدار الجديد الحالي من lib X من جيثب ، ويمكنني توقع كل أنواع ملفات
مشاكل.

إذن ، هل أفتقد شيئًا واضحًا؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/24301#issuecomment-385499702 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAuFsfnD8_kbUj8fSXvGgeN77ki6KYM6ks5tt2LLgaJpZM4Sg3bp
.

@ kardianos نعم ، ولكن هذا لا يزال يعني أنه يتعين علي دفع تغييرات lib الخاصة بي من أجل المحاولة؟

تحرير: يبدو أنه يمكنك استخدام المسارات للاستبدال (https://github.com/golang/go/issues/24110) ، وهو أمر جيد. لكن يمكنني أيضًا أن أتوقع أن هذا سينتهي به الأمر في كثير من الأحيان.

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

primalmotion لمنع ارتكاب الأخطاء السيئة ، ربما يجب عليك استخدام خطاف git.

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

primalmotion مع إصدار go.mod.replace بدون إصدار ، يمكنك تنفيذ مشروع لن يكون قابلاً للتكرار. بدلاً من ذلك ، مع استبدال go.mod ، فأنت متأكد من أنك تلتزم بالضبط بما تستخدمه حاليًا وتختبره.
قد يكون من الخطأ الالتزام باستبدال لكنك ستلاحظه وتصححه.
أو يمكن أن يكون تطوعيًا ، فأنا أفعل ذلك باستخدام الوحدات الفرعية ، ولا بأس عندما تعمل في مشروع و lib معًا ويكون قابلاً للتكرار إذا قمت بإلزام الوحدة الفرعية. كنت أفعل ذلك كثيرًا في Python وفقدت ذلك مع Go. مع vgo ، أنا سعيد لأنني أستطيع العمل بهذه الطريقة مرة أخرى. _ (أتمنى أن أكون واضحًا في لغتي الإنجليزية السيئة ، آسف) ._

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

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

ما الذي يمكن أن يجعل vgo يعمل بالنسبة لنا:

• نظام تجاوز كما أشرت
• طريقة لعدم استخدامه على الإطلاق والعودة إلى GOPATH القديم الجيد من أجل التنمية.

ونريده حقًا أن يعمل من أجلنا ، لأنه رائع.

هل يمكن أن يكون لدينا شيء نختبره في go 1.11 (إنه متجمد الآن) أو ربما نذهب 1.12؟
تم تمييزه بالفعل على أنه تجريبي. وأعتقد أنه كلما زاد عدد الأشخاص الذين يختبرونه في تطوير حقيقي ، زادت قيمة التعليقات.

قرأت عن المشكلة المتعلقة بالحزم التي تم إصدارها. لسيناريو واحد بسيط ، إذا كتبت مكتبة تقول استخدام dep للتحليل plist المسمى foo-plist . نتيجة الإعراب ، تكشف مكتبة plist عن أنواع معينة خاصة بها. الآن هذه المكتبة تمت ترقيتها إلى الإصدار 2 ، ويتم إجبار مكتبتي على الترقية إلى الإصدار 2 إذا صادفت إعادة أي كائنات من هذه الأنواع plist.

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

تحت npm ، على سبيل المثال ، يمكن لمكتبتي ببساطة تحديد تبعية الأقران لتقول >=1.0.0|>=2.0.0 والأمر متروك لمستخدم مكتبتي ليقرر إصدار plist الذي يجب استخدامه. لذلك ، إذا كان مستخدم مكتبتي foo-plist يستخدم أيضًا مكتبة أخرى تعتمد على plist ، فإذا كانت كلتا المكتبتين سعيدتين بـ v1 و v2 من plist ، فيمكن للمستخدم اختيار أي منهما يريد في الواقع استيراد. والأهم من ذلك ، إذا قامت كلتا المكتبتين بتصدير أنواع plist ، فستكون هذه الأنواع متوافقة بالفعل.

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

itsnotvalid يمكن لـ foo-plist.2 استيراد foo-plist وإعادة تصدير أنواعه باستخدام الأسماء المستعارة للنوع. يمكن العثور على وصف جيد لهذه التقنية هنا https://github.com/dtolnay/semver-trick

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

أفكار؟

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

rsc هل هناك أي فرصة لتحريك هذا إلى الأمام؟ لا أرى أي شيء كبير يعيق هذا.

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

sdboyer يخطط لنشر كتاباته هذا الأسبوع. أود أن أقول إنه من العدل انتظارهم.

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

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

أتفق مع dlsniper - لقد دخلنا بالفعل في مرحلة التجميد ، وقد مر ما يقرب من ثلاثة أشهر منذ تقديم تصميم vgo. إذا تأخر العمل على 1.11 أكثر ، فأنا قلق من أن يتم دفعه مرة أخرى إلى 1.12.

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

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

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

ومع ذلك ، إذا قلنا إن MVS على ما يرام ، حتى باعتباره فجوة مؤقتة ، فإنه يدخل ويكتسب ميزة القصور الذاتي. في هذه المرحلة ، علينا أن نثبت أنه غير ملائم لـ rsc (على الرغم من أنه في الحقيقة ، لقد حدد ذلك كمعيار بالفعل حتى قبل دمجها) ، وهو يعتقد أن هذا بيان حقيقي حول go get ، الآن:

اليوم ، لا يهتم الكثير من المبرمجين بالإصدار ، ويعمل كل شيء بشكل جيد في الغالب.

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

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

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

أنا شخصياً لا أمانع إذا تأخر الإصدار في Go ، فأنا جميعًا أؤيد القيام بشيء صحيح وليس سريعًا. ولكن في الوقت الحالي على الأقل ، لا يزال vgo يبدو الحل الصحيح بالنسبة لي (ويرى العديد من الأشخاص في المجتمع AIUI هذا على أنه مشكلة ملحة).

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

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

sdboyer ما هو موقفك بشأن ما إذا كان يجب دمج هذا في 1.11 مع الأخذ في الاعتبار أنك لم تذكر رسميًا سوى _ just_ رسميًا ، علنًا ، موقفك من MVS؟

إذا لم يصل هذا إلى 1.11 ، فلن يكون هذا متاحًا رسميًا للمعاينة حتى 1.12 في فبراير 2019 وسيتم إصداره رسميًا حتى 1.13 على الأقل في أغسطس 2019. هذا يضع أول إصدار محتمل بعد 18 شهرًا من بدء rsc في مناقشته. بالطبع لا ينبغي أن نتسرع في هذا دون داع ، ولكن كما ذكر Merovius أعلاه ، فإن العديد من الأشخاص ، بمن فيهم أنا ، يعتبرون الرد الرسمي على إدارة التبعية مسألة "عاجلة". يبدو أن الانتظار لمدة 18 شهرًا مفرطًا.

يبدو بالتأكيد أن dep سيكون الرد الرسمي وقمنا بتحويل مستودعاتنا إليه (وسعدنا بنتائجه). مع هذا الاقتراح الذي يعمل بشكل فعال على إهمال dep للاستخدام على المدى الطويل ، ومع ذلك لا توجد طريقة رسمية لبدء دمج vgo (على الأقل حتى يتم دمج # 25069) ، فقد تركنا في وضع غير مرضٍ حيث نضطر إلى استخدم أداة ( dep ) نعرف أن لها مدة صلاحية محدودة للغاية.

FWIW ، أعتقد تمامًا أنه يجب علينا المضي قدمًا في هذا من خلال دمج vgo كاقتراح في 1.11 وتضمين # 25069 في 1.11 (وكإصدارات التصحيح إلى 1.9 و 1.10 عند إصدار 1.11 ).

أنا بصراحة لا أتذمر الآثار الكاملة لمخاوف MVS و @ sdboyer بشأنها. ومع ذلك ، بالنظر إلى تجربته في هذا المجال ، أعتقد أن هذه المخاوف تستحق دراسة جادة. ومع ذلك ، إذا كان مشتركًا في دمج vgo مع MVS في 1.11 (مع إدراك أن اقتراحه [الذي لا يزال قيد التطوير] ، إذا تم قبوله [مقابل 1.12 ] ، يجب ألا يكسر الوحدات مصمم أصلاً لـ MVS) ، فلا أرى أي سبب لعدم المضي قدمًا.

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

فقط لإضافة 0.02 دولار ، فإن رأيي هو أن MVS هي لحظة "آه ها" لإدارة التبعية. إنني أقدر مقدار التفكير الذي وضعه الناس تجاهه ، لكنني ما زلت مقتنعًا بأن MVS هو المكان الذي يجب أن يذهب إليه هذا.

أتفق بشكل خاص مع النقاط التي أثارها الآخرون: "الإصلاحات الأمنية التلقائية" هي حلم بعيد المنال في أحسن الأحوال وعلبة ضخمة من الديدان في أسوأ الأحوال.

بالإضافة إلى ذلك ، أنا مع joshuarubin : الرد الرسمي على إدارة التبعية يمثل مشكلة ملحة. علق آخرون بأنه يمكننا المضي قدمًا مع MVS الآن ولاحقًا للتغيير إلى حلول أخرى إذا لزم الأمر ؛ إذا كان هذا ممكنًا بالفعل ، أعتقد أن هذه هي أفضل طريقة للذهاب.

أقترح فصل الإصدارات الرئيسية عن مسارات الاستيراد بالطريقة التالية. (أعتقد أنني قمت بحساب السبب في vgo-import وأنني لا أحط من إنجازات vgo المذكورة هناك.) هذا مستوحى من الفكرة من # 25069 أن go build في Go 1.9 و 1.10 يجب أن يتعلم تفسير مسارات الاستيراد بطريقة إبداعية (بإسقاط جزء الإصدار) ؛ في اقتراحي القديم go build لا يتغير ، لكن vgo يتعلم حيلة مماثلة.

من الناحية النحوية ، فإن التغييرات الوحيدة هي:

1. في ملفات .go import "repo/v2/pkg" import "repo/v2/pkg" إذا كان v2 دليلًا ، لكنه يصبح import "repo/pkg" خلاف ذلك. هذا يحافظ على التوافق مع go get الحالي.
2. في ملفات go.mod ، يظل module "repo/v2" كما هو إذا كان في الدليل الفرعي v2 ، لكنه يصبح module "repo" إذا كان في المستوى الأعلى. (هذه هي بادئة الاستيراد الأساسية.)
3. في ملفات go.mod ، يمكنك أيضًا كتابة require repo v2.3.4 as repo2 . ثم في ملفات .go ستستخدم import "repo2/pkg" (أو import "repo2/v2/pkg" إذا كان v2 هو دليل). لن يكون هذا قابلاً للاستيراد بواسطة go get الحالي (إلا إذا كنت تستخدم شيئًا مثل require github.com/owner/project v2.3.4 as gopkg.in/owner/project.v2 ) ، ولكن هذا ضروري فقط عندما تريد استخدام إصدارات رئيسية متعددة في نفس الوحدة ، ولا تكون التبعية كذلك تخزين الإصدارات الرئيسية في الدلائل الفرعية ، والتي لا يمكن دعمها بواسطة go get الحالي على أي حال.

من الناحية الفنية ، يتيح لك ذلك كتابة go.mod باستخدام:

require repo v1.0.0
require repo v1.1.1 as repo1
require repo v2.2.2 as repo2
require repo v2.3.3 as repo3

ولكن تحديد الإصدار الأدنى سيحل هذا الأمر ، بحيث يشير كل من repo و repo1 إلى الريبو بسعر v1.1.1 و repo2 و repo3 بسعر v2.3.3 . لا أعرف ما إذا كان يجب السماح بهذا الاسم المستعار أم حظره.

مزايا:

• سيكون رمز التعرف على الوحدة متوافقًا مع go get الحالي ، حتى الإصدار 2.0.0 السابق ؛ بناء على ذلك:
  
  
  
  • لا داعي لجعل وحدة go get على علم بالحد الأدنى (# 25069)
  
  
  • المشاريع التي تجاوزت الإصدار 2.0.0 لن تضطر إلى كسر التوافق مع الوحدة النمطية غير المدركة go get
  
  
• لن تضطر المشاريع إلى الانتظار حتى تصبح تبعياتها وحدات قبل أن تصبح وحدات نمطية بحد ذاتها [1]
• لا حاجة لإهمال مشاريع الوحدة غير المدركة أو لثني المؤلفين عن بدء مشاريع جديدة غير مدركة للوحدة
• أسهل في الحفاظ على الدعم لسير العمل بدون إصدار لـ go get الحالي (موضح هنا وما فوق )

سلبيات:

• قد يكون من غير الملائم الوفاء بالوعد بأن الملفات المكتوبة بالفعل go.mod ستستمر في العمل (ما لم يتم تسمية ملف الوحدة الجديدة بشكل مختلف عن go.mod )

التناقضات:

• قد يشير مسار الاستيراد نفسه في وحدات نمطية مختلفة إلى إصدارات رئيسية مختلفة
  
  
  
  • جيد: أسهل في الحفاظ على الإصدار 2.0.0 السابق وتغيير الإصدار الرئيسي
  
  
  • سيئ: أنت لا تعرف أي إصدار رئيسي تستخدمه دون النظر إلى go.mod
  
  
• قد تحدد الوحدات النمطية بادئات استيراد عشوائية لاستخدامها في التعليمات البرمجية الخاصة بها
  
  
  
  • سيختار بعض المستخدمين استيراد كل شيء باسم قصير (على سبيل المثال ، import "yaml" مع require gopkg.in/yaml.v2 v2.2.1 as yaml )
  
  

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

لقد أجريت تحليلًا لملفات Gopkg.toml التي تمكنت من العثور عليها من الحزم في https://github.com/rsc/corpus وكتبت ملخصًا على https://github.com/zeebo/dep-analysis. استنادًا إلى البيانات الموجودة هناك ، يبدو أنه لا يوجد الكثير من الأدلة على أن vgo لن يكون قادرًا على التعامل مع كل حالة استخدام تم تحديدها تقريبًا.

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

إذا اقتبست منك:

ما يقرب من نصف جميع القيود ليست في الواقع قيودًا على الإطلاق: فهي تشير إلى الفرع الرئيسي.

ربما يكون هذا بسبب وجود العلامة الرئيسية فقط بدون علامات أو "الفروع المسماة مثل v2 ، v3" إذا كان هذا هو الحال ، فإن المقارنة ليست عادلة لأنه ليس لديك خيار!

mvrhov لست متأكدًا مما تقصده بعبارة "ليس عدلاً". يبدو لي أن vgo و dep سيتعاملان مع هذه القضية على ما يرام. أو بالأحرى ، أي بديل واقعي يجب أن يتعامل مع هذه القضية على ما يرام. على وجه الخصوص: إذا لم يكن هناك إصدار تم إصداره حتى الآن ، في عالم vgo يمكن فقط وضع علامة v1.0 / v0.x عليها ولن يكون من الضروري إجراء أي تغيير على أي من مسارات الاستيراد (الخصوصية الرئيسية لـ vgo).

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

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

كان هناك اعتراضان على هذا الاقتراح نشعر أنه ينبغي التحدث إليهما:

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

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

نحن نقدر جميع التعليقات والشغف الذي قدمته بشأن هذه المشكلة الحرجة. تم قبول الاقتراح.

- لجنة مراجعة Go Proposal

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

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

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

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

peterbourgon باعتباري شخصًا شارك في استطلاع Go Dependency Management وعمل على Glide حيث استمعت إلى احتياجات الأشخاص وحاولت القيام بهذا العمل ، يمكنني إظهار المشكلات العملية (بدلاً من الآراء فقط). وهذا يعني أنه يمكنني مطابقة الرغبات والاحتياجات والتوقعات من المستخدمين مع حلول تلك المشكلات. ما يقلقني هو عدم التطابق في ذلك بالنسبة للمسار الحالي لـ vgo. هناك احتياجات غير ملباة ومشكلات عملية بسبب الاختلافات في كيفية إدارة الأشخاص للتبعية.

طريقة سهلة لبدء التخفيف من مخاوفي هي جعل vgo يعمل لصالح Kubernetes بما يرضي تيم هوكينز.

طريقة سهلة لبدء التخفيف من مخاوفي هي جعل vgo يعمل لصالح Kubernetes بما يرضي تيم هوكينز.

اجعل vgo يعمل مع Kubernetes اليوم أو اجعل vgo يعمل لصالح Kubernetes خلال السنوات القادمة؟ كما أفهمها ، فإن أحد الاختلافات الأساسية في التصميم بين vgo و dep هو ما إذا كنا بحاجة إلى العمل مع النظام البيئي كما هو موجود اليوم (افتراض الإدارة) أو ما إذا كان بإمكاننا تحويل المجتمع نحو القيام بإصدارات ذات علامات والحفاظ على التوافق (افتراض vgo) .

لذلك من المحتمل ألا يعمل vgo مع العديد من التبعية باستخدام Kubernetes لبعض الوقت ، حتى تتغير معايير مجتمع Go.

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

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

bradfitz SemVer يستخدمه Go pacakges اليوم بشكل عام بلغات PHP و node.js و Rust والعديد من اللغات الأخرى. إنه شيء شائع جدًا. لقد واجهت مشكلات عبر هذه اللغات والمزيد حيث تعطلت الحزم من مشكلات توافق SemVer. أحيانًا عن قصد وأحيانًا عن طريق الصدفة. ما الذي سيفعله Go بشكل مختلف لتجنب مشكلة موجودة في كل هذه اللغات الأخرى لأن الناس غير معصومين من الخطأ؟

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

أعتقد أن الجميع سيوافقون الرأي: الوضع الحالي مع إدارة التبعية مروع ، في أي لغة / منصة. أعتقد أن bradfitz شرح بشكل صحيح نقطة الصراع الرئيسية. ربما لن تنجح vgo ، لكن بالنسبة لي من الواضح أنه يتعين علينا تغيير شيء ما (أعني ليس فقط في Go ، ولكن بشكل عام) ، ويبدو أن vgo واعد جدًا لتجربته.

mattfarina نخطط لمحاولة تنفيذ خدمة تتحكم تلقائيًا في التوافق الذي يتم الحفاظ عليه بالفعل. بدمجها مع godoc.org ، وتوفير شارات لـ README ، واستخدامها كبديل لـ go get - هناك العديد من الطرق التي يمكننا من خلالها محاولة جعلها تعمل بشكل جيد بما فيه الكفاية. بالتأكيد ، sdboyer محق في أن توافق واجهة برمجة التطبيقات لا يضمن التوافق الفعلي ، ولكن هذه بداية جيدة ويجب أن تعمل بشكل جيد بما فيه الكفاية في معظم الحالات.

لذلك من المحتمل ألا يعمل vgo مع العديد من التبعية باستخدام Kubernetes لبعض الوقت ، حتى تتغير معايير مجتمع Go.

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

ما الذي سيفعله Go بشكل مختلف لتجنب مشكلة موجودة في كل هذه اللغات الأخرى لأن الناس غير معصومين من الخطأ؟

لقد كنا نناقش نوعًا من الأمر go release الذي يجعل الإصدارات / العلامات سهلة ، ولكن أيضًا يتحقق من توافق واجهة برمجة التطبيقات (مثل مدقق Go-internal go tool api الذي كتبته لإصدارات Go). قد يكون أيضًا قادرًا على الاستعلام عن godoc.org والعثور على المتصلين بالحزمة الخاصة بك وإجراء اختباراتهم مقابل الإصدار الجديد أيضًا في وقت ما قبل الإصدار ، قبل دفع أي علامة. إلخ.

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

هذا ليس عمليًا حقًا لأي شخص ليس Google.

هذا ليس عمليًا حقًا لأي شخص ليس Google.

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

ليس هناك الكثير من الصلصة السرية لـ Google عندما يتعلق الأمر بإجراء الاختبارات.

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

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

/اثنين سنتا

SamWhited MeteorJS كان هذا يعمل مع galaxy ، وهو أمر مدمج في meteor publish لتشغيل مشروعك في مزود السحابة. ربما أسيء فهم المشكلة المطروحة ، لكن تأرجحهم فيها بدا جيدًا.

bradfitz ماذا لو لم تتغير واجهة برمجة التطبيقات ولكن السلوك الذي يقف وراءها يتغير؟ هذه حالة تخرج عن SemVer وتؤثر على أولئك الذين يستوردونها. كيف تكتشف هذا الموقف؟ أسأل لأنني اختبرت ذلك في أكثر من مناسبة.

أداة مفتوحة المصدر يمكن لأي شخص تشغيلها ودفع 0.57 دولار أو 1.34 دولار التي يحتاجون إليها لإجراء اختبارات bazillion على مجموعة من المضيفين لبضع دقائق.

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

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

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

لنأخذ Kubernetes كمثال على ذلك. يكتب شخص ما حزمة تم استيرادها إلى Kubernetes. لذلك يجب أن تحصل الأداة على ذلك وتقوم بإجراء جميع الاختبارات. تم تصميم أجزاء منه للتشغيل على Windows و POSIX. هل يمكننا اختبار نظام التشغيل المتعدد / متعدد الأقواس (حيث أن Go يتعامل مع ذلك). كيف سيبدو ذلك حقًا (والتكلفة)؟

-

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

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

للاقتباس منtechnosophos في وقت سابق اليوم:

"مديرو الإصدارات ليسوا في الواقع أدوات للمترجمين أو الروابط أو أي شيء ... مديرو الإصدارات مخصصون للأشخاص المتعاونين."

لما يستحقه ، فقد كتب أكثر من مدير تبعية ، ودرس الآخرين ، وتحدث مع أشخاص كتبوا أكثر.

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

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

هناك مشاكل منطقية وعملية تم التعبير عنها حول هذا الاقتراح. يجب علينا تغيير الاقتراح لمواجهتها وليس مجرد قول: "العمل على النحو المنشود". إذا لم نتمكن من القيام بذلك بشكل صحيح بالنسبة لـ 1.11 أو 1.12 أو 1.13 ، فعلينا الانتظار حتى يمكن القيام بذلك بشكل صحيح. يقترح هذا الاقتراح نظامًا يتصرف بشكل مختلف تمامًا عن معظم الأنظمة الأخرى وليس بطريقة جيدة.

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

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

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

mattfarina ، SamWhited ، دعنا ننتقل المناقشة إلى https://github.com/golang/go/issues/25483.

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

لقد واجهت مشكلات عبر هذه اللغات والمزيد حيث تعطلت الحزم من مشكلات توافق SemVer. أحيانًا عن قصد وأحيانًا عن طريق الصدفة. ما الذي سيفعله Go بشكل مختلف لتجنب مشكلة موجودة في كل هذه اللغات الأخرى لأن الناس غير معصومين من الخطأ؟

لا يزال من غير الواضح بالنسبة لي لماذا يُفترض أن أداء vgo أسوأ في هذه الحالات من dep. على العكس من ذلك ، يبدو لي أن أداء vgo أفضل بشكل صارم . ذكرت في مدونتك مشكلة معينة في helm ، كدليل على فشل نموذج vgo. ومع ذلك ، في عالم vgo ، هناك سيناريوهان لسبب اختيار vgo لاستخدام الإصدار 1.4.0 لـ grpc:

1. اختار مطورو helm تحديد grpc >= v1.4.0 في go.mod كمتطلب. في هذه الحالة ، يمكنهم ببساطة التراجع عن هذا المطلب وبالتالي الرجوع إلى الإصدار السابق من grpc الذي يناسبهم.
2. اختار مطورو تبعية الدفة تحديد grpc >= v1.4.0 . في هذه الحالة ، كان من الممكن أن يقوم dep بتثبيت ذلك أيضًا ، وإذا حاول helm التراجع عن طريق تقييد grpc < v1.4.0 dep ، فسيتعين عليه التعطيل بسبب المتطلبات المتعارضة.

لذلك يبدو لي أن vgo يحل هذه المشكلة على الأقل كما يفعل القسم. وفي الوقت نفسه ، في عالم الرعب ، هناك خيار آخر:

1. تتطلب التبعيات متعدية لـ helm grpc >= v1.x.0 ، مع بعض x < 4 ، ثم grpc تم إصدار v1.4.0 وقرر dep استخدام الإصدار الأحدث عند التثبيت ، دون أن يُطلب منه ذلك . في هذه الحالة ، قد يتم كسر الدفة وتحتاج إلى التجمهر لإجراء إصدار إصلاح الخلل (كما هو موضح من خلال المنشور الخاص بك) ، مما يؤدي إلى الكد. في هذه الأثناء ، كان vgo سيتجاهل الإصدار الجديد وستستمر الأمور في العمل بشكل جيد.

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

للتوضيح ، هذا ليس عن dep . إنه تحليل لكيفية تصرف MVS (vgo) بالمقارنة مع حلول إدارة الحزم الأخرى القائمة على SAT-solver (تشمل القسم).

مثال آخر لمات ينص على ما يلي:

أنت مطور الوحدة النمطية app ولديك تبعيتان:

• grpc [> = 1.8 ]
• helm ، والتي لها التبعية التالية:
  
  
  
  • grpc [> = 1.0 ، <1.4] (لأن grpc أدخل تغييرًا فاصلاً في 1.4).
  
  

لن يعرف معظم الناس متطلبات التبعية متعدية ( helm -> grpc [> = 1.0 ، <1.4]) لأن ذلك سيتطلب إدراك أن helm فواصل عندما باستخدام grpc > = 1.4. أفترض أن هذا ليس شيئًا سيهتم به غالبية الناس أو يقضون الوقت والطاقة في التحقيق فيه.

إذا كنت تستخدم vgo (تعتمد بشكل خاص على MVS) ، فستحصل على:

• helm
• grpc [> = 1.8 ]

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

هذه نقطة مهمة لانتقاد MVS و vgo. لا تريد السماح للتبعيات بالحالة عندما تكون لديهم مشكلة في إصدار معين لتجنب الحاجة إلى حل SAT كامل . يمكنك الرجوع إلى الأقسام Theory و Excluding Modules في مقالة MVS لمزيد من التوضيح.

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

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

ما لم يبدأ الأشخاص بطريقة سحرية في التوافق مع SemVer ، أتخيل تثبيت تبعية عند استخدام vgo للتحول إلى تمرين غريب الأطوار حيث يتعين عليك بعد استيراد وحدة نمطية التحقق من ملف README لنسخ قائمة الإصدارات غير المتوافقة لتضمينها منهم في ملف go.mod . ضع في اعتبارك أن بيان exclude يأخذ إصدارًا واحدًا فقط حاليًا.

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

في منشور مدونة mattfarina ، يصفون ترقية Helm إلى grpc v1.4.0 عن قصد ، أي بما يعادل تحديث go.mod . السؤال ليس كيف يتجنب dep أو vgo هذه المشكلة ، بل كيف يمكن لمؤلف المكتبة التعافي منها. في حالة dep ، يمكنهم إصدار رقعة تُعلن عن قيد grpc<v1.4.0 . بالنسبة للمستخدمين الذين ليس لديهم اعتماد آخر على grpc ، فإن هذا سيعمل فقط. إذا كان المستخدم قد قام بالفعل بالتحديث إلى أحدث إصدار من الدفة ولديه تبعية أخرى على grpc>=v1.4.0 ، فإن هذا القيد سيؤدي إلى فشل بنائه ؛ ليس مثاليًا ، ولكنه أفضل من سلوك وقت التشغيل المكسور بمهارة.

مع vgo ، هل يتوفر لدى مشرفو Helm أي خيارات مكافئة متاحة؟ إذا قام المستخدم بترقية grpc إلى الإصدار 1.4.0 لأي سبب من الأسباب ، فسيختار MVS دائمًا [email protected] ، وسيتم كسر Helm ، ولا يوجد شيء يمكن لمشرفي Helm القيام به حيال ذلك (بدون تعديل السلوك المتغير ، وهو غالبًا استهلاك الوقت). لا يمكنني التحدث باسم mattfarina ، ولكن هكذا قرأت القلق الذي أثير وهو الأمر الذي أشاركه. باستخدام dep والأنظمة المماثلة ، يمكن للمكتبات المتوسطة الدفاع ضد (أو في كثير من الأحيان ، التعافي من) انتهاكات التوافق مع قيود الحدود العليا.

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

يبدو أن أحد أمثلة روس في حديث GopherconSG يغطي سيناريو مشابه جدًا (ربما متطابق؟).

في المنشور أعلاه ، تقول إن الدفة تعتمد على "grpc [> = 1.0 ، <1.4]". لكن هذا ليس دقيقًا تمامًا. أعتقد أن ما تقصده هو أن إصدارًا معينًا من الدفة يعتمد على "grpc [> = 1.0 ، <1.4]". لنفترض أن إصدار helm هو 2.1.3 ؛ يُفترض أن هذا الإصدار من helm قد تم إطلاقه بعد grpc 1.4 (وإلا لما عرفت أنه لا يتوافق مع grpc 1.4). نقطة روس في هذا الحديث هي أن الإصدار السابق من helm (لنقل 2.1.2) ، من المفترض أنه لم يكن (حتى الآن) قد حدد نفسه على أنه غير متوافق مع grpc 1.4.

بعبارة أخرى ، فإن المهمة المرضية (وفقًا للديب) ستكون helm = 2.1.2 ، grpc = 1.8. يمكن لـ Dep اختيار تعيين الإصدار هذا بشكل صحيح دون أخطاء ، لأنه يفي بجميع القيود في الإصدارات المعينة.

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

نسخة هيلم لا تغير المثال بشكل جذري. قد يعلن [email protected] عن الاعتماد على [email protected] وقد يعتمد مستخدم helm على [email protected] مباشرةً أو من خلال حزمة أخرى. في هذا السيناريو ، يفشل MVS ويقوم بتثبيت [email protected] و [email protected]. بالإضافة إلى ذلك ، يفترض هذا المثال أن المستخدم يقوم عن قصد بالتحديث إلى [email protected] (وبالتالي [email protected]) وربما حتى [email protected] و [email protected] وما إلى ذلك قبل اكتشاف المشكلة.

لا تسمح MVS عمدًا بالاستثناءات من التبعيات الوسيطة لتحقيق أهدافها النظرية:

الآثار السلبية (X → ¬ Y ، بشكل مكافئ ¬ X ∨ ¬ Y: إذا تم تثبيت X ، فلا يجب تثبيت Y) ...

في هذا المثال ، نحتاج إلى التعبير ، إذا تم تثبيت X = helm>= 2.1.3 ، فلا بد من عدم تثبيت Y = grpc>=1.4.0 ، وهو ما لا يمكننا القيام به حسب التصميم.

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

ربما سيشجع هذا السلوك الأفضل في المكتبات ذات الاستخدامات الكثيفة مثل grpc و aws-sdk-go لأن العبء الكامل لأي كسر ستشعر به جميع الأطراف وسيكون حله أكثر صعوبة. ومع ذلك ، فالأمر ليس بهذه السهولة دائمًا. ماذا لو لم يكن "الكسر" كسرًا حقًا ، ولكنه تغيير شرعي في السلوك له عواقب غير مقصودة على بعض المستخدمين ، ولكنه مفيد للآخرين؟ هذا النوع من الأشياء ليس نادرًا وسيتردد مؤلفو المنبع بحق في التراجع عن تغيير في هذا السيناريو.

لا أعتقد أنني كنت واضحًا مثل روس. دعني احاول مجددا.

في البداية ، تبدو حالة الأقسام هكذا.
Helm 2.1.2: grpc> = 1.0

ثم يتم تحرير grpc 1.4. يدرك مطورو Helm أن هناك عدم توافق ، ولذا دفعوا بإصدار جديد من Helm:
Helm 2.1.3: grpc> = 1.0، <1.4

أبدأ تطبيقًا جديدًا يعتمد على Helm وبعض الميزات الجديدة لـ grpc (من أجل الجدل). أسرد الأقسام التالية:
Helm> = 2.0.0
grpc> = 1.4

الادعاء أعلاه هو أن القسم سيلاحظ التضارب المتأصل ، ويبلغ عن خطأ.

لكن روس أشار إلى أن هذا ليس صحيحًا ، لأن هناك مهمة إصدار بدون تعارضات. على وجه التحديد ، يمكن أن تختار الإدارة استخدام helm 2.1.2 و grpc 1.4. وفقًا للقسم ، يعد هذا تعيينًا صالحًا ، لأن helm 2.1. 3 هو الذي لا يتوافق مع grpc 1.4 بينما 2.1. 2 متوافق مع جميع grpc> = 1.0.

بعبارة أخرى ، يمكن أن يختار dep _validly_ "إصلاح" تعارض ، عن طريق الرجوع إلى إصدار لم يسجل التعارض بعد. إذا كان لديك إصدارات غير قابلة للتغيير ، فهذا يبدو لا مفر منه. لذلك ، يبدو أن الإدارة ستسيء أيضًا التعامل مع https://codeengineered.com/blog/2018/golang-vgo-broken-dep-tree/.

balasanjay بالتأكيد ، لكن في النهاية ، طرح Helm 2.2.0 بميزة جديدة أنيقة تريدها ، وتحاول الترقية ، ثم تبدأ المشكلة.

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

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

و FWIW ، أعتقد أنه من المعقول التشكيك في فعالية الضمانة إذا كانت تنتهك مثالًا بسيطًا نسبيًا للنزاع.

للسجل ، تتبعت مثال روس (إنه مطابق إلى حد كبير لهذا المثال ، إلى حد كبير): https://youtu.be/F8nrpe0XWRg؟t=31m28s

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

تخيل مكتبة مشهورة في وضع maitenence ، على سبيل المثال v1.2.3 تم إيقافه منذ أكثر من عام دون أي تغييرات. تعتمد عليه العديد من المكتبات الأخرى.
يأتي المطور ويدرك تحسين السرعة في الإصدار 1.2.3. يعمل على تسريع الوظيفة الأساسية للمكتبة بمقدار 10x ، دون تغيير واجهة برمجة التطبيقات! تم إصدار هذا كـ v1.3.0. لم يتم العثور على المزيد من الأخطاء في هذه الحزمة للعام التالي.

كيف المعالين في نهاية المطاف الحصول على هذا التحديث؟ يمكنهم العمل مع v1.2.3 ، ولكن من الواضح أن v1.3.0 أفضل.

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

كيف المعالين في نهاية المطاف الحصول على هذا التحديث؟

سيحتاج كل تطبيق إلى تعيين 1.3.0 كحد أدنى للإصدار المطلوب استخدامه.

حسنًا ، يا له من يوم سخيف اليوم! 😄

كان هذا الاقتراح مفتوحًا مع مناقشات نشطة لأكثر من شهرين

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

كان هناك اعتراضان على هذا الاقتراح نشعر أنه ينبغي التحدث إليهما:

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

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

حرفيا لا أحد يعتقد أنه يمكن تغطية جميع السيناريوهات الممكنة. تكمن المشكلة ، ولا تزال دائمًا ، في أن MVS لا يحل سوى مشكلة "الوهمية" (تجنب SAT) ، ويخلق مشاكل جديدة بدلاً منها والتي تكون أكثر أهمية في الممارسة العملية ، ولا يمكن أن تعمل بشكل فعال كطبقة وسيطة يمكننا العمل عليها بشكل معقول.

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

لا شيء يساعد في التقليل من أهمية درجة التغييرات المقترحة هنا من خلال مقارنتها بتشغيل gofmt - ربما يكون النشاط الوحيد الأكثر طائشًا الذي نقوم به كمطورين Go.

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

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

@ ميروفيوس :

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

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

تكمن المشكلة ، وكانت دائمًا ، في أن MVS لا يحل سوى مشكلة وهمية (تجنب SAT) ، ...

مع الاحترام ، IMHO حل SAT ليس حلاً ، لذلك بالنسبة لي ، MVS يحل مشكلة حقيقية للغاية.

IMHO حل SAT ليس حلاً ، لذلك بالنسبة لي ، MVS يحل مشكلة حقيقية للغاية.

هل تحب أن تفهم السبب وراء ذلك ، إن أمكن؟

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

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

أفهم أنه لا ينبغي لنا اختيار الحل الأول الذي سيتم تنفيذه. لكن الوقت هو أحد العوامل. لم يتم تحديد الاقتراح المضاد الخاص بـ vgo بشكل جيد ، ومن المحتمل جدًا أن يستغرق سنوات حتى يتحقق. سأختار vgo في Go 1.11 بدلاً من حل رائع يعتمد على SAT في Go 1.14 في أي يوم.

هذا أيضًا بافتراض أن أدوات vgo ثابتة. لكل ما نعرفه ، يمكن أن يتغير vgo بشكل كبير خلال النوافذ 1.12 و 1.13.

هل تحب أن تفهم السبب وراء ذلك ، إن أمكن؟

إنه نفس السبب وراء تفضيل التعبير العادي لـ Go على PCRE ، أي. عدم السماح لبرنامج ما بالاعتماد على خوارزمية ذات تعقيد تربيعي / أسي أسوأ حالة.

يجب أن نضع في اعتبارنا أن vgo سيحل محل go get ولا شيء آخر. يجب أن نقارن بين vgo بـ go get وليس vgo بشيء غير موجود. "الأسوأ هو الأفضل"! دعونا نركز الآن على تفاصيل التنفيذ.

FWIW ، من الممكن تمامًا IMO تقديم الحدود العليا دون وجود محلل SAT كامل - ليس من الممكن أن يكون الحل الذي تم إنشاؤه هو الحل الأمثل أو ضمان العثور على حل موجود. إذا لزم الأمر ، يمكنك ذلك

1. اجعل من الممكن تحديد الحدود العليا
2. تجاهلها عند الحل عبر MVS
3. تحقق من الحل الذي تم العثور عليه مقابل جميع الحدود وقم بتشويش إذا لم يكن مناسبًا (هذا هو الاختلاف الرئيسي: ستحاول الأساليب التقليدية إيجاد حل مختلف بدلاً من ذلك)

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

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

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

إنه نفس السبب وراء تفضيل التعبير العادي لـ Go على PCRE ، أي. عدم السماح لبرنامج ما بالاعتماد على خوارزمية ذات تعقيد تربيعي / أسي أسوأ حالة.

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

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

كنت أتساءل عما إذا كان لدى الناس أسباب أخرى لتفضيلها على خوارزمية تعتمد على SAT.

كنت أتساءل عما إذا كان لدى الناس أسباب أخرى لتفضيلها على خوارزمية تعتمد على SAT.

ibrasho MVS لا تحتاج إلى ملف قفل.

كنت أتساءل عما إذا كان لدى الناس أسباب أخرى لتفضيلها على خوارزمية تعتمد على SAT.

أنا شخصياً أسبابي

1. يقوم بتوحيد ملف القفل والبيان في ملف واحد ، والذي يمكن تحريره بواسطة الكمبيوتر إلى حد كبير. يعني تقليل الضوضاء أثناء الحصول على قابلية التكرار (أو "الدقة العالية") في الحالة الشائعة. AFAICT هذا شيء فريد لـ MVS. نظرًا لأن أحد إحباطاتي الرئيسية مع مديري الحزم الآخرين هي صعوبة الاضطرار إلى تعديل ملفات البيان ، فهذا أمر ضخم بالنسبة لي.
2. سيكون الإصلاح التدريجي أسهل / ممكنًا. نظرًا لأنني من أشد المؤمنين بهذا النهج لحل مشكلة التنمية الموزعة ، فإن هذا مهم أيضًا بالنسبة لي.
3. قد يساعد النظام البيئي على البقاء بشكل جماعي بالقرب من HEAD لمعظم المكتبات. هذا هو التخمين إلى حد كبير ويعتمد إلى حد ما على الأدوات المتاحة. ولكن إذا كان "سحب كل شيء إلى أحدث إصدار" بسيطًا بدرجة كافية ، فيمكنه زيادة إيقاع اختبار الإصدارات الأحدث من المكتبات ضد بعضها البعض في الإنتاج.
4. يحقق كل هذا مع الحفاظ على الصفات المرغوبة للنهج الأخرى ، AFAICT أو تجاوزها. ترقيات تحدث فقط إذا رغبت في ذلك. وسيستمر إنشاء الحزم الثنائية حتى إذا تم كسر بناء بعض تبعياتها في إصدار جديد ، مما يمنح المؤلف الوقت للعمل على الإصلاح.

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

تضمين التغريدة
"يوحد ملف القفل ويظهر في ملف واحد"

• هذا ليس صحيحًا تمامًا حيث تنتشر البيانات بشكل فعال في جميع ملفاتك. تعمل بيانات الاستيراد بشكل فعال كقوائم.

docmerlin عندما قلت "manifest" ، كنت أعني ملفًا يسرد جميع الوحدات التي تعتمد عليها مع إصداراتها المناسبة (على وجه الخصوص ، يحتوي على معلومات أكثر دقة من بيانات الاستيراد ، وإلا فلن تحتاجها). في حالة vgo الذي سيكون go.mod ، في حالة dep يكون Gopkg.toml . يمكنك أيضًا استدعاء ملف التكوين الخاص بحل التبعية. إذا كنت تعتبر مصطلحًا مختلفًا أكثر ملاءمة ، فلا تتردد في استبداله بمصطلح بيان ، عندما تقرأ تعليقي.

لاحظ أنه من الطبيعي جدًا أن يكون هناك ملف يسرد جميع التبعيات وقائمة بالواردات الصريحة (التي من المحتمل أن تكون مجموعة فرعية صارمة من التبعيات) لكل ملف. على وجه الخصوص ، كل مدراء التبعية Go الذين أعرفهم يفعلون ذلك. تستخدم الطرق الأخرى أيضًا ملف قفل يصف إصدارات محددة ودقيقة لاستخدامها لضمان إنشاءات قابلة للتكرار. والميزة المميزة لـ MVS التي كنت أشير إليها ، هي أن هذا الملف ليس ضروريًا ، لأنه يمكن اشتقاقه بشكل فريد من ملف manifest / التبعية-solver-config / go.mod.

(تم حذفه + إعادة نشره من حسابي الشخصي)

cznic ، التركيز على فئات التعقيد في MVC مقابل النهج القائم على SAT في عزلة لا معنى له (كما أعتقد أن sdboyer يكتب في مكان ما - ننشغل بالحديث عنه لأنه أحد الأشياء القليلة التي يمكننا القيام بها الاسم / التعريف).

يتضمن اقتراح bradfitz في # 25483 لمعالجة بعض المخاوف مع vgo (والذي أعتقد أنه حل مجنون في البداية ولكن ربما يكون حلًا عمليًا رائعًا) إجراء الاختبارات من المستخدمين التعسفيين لواجهة برمجة التطبيقات الخاصة بك قبل الإصدار. هذه مشكلة NP كاملة بشكل عام ، ولكن من الناحية العملية قد تكون حلاً رائعًا (تمامًا مثل GPS2).

لذلك من ناحية ، لدينا خوارزميات إدارة الحزم المستندة إلى SAT ، ومن ناحية أخرى لدينا خوارزمية في NL تجبرنا على القيام بعمل NP الكامل لاحقًا (أو المهلة ، وهو ما سيفعله أي محلل عملي لـ SAT لملفات قفل الخصومة).

التركيز على فئات التعقيد لـ MVC مقابل النهج القائم على SAT بمعزل عن غير منطقي ...

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

... اقتراح في # 25483 لمعالجة بعض المخاوف مع vgo ...

يبدو أن المشكلة رقم 25483 لا تتعلق بـ vgo. خطأ مطبعي؟

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

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

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

يبدو أن المشكلة رقم 25483 لا تتعلق بـ vgo

السطر الأول في هذا العدد هو رابط لتعليق براد في هذا العدد: https://github.com/golang/go/issues/24301#issuecomment -390788506. في حين أن هذه الأداة ستكون مفيدة خارج vgo ، يبدو أنه يتم النظر فيها إلى حد كبير للتخفيف من بعض الجوانب السلبية لـ MVS (في رأيي / فهمي).

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

قبل عامين ، كان هناك عدد من حلول إدارة التبعية المختلفة (على سبيل المثال ، godep ، glide ، إلخ). لاكتشاف مسار للأمام ، حدثت بعض الأشياء:

1. اجتمعت مجموعة من الأشخاص المثقفين والمطلعين في لجنة . ملاحظة ، كان أحد أعضاء فريق go في Google جزءًا من هذه المجموعة.
2. قامت مجموعة ثانية من الأشخاص الذين قاموا بتأليف مديري التبعية أو لديهم معلومات عنهم بدعم هذه المجموعة الأولى.
3. تم إجراء مسح للمجتمع حول الاحتياجات والأفكار حول الأدوات الموجودة (في Go وخارجها) . لاحظ أن بعض النتائج كانت خاصة لأعين اللجنة فقط.
4. تمت مقابلة الشركات التي تستخدم Go for Production للحصول على تفاصيل حول احتياجاتهم. تفاصيل هذا ليست علنية حتى يتمكن الناس من التحدث بحرية.

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

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

هل يلبي vgo احتياجات الأشخاص التي عبروا عنها في الاستبيان والمقابلات؟ مما جمعته من روس ، لم يقرأ النتائج لكنه انتقد العملية. قد يكون من المفيد قيام شخص ما برسم الخرائط.

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

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

لا ، # 25483 ليس له علاقة بـ vgo. لقد أدرجته للتو مرتجلاً كنوع آخر من الأشياء التي يمكن أن يفعلها الأمر المساعد الافتراضي go release . لكنها ستكون مفيدة في أي وقت.

كانت وجهة نظري الأكبر هي أن Go لم يجعل من السهل جدًا القيام بإصدارات من حزم Go. في حياة سابقة ، كتبت http://search.cpan.org/dist/ShipIt/ لأتمتة إصدارات حزم Perl CPAN وقد أحدثت فرقًا كبيرًا عندما يكون لديك أدوات حول مثل هذه الأشياء مقابل القيام بذلك يدويًا.

لم أذكر سوى go release افتراضيًا على الإطلاق لأنني سُئلت عما قد يفعله Go بشكل مختلف لمساعدة البشر على عدم ارتكاب الأخطاء.

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

يبدو أنه سيكون من التافه إضافة إصدار max إلى vgo كطريقة لمساعدة vgo في تحديد متى تكون مكتبتان غير متوافقين. إذا قالت إحدى المكتبات إنها تحتاج إلى الإصدار 1.7 على الأقل وقالت مكتبة واحدة إنها بحاجة إليه

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

تعمل قيود إصدار natefinch max على دفع MVS للخروج من منطقة تجنب SMT-solver الذكية.

أعتقد أن natefinch يعني إصدارات max كتحقق / مرشح نهائي. بمجرد أن تقوم MVS بعملها ، سيخطئ vgo إذا لم يتم استيفاء أي من قيود الإصدار القصوى هذه. هذا لا يزال لا يقودنا إلى منطقة حل SAT.

بالضبط. لا يوجد حل. هناك فقط "تقول vgo أن 1.7 هو الشيء الصحيح الذي يجب استخدامه ، لكن الوحدة X تنص على أنها لا تعمل مع هذا الإصدار". هذا بالفعل شيء يمكن أن يحدث اليوم مع vgo إذا كان لديك شيء يقول require foo 1.7 وشيء آخر يقول exclude foo 1.7 ، إذا لم يكن هناك إصدار foo أعلى.

ثم ماذا يفترض أن تفعل؟

أنت تستخدم عقلك البشري لاكتشاف حل ، لأنه لا يوجد حل ميكانيكي. أنت تحاول استخدام مكتبتين تنصان بشكل قاطع على أنهما تتطلبان إصدارات غير متوافقة من مكتبة. سوف يخترق A مع 1.6 ، ويكسر B مع 1.7. النهاية.

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

لا توجد إجابة جيدة. ولكن لا توجد أدوات في العالم يمكنها إصلاح ذلك لك أيضًا.

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

كانت المشكلة ، وكانت دائمًا ، أن MVS لا يحل سوى مشكلة وهمية (تجنب SAT) ،

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

كما أراها ، فإن المشاكل الملموسة التي تحلها MVS هي:

• جعل البنيات قابلة لإعادة الإنتاج افتراضيًا ،
• بناء أقرب ما يمكن من الإصدارات المختبرة ، و
• تجنب الرفض الزائف.

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

أنا موافق. لكني أريد أن ألقي نظرة فاحصة على افتراضاتك: ما هي الأدوات التي "تعاقب" المشاركة ولماذا؟

أحد الأمثلة التي قدمتها في رسالتك كان ، "يعتمد مشروعنا على [email protected] الآن ، لكنه لا يعمل مع [email protected] أو أحدث. نريد أن نكون مواطنين صالحين ونتكيف ، ولكن ليس لدينا النطاق الترددي في الوقت الحالي ".

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

في المقابل ، بموجب MVS ، يلتزم المشرفون فقط بالإعلان عن شيء واحد: "لقد اختبرنا بدقة مقابل [email protected] وقد نجح الأمر." إذا لم يفعل المستخدمون أي شيء لتعطيل ذلك ، فإنهم يبنون مقابل [email protected] ويستمر كل شيء في العمل كما كان يفعل من قبل.

ضمن MVS ، يحدث الكسر فقط في وقت الترقية الصريحة. - هذه فائدة كبيرة: إذا قام المستخدم بترقية بعض التبعية الأخرى بحيث يسحب [email protected] ويكسر استخدامهم لحزمتك ، فيمكنهم ببساطة تراجع عن تلك الترقية حتى يتوفر لديك الوقت لإصلاحها ، _ أو حتى يتاح للمشرف X وقتًا لتصحيح عدم التوافق. - وبالنظر إلى التوقعات الصحيحة ، قد يكون الأخير أكثر احتمالية من السابق: إحراز الخروج [email protected] قد يتحول إلى عمل مزدحم لا داعي له إذا [email protected] التوافق.

الافتراض الثاني الذي تقوم به هو أن كل عدم توافق يؤثر على _ أي جزء_ من الوحدة الخاصة بك يؤثر على _جميع مستخدمي_ وحدتك. إذا كان جزء الحزمة الخاص بك الذي ينكسر تحت [email protected] وظيفة مستخدمة قليلاً ، فلماذا تمنع المستخدمين من ترقية X في برنامجهم الذي لا يسميه حتى؟

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

¹ بشكل عام ، يتطلب اكتشاف حالات عدم التوافق مع التبعيات اختبارًا مقابل المنتج المتقاطع لجميع الإصدارات من تلك التبعيات: من الممكن أن يكون استخدامك الخاص لـ [email protected] جيدًا ، لكنه ينفصل مع بعض الحزم الأخرى التي تعتمد عليها تشغيل. على سبيل المثال ، ربما تحتاج أنت والتبعية إلى خيارات غير متوافقة في تكوين عام.

يمكنهم ببساطة التراجع عن تلك الترقية

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

إذا كان جزء الحزمة الخاص بك الذي ينكسر تحت [email protected] هو وظيفة مستخدمة قليلاً ، فلماذا تمنع المستخدمين من ترقية X في برنامجهم الذي لا يسميه حتى؟

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

هذا يفترض أن هذا خطأ في المترجم أو شيء مشابه مرئي للغاية. من المرجح أن يكون خطأ سلوك خفي غير واضح على الفور.

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

ما الذي يجعل هذه الفئة الخاصة من الحشرات خاصة؟

من الذي سيقول أن بعض مسارات البرمجة غير المستخدمة لن يتم تنشيطها فجأة على الطريق عندما تقوم بتغيير الكود الخاص بك؟

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

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

ما الذي يجعل هذه الفئة الخاصة من الحشرات خاصة؟

إنه ليس مجرد خطأ. إنه أكبر من ذلك. قال مؤلف المكتبة ، وهو أول خبير في الكود الخاص بهم ، للعالم "إن الإصدار 1.7 من X يكسر أشيائي بطرق سيئة للغاية ، فقط لا تبني معها".

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

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

إنه ليس مجرد خطأ. إنه أكبر من ذلك. قال مؤلف المكتبة ، وهو أول خبير في الكود الخاص بهم ، للعالم "إن الإصدار 1.7 من X يكسر أشيائي بطرق سيئة للغاية ، فقط لا تبني معها".

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

اكتب اختبارًا يفشل عند استخدامه مع إصدار غير متوافق من X.

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

هناك سبب لعدم قيام go test ./... بإجراء الاختبارات في دليل البائع.

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

لماذا لا يتفق الطرفان على معاقبة اقتراح منافس يستكشف كيف يمكن أن يتلاءم GPS2 مع أجزاء من vgo مثل كلا الجانبين. بعد ذلك ، قم بدمج تجربة vgo في هذه الأثناء وإعادة النظر في اقتراح GPS2 قبل دمج vgo مع mainline؟

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

مجرد إلقاء هذا هناك:

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

هذه مشكلة في البرامج بشكل عام. تستخدم NPM (أداة الإصدار الأخرى التي أمتلكها أكثر من غيرها) أداة حل SAT مدمجة مع المجتمع الذي تبنى بشدة semver ، ولا تزال هذه المشكلة قائمة.

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

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

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

malexdev قد تكون هناك مشكلة مع الممثلين في الحجة التالية:

دعونا لا نفشل في تنفيذ حل جيد لعدم وجود حل مثالي.

ديب هو حل جيد اليوم. واحد تم إنشاؤه بواسطة المجتمع للعمل معًا. vgo ، كما بدأ سابقًا ، يضع عدة افتراضات:

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

يعتمد vgo بشكل أكبر على "الحل الأمثل" في "عالم مثالي" بينما يعمل dep اليوم باتباع ما يعمل بالفعل في النظام الإيكولوجي للغات البرمجة الأخرى بينما يتسامح مع الأخطاء.

يمكنك رؤية هذا في تاريخ مساحة مشكلة إدارة الحزم التي كتبتها للتو .

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

أنا أتفق مع هذا الملخص.

لماذا لا يتفق الطرفان على معاقبة اقتراح منافس يستكشف كيف يمكن أن يتلاءم GPS2 مع أجزاء من vgo مثل كلا الجانبين.

في هذه المرحلة ، ما زلت غير مقتنع بأن GPS2 ضرورة أو حتى فكرة جيدة. يمكن تعديل القدرة التي حددتها أعلاه لتعديلها إلى vgo فوق MVS (مثل هذا أو هذا ). أنا شخصياً آمل أن تحتوي التدوينة التالية على مدونة sdboyer على حجج جيدة ضد MVS نفسها ، لكن في الوقت الحالي ، لا أرى أي سبب حقيقي لخوارزمية مختلفة - لا سيما تلك التي قد تكلف مزايا UX كبيرة من vgo.

رغم ذلك ، لكي نكون منصفين ، لا أرى أيضًا أي سبب يمنع تجربة ذلك.

ديب هو حل جيد اليوم.

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

1. أن لا أحد سوف ينفصل عن سمفر ، حتى عن طريق الصدفة

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

أعتقد بشكل عام أنه من المنطقي التمييز بين الأجزاء المختلفة لما نتحدث عنه. بعض الشكاوى تتعلق بـ SIV ، وبعض MVS وبعض Vgo-shell العام. على سبيل المثال ، صحيح أن MVS لا يمكنه التعامل مع حدود الإصدار الأعلى ، لكن هذا لا يعني أن vgo لا يمكنه التعامل مع حدود الإصدار الأعلى. يتطلب SIV تغيير الكثير من التعليمات البرمجية (عن طريق إعادة كتابة بيانات الاستيراد) ، ولكن مرة أخرى ، هذا لا يعني بالضرورة أن vgo سيتطلب ذلك. على الرغم من أني لأكون واضحًا ، فأنا لا أعتقد أيضًا أنها صفقة كبيرة ، طالما أننا قادرون على الهجرة. أي AFAICT نستطيع.

لقد شاهدت للتو الكلمة الرئيسية الافتتاحية لـ GopherConSG من rsc حول تعيين الإصدار. لقد تناول السيناريو حيث تقدم التبعية تغييرًا مفاجئًا ، وقارن كيف سيتعامل معها vgo و dep ، والذي يبدو أنه الشاغل الرئيسي هنا. (إنها ساعة رائعة.)

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

willfaught بالنسبة لنا ، يعتبر dep كسر البناء عند استخدام حد أقصى للإصدار لتجنب إصدار سيئ نجاحًا! هذا ما نريد أن يحدث. يلاحظ روس بشكل صحيح أن هذه المشكلة لا يتم حلها تلقائيًا. لن يؤدي قيد على Helm>2.0.0 إلى ترقية المستخدم تلقائيًا إلى " [email protected] " ولكنه سيعمل بنجاح (الرجوع إلى إصدار أقدم من grpc أو يؤدي إلى فشل إنشاء إذا كان ذلك مستحيلًا) إذا كان المستخدم يعتمد صراحة على "Helm == 2.1.4 ". شخصيًا ، أول شيء أحاول عادةً عند مواجهة مشكلة في مكتبة هو فرض تحديث لأحدث إصدار. مع Dep ، سيبلغني هذا بالفشل الذي قدمه GRPC 1.4.0. باستخدام vgo ، الطريقة الوحيدة التي يستخدمها Helm لإيصال هذا إليّ هي من خلال التوثيق.

لتكرار النقطة لأنها لا تزال غير مفهومة: لا يمكن لأي dep ولا vgo منع حدوث هذه المشكلة أو تقديم حل مضمون. بدلاً من ذلك ، يسمح dep لـ Helm بالإبلاغ عن وجود المشكلة ، في حين أن vgo لا يفعل ذلك.

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

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

أعتقد أن @ Merovius يعمل على حل عملي. ستستمر MVS على النحو المحدد ، ثم بعد اكتمال الحل ، سيتحقق vgo من كل حزمة تم حلها بحثًا عن الاستثناءات. إذا تم العثور على أي منها ، يتم إبلاغ المستخدم النهائي بها ، والذي يمكنه اختيار تغيير تبعياته لتلبية هذه القيود أو اختيار تجاوز القيود وتجاهلها. لقد كنت في الجانب الآخر من هذا أيضًا وأحيانًا تعرف أفضل من المشرف ؛ إنه يعمل مع تطبيقك وهذا كل ما تهتم به.

يؤدي هذا إلى استعادة مسار للمكتبات الوسيطة لإبلاغ المستخدمين النهائيين بعدم التوافق. لتكرار مثال الدفة مرة أخرى:

[email protected] : Helm @ 2.1.2
[email protected] : GRPC @ 1.3.5

==> ترقيات المستخدم إلى [email protected] عمدًا.

المستخدم: Helm @ 2.1.3، [email protected] ("تم تحديث Helm ، لذا يمكنني أخيرًا استخدام grpc 1.4!")
Helm: GRPC @ 1.4.0

==> تم اكتشاف خطأ! يرى المستخدم بعض المشكلات في Helm ، لذا تحقق من وجود إصدار جديد.

المستخدم: [email protected] ، [email protected]
Helm: GRPC @ 1.3.5 ، GRPC ضعيف <1.4.0

يرى المستخدم تحذيرًا بأن GRPC 1.4.0 مرفوض من خلال تثبيت [email protected]. نظرًا لأن Helm معطل بالنسبة لي وهذا ما أحاول إصلاحه ، فقد قمت بإزالة اعتمادي على GRPC 1.4.0 (للأسف فقد بعض الوظائف المفيدة) وأعد تشغيل MVS. هذه المرة ، حل MVS GRPC إلى 1.3.5 و Helm إلى 2.1.4 ، وأعاد فحص جميع القيود الضعيفة ، واكتشف أنها تحمل ، وقد انتهيت.

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

willfaught بالنسبة لنا ، يعتبر dep كسر البناء عند استخدام حد أقصى للإصدار لتجنب إصدار سيئ نجاحًا! هذا ما نريد أن يحدث.

النقطة التي أثيرت في الحديث هي أن vgo ليس أسوأ من dep في هذا السيناريو. في مثاله ، لم يتم كسر البناء بمعنى أن القسم لا يمكنه إيجاد حل ؛ إنه معطل بمعنى أن الإدارة لا تجد حلاً ، وأن هذا الحل يتضمن الإصدار السيئ ، مما أدى إلى نفس الموقف السيئ الذي أردنا تجنبه.

يجب أن تشاهد مقطع الفيديو حقًا ، الذي يسير عبر مثال ممتاز ، ولكن هذا هو جوهر ما فهمته / أتذكره:

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

أوافق في الغالب على اقتراح إضافة أقصى استثناءات للإصدار ، ولكن لدي هذا القلق: لنفترض أنني وضعت في مكتبتي "استخدم gRPC> 1.4 ، <1.8" ثم في gRPC 1.9 ، قرر المؤلفون ، "أنت تعرف ماذا ، كان Helm حسنًا ، لقد أجرينا تغييرًا مفاجئًا في 1.8 ، وسنعود إلى سلوكنا السابق في 1.9.0 ". الآن الأشخاص الذين يحاولون استيراد Helm + gRPC لن يتمكنوا من استخدام 1.9 حتى تصدر Helm إصدارًا يقول "استخدم gRPC> 1.4 ، باستثناء 1.8.0 ، 1.8.1 ، 1.8.2 ، لكن 1.9+ رائع".

بمعنى آخر ، ربما يكون exclude grpc 1.8 كافيًا لأننا لن نعرف ما إذا كان gRPC 1.9 سيكون غير متوافق أم لا حتى يتم نشره ، وعند هذه النقطة يمكن لـ Helm إما إضافته إلى قائمة الاستبعاد أم لا.

لا أعرف شيئًا عن هذا الفضاء. ولكن من قراءة المناقشة هنا ، يبدو أن الخلاف الأكبر يتلخص في كيفية اكتشاف الحالات الخاطئة. أي أن كلاً من MVS (vgo) و SAT (dep) يتعاملان مع المواقف العادية بشكل جيد أو أقل ، ربما ليس بشكل متماثل ، ولكن بشكل جيد بما فيه الكفاية.

يوفر SAT قدرة لا توفرها MVS: باستخدام SAT ، يمكن لمؤلف حزمة المكتبة P1 أن يعلن أن "P1 يتطلب P2 ، ويعمل مع P2Version> 1.1 و P2Version <1.4". يمكن لـ MVS فقط الإعلان عن "P1 يتطلب P2 ، ويعمل مع P2Version> 1.1" ، ولا يمكنه التعبير عن القيد "P2Version <1.4". في الحالة العادية ، هذا لا يهم. لا يهم إلا إذا حاولت بعض العمليات ترقية P2 إلى الإصدار 1.4. في هذه الحالة ، ستبلغ SAT عن خطأ ، بينما لن تقوم MVS بذلك. عند استخدام MVS ، إذا لم يكن عدم التوافق خطأ في التحويل البرمجي ، فقد يتسبب ذلك في حدوث عطل لفترة طويلة بعد حدوثه.

لا شك أن مؤيدي SAT يرون مشاكل كبيرة أخرى مع MVS ، لكن حتى الآن هذا هو ما أفهمه.

أعتقد أنه من الجدير بالذكر أنه إذا تم إصدار تعبيرات التقييد نفسها - إذا كانت جزءًا من إصدار معين من P1 - فعندئذٍ في المسار الطبيعي للأحداث ، قبل إصدار P2 الإصدار 1.4 ، سيقول P1 الإصدار 2.2 لحسن الحظ "P2Version > 1.1 ". فقط عندما يتم إصدار الإصدار 1.4 من P2 ، سيلاحظ مؤلفو P1 عدم التوافق ، ويصدرون الإصدار 2.3 من P1 مع "P2Version> 1.1 و P2Version <1.4". لذلك إذا كنت تستخدم الإصدار 2.2 من P1 ، فلن يبلغ SAT أو MVS عن أي مشكلة في ترقية P2 إلى الإصدار 1.4 ، على الرغم من أنه قد يفشل بطريقة خفية.

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

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

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

لذلك إذا كنا نفكر من حيث

1. طريقة لتعريف البيانات الوصفية للحزمة التي تصف عدم توافق الحزم
2. بناءً على ذلك ، أداة تُبلغ عما إذا كانت حزمك الحالية متوافقة

ثم ربما تصبح بعض الاختلافات الرئيسية بين MVS و SAT أقل أهمية.

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

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

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

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

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

ما هو مهم حقًا هنا هو هذه النقطة ، على الرغم من أنه ربما ليس بالطريقة التي كنت تقصدها:

ربما تصبح بعض الاختلافات الرئيسية بين MVS و SAT أقل أهمية.

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

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

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

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

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

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

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

اقتراح أداة التعريف التي تقوم بهذا البحث - نعم ، هذا بحث SAT

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

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

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

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

في 28 مايو 2018 ، الساعة 4:02:13 مساءً بتوقيت شرق الولايات المتحدة ، كتب Axel Wagner [email protected] :

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

اقتراح أداة التعريف التي تقوم بهذا البحث - نعم ، هذا ملف
بحث SAT

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/golang/go/issues/24301#issuecomment -392595150

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

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

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

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

يحدث لي أن شيئًا ما خارج التحكم في المصدر يحدد التوافق من شأنه أن يغير حتمية نظام MVS. إذا كان لديك foo> = 1.5.0 كقيد في lib واحد ، وكان lib آخر foo> = 1.6.0. ثم ضع هذين في ثنائي ويختارون 1.6.0. في MVS ، هذا كل ما تحتاجه لبناء قابل للتكرار. سيختار دائمًا 1.6

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

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

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

leighmcculloch ، إذا تم تحديث أي ملفات في التطبيق ، فهذا بناء مختلف تمامًا وخارج نطاق مشكلة "الإنشاء القابل للتكرار بدون ملف القفل".

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

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

الهدف من معلومات عدم التوافق هو أن يقوم مؤلفو المكتبات بإيصال معلومات عدم التوافق إلى مستخدميهم. ما إذا كانت هذه المعلومات تستخدم في البناء أو في وقت الإصدار هو سؤال مختلف.

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

في القسم ، يتم استخدام هذه المعلومات فقط في وقت الإصدار ثم يتم تسجيلها في ملف قفل ، والذي يتم استخدامه في وقت الإنشاء. لذلك يبدو أننا نفكر في استخدام وقت الإصدار "جيد بما فيه الكفاية" على أي حال ، على الأقل عندما يتعلق الأمر بمخاوف من vgo vs. dep.

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

[1] أنا شخصياً أزعم أن استخدامه في وقت الإصدار وفقط إذا تم استخدام -v في وقت الإنشاء يكون أفضل ، لأنه لا يجب على المستخدم أن يقرر ما إذا كان التحذير قابلاً للتنفيذ أم لا.

كتب rsc :

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

أتساءل عما إذا كان من الضروري تسجيل عدم التوافق بين الزوجين. الطريقة التي أراها حاليًا هي أن أي عدم توافق بين الوحدة النمطية A @ vN والوحدة B @ vM هو حقًا لأن B قام بتغيير غير متوافق من بعض إصدارات vL حيث L <M.

إذا لم تقم الوحدة "ب" بإجراء تغيير غير متوافق ، فإن الوحدة "أ" بها خطأ فقط. إذا كان الأمر كذلك ، فإن المشكلة تتعلق بـ B نفسها ، وليس حول الاقتران بين A و B.

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

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

قد تكون مجموعة مجموعات النموذج ( وحدة ، إصدار قديم ، إصدار جديد ، وصف ) كافية.

يمكن لأداة go أن تأخذ في الاعتبار البيانات الوصفية وترفض النظر في إصدار غير متوافق مع أي إصدار يتم اختياره حاليًا

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

أخشى أن يصبح go release "مترجمًا ذكيًا بدرجة كافية" لهذه المناقشة. ما الذي يمكن أن يتوقعه المستخدمون بشكل ملموس من go release في Go 1.11 / 12؟ أعتقد أن هذا يحدث فرقًا بالنسبة للتوقعات المعقولة حول MVS / SIV.

شكرًا على الطاقة التي جلبها الكثير منكم إلى Go وهذا الاقتراح على وجه الخصوص.

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

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

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

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

شكرا مرة أخرى على مساعدتك.

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