Fabric: تقسيم الميزات غير المعتمدة على ssh إلى lib منفصل

:كيك:

تعد الأداة الجديدة تمامًا التي تناسب حالة الاستخدام خيارًا دائمًا أيضًا بالطبع.

وصف محدث حفنة.

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

الأفكار:

• توني - كما في Tony Masters الملقب بـ Taskmaster (كتب هزلية ~)
• الرئيس التنفيذي - يدير الأشياء ، (أو القيصر أو شيء مشابه على هذا المنوال)

آسف أنا أمتص في الأسماء :(

أيضًا أشياء مثل "kirk" (كما في Captain kirk).

حاولت التفكير في شيء يتعلق بالنسيج يتعلق بتشغيل المهام ولكن لا يمكنني التفكير في شيء يرتبط بالمهام + النسيج.

لكن Loom ليس اسمًا سيئًا لا أعتقد ذلك.

الاسم الأولي العصف الذهني.

المفاهيم

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

الأسماء غير مأخوذة في PyPI

• runner
• executor
• go
  
  
  
  • الخلط مع لغة البرمجة و / أو لعبة اللوحة ، خاصة إذا كان الأول يحتوي على ثنائي يسمى على وجه التحديد go
  
  
  • للأفضل أو للأسوأ ، يحتوي على العديد من أسماء المهام السخيفة المحتملة مثل away أو fuck_yourself أو bother_somebody_else
  
  
• weaver

أسماء ثنائية

شكرًا ، قاموس المرادفات Oxford American Writer كما تم تقديمه بواسطة تطبيق قاموس OS X's!

• run
• execute
• go
  
  
  
  • أنظر فوق
  
  
• create (مثل make )
• fabricate (طويل جدًا ، ومن السهل جدًا الخلط بينه وبين fab )
• fab (على سبيل المثال ، هل لديك اسم lib الجديد بشكل مختلف ولكن لا يزال يتم تثبيت fab ثنائي ؛ إذا كان كلاهما موجودًا على النظام ، فإن الأسبقية لـ Fabric؟ تبدو وكأنها فكرة غبية.)
• generate
• produce
• fashion (meh)
• build
• devise
• shape
• setup
• weave

ليس في أفضل حالات العصف الذهني اليوم. تريد moar.

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

الرئيس: يدير الأشياء.

شارك. Kinda مثل Make ، ولكن من أجل Python.

تنفيذي.

تعجبني فكرة أنها تتجه نحو المهام. همم..

@ kennethreitz ، أنا أحب بوس ، بخلاف الارتباك المحتمل مع مواطن معين من نيوجيرسي (آسف ، لست معجبًا ، تجربة رفيقة السكن السيئة في الكلية)

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

خادمة مثيرة للاهتمام. يؤدي المهام الخاصة بك نيابة عنك. على غرار "صنع".

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

maid clean ، maid release ، maid test . احب ذلك.

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

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

Boss كاسم مكتبة مأخوذ بالفعل FWIW

في يوم الثلاثاء 21 فبراير 2012 الساعة 8:38 مساءً ، كتب جيف فورسيير:

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

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

intern هو أيضًا اختيار رائع بشكل لا يصدق.

dstufft حسنًا ، ولم أستطع التفكير في اسم ثنائي جيد لذلك أيضًا ، boss docs غير مناسب حقًا.

ذكر @ kennethreitz bake على IRC ، والذي يتناسب مع سمة make / rake ، وأيضًا يناسب نوعًا من فعل الاستدعاء (على سبيل المثال ، $ bake docs ، على الرغم من أنه من الناحية الموضوعية قليلاً ، يبدو أنه '' د تناسب أفضل في الشيف أو شيء من هذا القبيل.

تحرير: أيضًا deliver . كان رد فعلي الأولي على هذا الأمر إيجابيًا إلى حد ما ( $ deliver build $ deliver docs ) ولكن لا يوجد اسم مشروع _great_ يتماشى معه ، فهو ليس سخيفًا إلى حد ما ، وهو طويل بعض الشيء.

$ invoke taskname (أسماء المشاريع: invoker ، invoked ، ؟؟؟)

استدعى.

أنا معجب حقًا بـ Invoked و invoke docs invoke tests invoke publish إلخ.

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

أعتقد أن "الاستدعاء" أكثر إثارة قليلاً من "الاستدعاء" ، ولكن يمكن لأي منهما أن يعمل.

لا يجب أن يختلف الاسم ، لا ، إنه أكثر منطقية في كثير من الأحيان.

لقد فكرت أثناء المشي إلى القطار (في القطار المذكور الآن: P go go ربط الهاتف الذكي!) وهو أنه يمكننا _يمكننا _ تخطي كل هذا وببساطة نقل الجانب fab + fabfile.py بالكامل من الأشياء إلى هذه المكتبة "الجديدة" (وسميها ، على سبيل المثال ، fabricator ).

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

الإيجابيات:

• لا حاجة لاسم ثنائي جديد
• سيكون وجود اسمين ثنائيين مربكًا على أي حال
• إذا لم يستخدم lib _didn't_ "ملفات fabfiles" الجديدة ، فسيكون لدينا نوعان مختلفان من "ملفات المهام" أيضًا ، مرة أخرى مربكًا / رمز إضافي / إلخ.

سلبيات:

• التباس محتمل بين المشروعين بسبب الأسماء المتشابهة
• يجب أن يكون المشروع الجديد قابلاً للتوسعة بشكل إضافي للسماح لجميع نماذج Fabric (على سبيل المثال جميع أعلام CLI تقريبًا ، وما إلى ذلك) بمواصلة العمل كما هو
  
  
  
  • أي pip install fabricator يمنحنا fab ، والذي سيكون به مجموعة صغيرة من الأعلام
  
  
  • ثم إذا كان لديك pip install fabric ، فجأة يجب أن تعرض نفس fab جميع أعلام Fabric CLI الإضافية ، إن لم تكن أشياء أخرى أيضًا
  
  
  • OTOH لا يشبه السماح لرمز "العميل" بتوسيع تحليل CLI فهو أمر سيء ، إنه مجرد عمل أكثر يجب القيام به مقدمًا.
  
  

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

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

أعتقد أن الارتباك في الاسم سيكون مشكلة.

هذا شيء شخصي ولكني أحب مظهر invoke test invoke docs أفضل من fab test .

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

أعتقد أنه إذا ذهبت إلى مسار الاستدعاء + النسيج الذي يسبق 2.0 كل من فابفيليس و "إنفوكيفيلز"؟ سيتم دعمه ، وبعد ذلك مع 2.0 فقط استدعاء الملفات؟

لذلك أنا في الأساس +1 لتقسيمه إلى "عداء مهام" و "بعيد / عناصر ssh" ، ووضع حشوات متوافقة لـ 1.x ، وإهمال الأشياء لـ 2.x. أعتقد أن هذا التقسيم سيجعل كلا من libs أفضل ، وسوف يدعم عداء المهام بعض القابلية للتوسعة اللطيفة (وربما المهام الخارجية التي يمكن الاعتماد عليها بسهولة وتشغيلها وما إلى ذلك). وستستفيد الأشياء البعيدة / ssh من وجود مجموعة أصغر من المسؤوليات مما يسمح لها بأن تكون أكثر تركيزًا /

سنتي على أي حال.

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

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

dcolish لم أكن أقصد الإيحاء بأنه من غير الممكن عمل امتدادات CLI ، والأنف هو بالتأكيد فن سابق جيد لفحصه.

إذا استخدمنا "استدعاء" ، فربما يكون اسم الملف invocations(.py) ؟ لمسة على الجانب السخيف / المنتزه ، لكنه يناسب قواعد اللغة ، و invokefile.py يبدو محرجًا بعض الشيء بالنسبة لي. أو ربما تذهب إلى طريق Rake Convention واستخدم tasks(.py) .

مرتبطًا جزئيًا ، أعتقد أنه يجب علينا بالتأكيد أن نلعب / نركز على جانب الوحدة / المجلد للمضي قدمًا. نظرًا لأنه Just Python إما أنه سيظل مدعومًا ، ولكن فيما يتعلق بالمواد التعليمية والمستندات ، فقد يكون الحصول invocations/__init__.py هو الخيار الافتراضي أمرًا جيدًا.

أحب tasks.py . من الغريب كتابة invocations.py .

حسنًا ، ليس الأمر كما لو كنت مضطرًا إلى كتابته كثيرًا ، أليس كذلك؟ ؛) لكن نعم ، tasks/ أو tasks.py أكثر وضوحًا على مستوى العالم.

ملف المهام

أنت invoke مهام (.py | /) ، الصياغة لطيفة على أي حال :)

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

@ kennethreitz ، لم أكن أبدًا معجبًا كبيرًا بـ XYZFile باعتباره اصطلاحًا للتسمية ، وخصوصًا أنه كثيرًا في هذه الأيام _ ليس ملفًا واحدًا ، لا أرى أي حاجة لمواصلة الاتفاقية خارج Fab 1.x :)

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

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

askedrelic نعم ، لقد كان وجود شيئين في واحد دائمًا مربكًا بعض الشيء للأسف.

غير ذي صلة: أستدعيtswicegood إلى هذا الموضوع منذ أن ناقشنا أنا وهو المسألة قبل بضعة أسابيع وأعتقد أنه قد يرغب في تقييمها. كالعادة ، احتفظ بالحق في عدم الموافقة ؛)

تم استدعائي؟ :-)

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

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

if __name__ == "__main__":
    <some_mod>.main()

ثم تستخدم بايثون فقط. أنا بخير مع ملف قابل للتنفيذ ، فقط لا أعرف ما إذا كان ضروريًا.

FWIW ، لقد بدأت مشروعًا منذ بضعة أسابيع للتعامل مع إنشاء حزمة تسمى flunky . بالتمسك بهذا الموضوع المصاحب ، يتوفر كل من footman أو lacky (الأخير لديه تعارض مع lackie - مشروع Ruby). يوم آخر سيكون يوم الجمعة ، كما في يوم الجمعة فتاة / رجل . اجتاز اختبار GitHub / PyPI / Homebrew حيث لا يوجد شيء اسمه ذلك. في الواقع ، الآن بعد أن أفكر في ذلك سيكون خياري الأول.

رهان جانبي ، أتساءل كم من الوقت سيستمر حتى تقدم niran للعلاقات العامة لتحديث README لتشمل الأغنية الواضحة ، وإن كانت مروعة.

أعتقد أن وجود "ثنائي" على - $PATH "ثنائي" (خاصة بالنظر إلى أنه ليس _ حاليًا _ ثنائيًا حقيقيًا ولكنه مجرد كعب تم إنشاؤه بواسطة setuptools والذي يستدعي (invoked|fabric).main() ) هو الأكثر سهولة في الاستخدام ، ولا أرى أي فوائد لنقل محتويات هذا كعب الروتين ليتم إنشاؤه تلقائيًا داخل وحدة المهام (وفي الواقع أرى عددًا من الجوانب السلبية له.)

ونعم ، بيت القصيد من هذا هو أن ينتهي بك الأمر مع lib الذي يتيح لك الحصول على الأشياء المهمة دون الحاجة إلى أي SSH / شبكة / أقسام تشفير :)

أتفق تمامًا مع bitprophet على الملف القابل للتنفيذ. يجعل تشغيلها أسهل. إذا أراد شخص ما استخدام شيء آخر غير invoke / fab في مشروعه الشخصي فهو مجرد كعب حتى تتمكن بسهولة من إنشاء ملفك الثنائي (ويمكن أن يعيش بسهولة على finalname.__main__.main ، في هذه الحالة يمكنك أيضًا python -m finalname فقط إذا أردت ذلك أيضًا.

+1.

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

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

الأفكار رائعة ، أحب الأفكار :)

يوم الجمعة قليل جدًا على الجانب اللطيف ، على الرغم من أنني أحب مرجع ثقافة البوب. تلك الأغنية رائعة جدا! :وجه القزم:

أعتقد في الوقت الحالي أنني سأذهب مباشرة إلى invoke كاسم للحزمة / المشروع ، والاسم الثنائي. يوينك! كان Invoker أو Invoked من الاحتمالات الأخرى للأول (أي لا يزال مع invoke ثنائي) لكنني لم أستطع التفكير في أي سبب وجيه لعدم السير في الطريق المباشر.

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

dcolish تم إقراره ، شكرًا!

لم أتخذ قرارًا نهائيًا بعد ، لكنني أعتقد في هذه المرحلة أن النهج المعقول هو:

• Invoke شيء خاص به ، يمتلك هوية جديدة / "علامة تجارية" ، يستخدم invoke ثنائي ، يبحث عن وحدة tasks ، إلخ.
  
  
  
  • هذا نظيف ومباشر من الناحية المفاهيمية للمستخدمين الذين يستخدمون Invoke فقط وليس Fabric ، ويزيل الأمتعة التاريخية ، وما إلى ذلك
  
  
• يؤدي الاستدعاء إلى الكشف عن أي رمز مشترك قد يرغب Fabric (أو أدوات أخرى) في استخدامه كواجهات برمجة تطبيقات عامة
• يواصل Fabric استخدام fab ويبحث عن وحدة fabfile ، أثناء إضافة تبعية وقت التثبيت على Invoke ، ويستخدم Invoke's APIs لاستدعاء هذا الرمز المشترك
  
  
  
  • هذا يعني أن تثبيت Fabric ينتج عنه ثنائيتان ، ولكن من منظور المستخدمين الذين يركزون على Fabric ، فهم لا يحتاجون إلى _ معرفة أن invoke / tasks موجودة / خيارات ، لأنهم ' d لا تستخدمها أبدًا - لا يزال fab مجموعة شاملة من الوظائف.
  
  
  • المستخدمون الذين يرغبون في استخدام كل من Invoke لمصلحتهم (على سبيل المثال في المشاريع الأخرى التي لا تحتوي على ملفات Fabfiles) _ و_ النسيج هما النقطة الشائكة ، فيما يتعلق: كيف يرتبط invoke و fabric ببعضهم البعض ويتصرفون . قد يكون لدى هؤلاء الأشخاص بعض الاهتمام بـ invoke و fab كونهم أسماء مستعارة بسيطة لبعضهم البعض (على سبيل المثال ، وجود تثبيت Fabric يغير كيف يتصرف invoke ، مثل كيفية عمل مكونات Nose الإضافية.)
  
  
  • ومع ذلك ، أعتقد أنه من الأفضل جعل الاثنين يتصرفان بشكل مختلف - fab _ يجب_ التمييز _ على الأقل_ في "ما اسم وحدة المهمة التي أبحث عنها؟" المعنى ، عند هذه النقطة قد يكون لدينا أيضًا مخلوقه الخاص ، والعلاقة بين Fabric و Invoke هي فقط في كيفية استخدام Fabric لقاعدة بيانات Invoke.
  
  

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

يحتوي Invoke على إصدار تجريبي الآن (بعد الكثير من العمل الذي تم إجراؤه مؤخرًا). موجودة مسبقا:

• أفضل ، وأكثر وضوحا ولكن لا تزال مسافات أسماء النطاقات شبه معدومة
• محلل علامات CLI "الحقيقي" ، ليس أكثر من foo:bar,lol ، بما في ذلك الترجمة التلقائية للوظيفة argspec إلى مواصفات CLI
• تمت محاولة تصميم وحدات بت لتنفيذ المهام بحيث تكون قابلة للتوسيع / ​​قابلة للتجاوز لإعادة: الموازاة
• تم القيام به لدعم: المهام التمهيدية (حدد المهام التي سيتم تشغيلها قبل المهام الأخرى)
• عداء مهام محلي قادر run الالتقاط والطباعة
• قد ننسى بتات زوجين أخرى؟

اركض عليه على أمل البدء في وضع نماذج أولية لكيفية تثبيت Fab 2 عليه ، هذا الأسبوع.

تأكد من النظافة
ضمان بني
"ضمان" "الحالة"

ما هي حالة القماش 2؟ هل هناك شوكة في الخارج تغطي هذا؟ أعني الأشياء التي يجب أن تغطيها fabric2 والتي لا يتم استدعاءها.

mvaled سيظهر قريبًا ، لقد كان في فرع خاص "نظيف" من إعادة شراء النسيج.

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

شكرا لكل العمل الرائع على الدعوى والنسيج!

@ dmr أنا في منتصف الحصول على Fabric 2 يعمل على Invoke. مجموعة من الميزات التي سيتم نقلها من Fabric 1 ستعلم قرارات التصميم لـ Invoke (للميزات الجديدة أو الميزات الحالية - على سبيل المثال ، كان إصلاح التكوين الأخير أحد هذه الميزات) ، لذلك لا أريد تسمية Invoke 1.0 حتى يتم " تم اختبار المعركة "بما فيه الكفاية.

خطتي هي أن يكون لديك alpha of Fabric 2 جاهزًا للجمهور بواسطة PyCon على أبعد تقدير (من الناحية المثالية في وقت أقرب بكثير) وهذا سيؤدي إلى Fabric 2.0 + Invoke 1.0.

شكرا للتوضيح ، أين يمكنني المساعدة؟

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

لقد بدأت بالتبديل للاستدعاء مع أوامر shell وبعض Paramiko لأن النسيج هو الحزمة الأخيرة بدون دعم python3 في مشروعي

هل تم إصدار أي ETA لـ Fabric 2.0 و Invoke 1.0 حيث تم إصدار Python 3.5 أمس وهل سيكون الخيار الافتراضي في Ubuntu 16.04 LTS؟