Jinja: حدد تسمية متسقة لـ "Jinja" أو "Jinja2"

تم إنشاؤها على ٢٥ يوليو ٢٠١٧  ·  17تعليقات  ·  مصدر: pallets/jinja

استمرار المناقشة من https://github.com/pallets/meta/issues/10#issuecomment -209980352

التسمية غير متسقة:

  • Github repo هو jinja
  • اسم حزمة Pypi هو jinja2
  • مشروع المنصات يسميها "جينجا": https://www.palletsprojects.com/p/jinja/
  • مساحة الاسم RTD هي jinja2.readthedocs.io
  • مستندات Pocoo (الرسمية حاليًا) هي "Jinja": http://jinja.pocoo.org/docs/2.9/
  • امتدادات الملفات تكون أحيانًا .jinja ، .j2 ، .jinja2 ... يستخدم مشروع Ansible حاليًا .j2

يجب أن نختار إما "Jinja" أو "Jinja2" ونستخدمها في كل مكان لتحقيق التناسق.

أنا منفتح على أي منهما ، "Jinja" أبسط وأقصر ، لكن "Jinja2" لها حلقة أكثر تميزًا وأقل عرضة للارتباك مع أي مشاريع أخرى.

التعليق الأكثر فائدة

علامة Stack Overflow هي "jinja2" ، "jinja" هي مرادف يتم تحويله بشكل غير رسمي. رغم جهودي تجاه العكس. (حدث هذا قبل عام أو نحو ذلك).

أريد حقًا إسقاط "2" من الاسم. ابدأ في إضافة إصدارات v2 إلى صفحة PyPI "jinja". تجاهل استيراد "jinja2" والعودة إلى مساحة الاسم "jinja".

ال 17 كومينتر

علامة Stack Overflow هي "jinja2" ، "jinja" هي مرادف يتم تحويله بشكل غير رسمي. رغم جهودي تجاه العكس. (حدث هذا قبل عام أو نحو ذلك).

أريد حقًا إسقاط "2" من الاسم. ابدأ في إضافة إصدارات v2 إلى صفحة PyPI "jinja". تجاهل استيراد "jinja2" والعودة إلى مساحة الاسم "jinja".

ThiefMastermitsuhikountitaker هل الرجال لديهم آراء؟

أعتقد أنه يمكننا القيام بذلك ولكني أقترح شخصيًا مواءمة الإصدار 3.0 مع ذلك.

: +1: انتظار 3.0.


علامة Stack Overflow هي "jinja2" ، "jinja" هي مرادف يتم تحويله بشكل غير رسمي. رغم جهودي تجاه العكس. (حدث هذا قبل عام أو نحو ذلك).

قد أكون قادرة على إصلاح ذلك.

تحرير: نعم أستطيع

إعادة تسمية المعاينة
سيتم إزالة jinja2 من 3486 سؤالا
ستتم إضافة jinja إلى 3486 سؤالاً
سيتم نقل التزامات 5 لمقترح وثائق jinja2 إلى اقتراح jinja
سيتم إنشاء تعيين مرادف الوسم jinja2 → jinja.
(تشمل هذه الأعداد الأسئلة المحذوفة واستبعاد العلامات المتداخلة)

ما هو الجدول الزمني للإصدار 3.0؟

كلما أسرعنا في إعطاء الأشخاص تنبيهًا ، كان ذلك أفضل ، فماذا عن إضافة تحذير الإيقاف الآن على الواردات jinja2 وتحذيرًا بشأن استيراد jinja الذي سنقوم به قريبًا بدفع v3 إلى jinja مساحة الاسم؟

davidism هل أنت قادر على نقل مساحة اسم RTD إلى jinja ؟ وفقًا لتعليقي أعلاه ، فهو حاليًا أقل من jinja2 ، و IIRC ، هل كنت تقود عملية ترحيل / تنظيف ملكية مساحات أسماء RTD لمشاريع أخرى؟

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

يبدو حفظ التغييرات العاجلة وتوحيد الاسم لـ Jinja v3 رائعًا بالنسبة لي. قد نحاول أيضًا العثور على التغييرات العاجلة التي يمكننا تحديدها من أجلها.

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

nudgedavidism - حسب تعليقي أعلاه ، هل أنت قادر على تعديل مساحة اسم RTD من jinja2 إلى jinja؟

في الإصدار 2.11 ، أفكر في إعادة تسمية الحزمة إلى jinja ، مع وحدة placholder للوحدة jinja2 التي تعيد توجيه جميع الواردات وتصدر تحذيرًا بالإيقاف.

لا يزال يتعين علي تحديد توقيت هذه الخطوة التالية ، ولكن أود أيضًا محاولة العودة إلى اسم "Jinja" على PyPI. أعتقد أن ما سأحاول القيام به هو الحصول على إصدار Jinja 2.11 الذي يتضمن العنصر النائب jinja2 ، وجعل Jinja2 2.11 يعتمد فقط على jinja>=2.11 ، أو أن يكون لديك شريحة صغيرة تشرح التثبيت الاسم الآخر دون كسر أي رمز. أنا على استعداد لبذل جهد إضافي للحفاظ على مزامنة هذه البنيات لفترة من الوقت أثناء إدارة عملية النقل.

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

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

السبب وراء إعادة تسمية الحزمة بـ 2.0 هو أنه لا توجد طريقة (ولا تزال هناك طريقة) للحصول على تثبيتات متوازية من مكتبات Python غير متوافقة على عكس node أو rust can. بسبب ذلك أعتقد أننا سنكون عاجلاً أم آجلاً مرة أخرى في موقف غبي حيث يحتاج Jinja 4.0 إلى تسمية "Jinja4" على pypi.

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

coleifer ليس لدي أي فكرة حقًا

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

~ fwiw يمكننا أيضًا إصدار إصدار جديد (نقطة) من jinja2 يعيد تصدير كل jinja (أي أنه الرقاقة). يعمل هذا عادةً في Rust عندما يكون لديك تبعيات متعددة تعتمد على حزمة أخرى. عليك فقط تحديث jinja2 لجعل الحزم التي تعتمد على jinja2 تستخدم ضمنيًا الأنواع من jinja . ~ تجاهل هذا. هذا هو بالضبط ما تفعله الرقاقة. ليس لدي فكرة ما هو القلق.

untitaker مهتم بالمشكلات التي تشير إليها بإجراء إعادة التسمية في Jinja 3.0 بدلاً من ذلك. بناءً على المناقشة مع ThiefMaster ، يبدو أن القيام بذلك في 3.0 كان منطقيًا أكثر ، لأنه يمثل تغييرًا كبيرًا. فكرنا أيضًا في إصدار 2.12 لإعادة التسمية فقط.

سيكون Jinja2 3.0 هو الرقاقة والسحب في Jinja 3.0 كتبعية.

من المحتمل أن يكون ذلك جيدًا ، لكنه سيمنع استخدام الاسم الجديد jinja مع الحزم التي تعتمد صراحة على Jinja2==2.* . مما يحد من الفائدة المحتملة للرقاقة.

نعم ، كان هذا أحد الأسباب الأولية لاستخدام 2.11. أعتقد أن 2.12 مقابل 3.0 يأتيان لاتخاذ قرار بشأن ما إذا كانت إعادة التسمية تغييرًا رئيسيًا على الرغم من أن jinja2 سيستمر في العمل ويصدر تحذيرات الإيقاف. 3.0 كان في الأصل إصدارًا رئيسيًا فقط لأنه أسقط Python 3.


بعد مزيد من المناقشة داخليًا ، سنعود إلى هذا. انظر # 1131.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات