Fabric: गैर-एसएसएच-निर्भर सुविधाओं को अलग lib . में विभाजित करें

:केक:

एक पूरी तरह से नया उपकरण जो उपयोग के मामले में अच्छी तरह फिट होगा, निश्चित रूप से हमेशा एक विकल्प भी होता है।

अद्यतन विवरण एक गुच्छा।

@kennethreitz : यह वास्तव में फैब्रिक के उस आधे हिस्से की मौजूदा जरूरतों/फीचर सेट के आधार पर एक नई "चीज" होगी। विचार यह है कि इसकी अपनी इकाई पुन: स्थापना, विकास कार्यक्रम इत्यादि हो, लेकिन फिर भी फैब्रिक देव/समुदाय द्वारा नियंत्रित किया जाता है।

विचार:

• टोनी - जैसा कि टोनी मास्टर्स उर्फ ​​द टास्कमास्टर (कॉमिक बुक्स ~)
• सीईओ - चीजें चलाता है, (या सीज़र या उस तर्ज पर कुछ इसी तरह)

क्षमा करें, मैं नामों को चूसता हूँ :(

इसके अलावा "किर्क" (कप्तान किर्क के रूप में) जैसी चीजें।

मैंने कुछ ऐसे कपड़े के बारे में सोचने की कोशिश की जो चल रहे कार्यों के साथ करना है, लेकिन मैं उस एक के बारे में नहीं सोच सकता जो कार्यों + कपड़े से जुड़ा हो।

लेकिन लूम कोई बुरा नाम नहीं है और न ही मुझे लगता है।

प्रारंभिक नाम मंथन।

अवधारणाओं

• दौड़ना/जॉगिंग/आदि
• निष्पादन (आदेशों का, लोग शायद हालांकि यह थोड़ा मैकाब्रे है, आदि)
• कार्य (जैसे-करने के काम, काम आदि)
• हो सकता है कि # 461 से कुछ अस्वीकृत या इसी तरह के नाम, जहां तक ​​कपड़े से चीजों को बुनाई या एक साथ रखने का विचार भी कार्यों पर लागू होता है

पीपीपीआई पर नाम नहीं लिए गए

• runner
• executor
• go
  
  
  
  • प्रोग्रामिंग भाषा और/या बोर्ड गेम के साथ भ्रम, विशेष रूप से यदि पूर्व में एक बाइनरी है जिसे विशेष रूप से go कहा जाता है
  
  
  • बेहतर या बदतर के लिए, कई संभावित मूर्खतापूर्ण कार्य नाम हैं जैसे away या fuck_yourself या bother_somebody_else
  
  
• weaver

बाइनरी नाम

धन्यवाद, ऑक्सफ़ोर्ड अमेरिकन राइटर का थिसॉरस जैसा कि OS X के डिक्शनरी एप्लिकेशन द्वारा प्रस्तुत किया गया है!

• run
• execute
• go
  
  
  
  • ऊपर देखो
  
  
• create (जैसे make )
• fabricate (बहुत लंबा, बहुत आसानी से भ्रमित होने वाला fab )
• fab (अर्थात इस नए lib को अलग नाम दिया गया है लेकिन फिर भी fab बाइनरी स्थापित कर रहा है; यदि दोनों सिस्टम पर मौजूद हैं तो फैब्रिक एक प्राथमिकता लेता है? एक गूंगा विचार की तरह लगता है।)
• generate
• produce
• fashion (मेह)
• build
• devise
• shape
• setup
• weave

आज टॉप ब्रेनस्टॉर्मिंग फॉर्म में नहीं है। मोर चाहते हैं।

@dstufft लूम का एक ठीक नाम है, और सीईओ एक अधिकतर ठीक अवधारणा है (कॉमिक बुक संदर्भ का एक बड़ा प्रशंसक नहीं है, अगर केवल इसलिए कि यह अस्पष्ट लगता है, मैंने चरित्र के बारे में कभी नहीं सुना;))। मुख्य समस्या एक अच्छे बाइनरी नाम के साथ आ रही है, मुझे लगता है कि एक क्रिया अच्छी तरह से काम करने के लिए बहुत जरूरी है। सुनिश्चित नहीं है कि उनमें से किसी के लिए क्या काम करेगा।

बॉस: चीजें चलाता है।

हिस्सा लेना किंडा मेक की तरह है, लेकिन पायथन के लिए।

कार्यकारी।

मुझे इसका विचार कार्यों के इर्द-गिर्द उन्मुख करना पसंद है। हम्म..

@kennethreitz मुझे बॉस पसंद है, न्यू जर्सी के एक निश्चित मूल निवासी के साथ संभावित भ्रम के अलावा (क्षमा करें, सिर्फ एक प्रशंसक नहीं, कॉलेज में खराब रूममेट अनुभव)

जैसा कि मैंने @dstufft से कहा, बाइनरी नाम निश्चित रूप से यहां महत्वपूर्ण हैं, इसलिए यदि आप कर सकते हैं, तो कृपया उन्हें भी ध्यान में रखने का प्रयास करें। यदि प्रोजेक्ट-नाम-ए-बाइनरी थोड़े गूंगा लगता है तो एक महान प्रोजेक्ट नाम मदद नहीं करता है;)

नौकरानी दिलचस्प है। आपके लिए आपके कार्यों को करता है। "मेक" के समान।

बटलर भी। हम एक यादृच्छिक ब्रिटिश-लगने वाला बटलर नाम चुन सकते हैं।

maid clean , maid release , maid test । मुझें यह पसंद है।

मेरे (असीम, स्वाभाविक रूप से) मर्दानगी पर थोपने के अलावा, maid बहुत अच्छा है, भले ही यह क्रिया पैटर्न में फिट न हो। (यानी यह बेहतर गैर-क्रिया बाइनरी नामों में से एक है।) (संपादित करें: और बटलर क्या करते हैं _do_? बटल?)

मैंने बस नाम ठुकरा दिया, बस मामले में। मुझे यह अब तक बहुत पसंद है।

एक पुस्तकालय नाम के रूप में बॉस पहले ही FWIW लिया जा चुका है

मंगलवार, 21 फरवरी, 2012 को रात 8:38 बजे, जेफ फोर्सियर ने लिखा:

मेरे (असीम, स्वाभाविक रूप से) मर्दानगी पर थोपने के अलावा, maid बहुत अच्छा है, भले ही यह क्रिया पैटर्न में फिट न हो। (यानी यह बेहतर गैर-क्रिया बाइनरी नामों में से एक है।)

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

intern भी एक अविश्वसनीय रूप से बढ़िया विकल्प है।

@dstufft तो यह है, और मैं इसके लिए एक अच्छा बाइनरी नाम नहीं सोच सका, boss docs वास्तव में अच्छी तरह से फिट नहीं है।

@kennethreitz ने आईआरसी पर bake उल्लेख किया है, जो मेक/रेक थीम में फिट बैठता है, और एक आह्वान क्रिया के रूप में भी फिट बैठता है (उदाहरण के लिए $ bake docs , हालांकि विषयगत रूप से यह थोड़ा दूर है, ऐसा लगता है' डी शेफ या कुछ और में बेहतर फिट।

संपादित करें: deliver भी। इस पर मेरी प्रारंभिक प्रतिक्रिया कुछ सकारात्मक थी ( $ deliver build $ deliver docs ) लेकिन इसके साथ जाने के लिए कोई _great_ प्रोजेक्ट नाम नहीं है जो थोड़ा बहुत मूर्खतापूर्ण नहीं है, और यह थोड़ा लंबा है।

$ invoke taskname (परियोजना के नाम: invoker , invoked , ???)

आह्वान किया।

मुझे वास्तव में Invoked और invoke docs invoke tests invoke publish आदि पसंद हैं।

परियोजना का नाम सिर्फ "आमंत्रण" भी हो सकता है, क्या बाइनरी और परियोजना को अलग-अलग नामों की आवश्यकता है?

मुझे लगता है कि 'आह्वान' में 'आह्वान' की तुलना में थोड़ा अधिक पिज्जाज़ है, लेकिन कोई भी काम कर सकता है।

नाम का अलग होना जरूरी नहीं है, नहीं, यह सिर्फ इतना है कि कई बार यह अधिक समझ में आता है।

ट्रेन में चलते समय मेरे मन में एक विचार आया (अब उक्त ट्रेन में :P go go Smartphone tethering!) जो यह है कि हम _संभवतः यह सब छोड़ सकते हैं और बस पूरे fab + fabfile.py साइड को स्थानांतरित कर सकते हैं इस "नई" लाइब्रेरी की चीज़ें (और इसे कॉल करें, कहें, fabricator )।

दूसरे शब्दों में, स्टैंडअलोन लिब के लिए एक कॉल करने योग्य और एसएसएच-उपयोग सेटअप के लिए एक अलग होना जरूरी नहीं है, और यहां तक ​​​​कि एक नुकसान भी हो सकता है।

प्लसस:

• नए बाइनरी नाम की आवश्यकता नहीं है
• वैसे भी दो बाइनरी नामों का होना भ्रमित करने वाला होगा
• यदि नया lib _didn't_ "fabfiles" का उपयोग करता है, तो हमारे पास दो अलग-अलग "कार्य फ़ाइल" प्रकार भी होंगे, फिर से भ्रमित/अतिरिक्त कोड/आदि

माइनस:

• समान नामों के कारण दो परियोजनाओं के बीच संभावित भ्रम
• सभी फैब्रिक-आइम्स (जैसे लगभग सभी सीएलआई झंडे, आदि) को काम करना जारी रखने के लिए नई परियोजना को अतिरिक्त एक्स्टेंसिबल होना होगा-
  
  
  
  • यानी pip install fabricator हमें fab देता है, जिसमें झंडे के कुछ छोटे सेट होंगे
  
  
  • फिर यदि आप pip install fabric , तो अचानक उसी fab को सभी अतिरिक्त फैब्रिक सीएलआई झंडे प्रदर्शित करने होंगे, यदि अन्य चीजें भी नहीं हैं
  
  
  • ओटीओएच यह "क्लाइंट" कोड को सीएलआई पार्सिंग का विस्तार करने की इजाजत देने जैसा नहीं है, यह एक _bad_ चीज है, यह केवल और काम है जिसे सामने किया जाना है।
  
  

आपके पास एक कमांड लाइन क्लाइंट एक्स्टेंसिबल बन सकता है। देखें कि कैसे नाक अपने कमांड लाइन टूल से प्लगइन एंट्रीपॉइंट को व्यक्त करने की अनुमति देता है

मुझे लगता है कि अतिरिक्त एक्स्टेंसिबिलिटी एक अच्छी बात होगी चाहे वह किसी भी तरह से जाए।

मुझे लगता है कि नाम भ्रम एक मुद्दा होगा।

यह एक निजी बात है लेकिन मुझे invoke test invoke docs से बेहतर fab test का लुक पसंद है।

जहां तक ​​​​अलग-अलग बायनेरिज़ जाते हैं, मैं सिर्फ यह सुनिश्चित करूंगा कि कोर बाइनरी (इनवोक) सभी फैब्रिक चीजों को होने की अनुमति देने के लिए एक्स्टेंसिबल है, और फिर फैब को उसी एंट्री पॉइंट को इनवोक के रूप में कॉल करें (यानी वास्तविक फैब/इनवोक बायनेरिज़ main() (या जो कुछ भी) के अल्ट्रा न्यूनतर कॉलर्स होंगे।

मुझे लगता है कि अगर आप इनवोक + फैब्रिक रूट पर जाते हैं जो कि 2.0 से पहले फैबफाइल्स और "इनवोकफाइल्स" दोनों हैं? समर्थित होगा, और फिर 2.0 के साथ बस फाइलों को आमंत्रित करें?

तो अनिवार्य रूप से मैं इसे अलग "टास्क रनर" और "रिमोट/एसएसएच स्टफ" में विभाजित करने के लिए +1 हूं, 1.x के लिए कॉम्पेट शिम में डाल रहा हूं, और 2.x के लिए सामान को बहिष्कृत कर रहा हूं। मुझे लगता है कि यह विभाजन दोनों libs को बेहतर बना देगा, कार्य धावक कुछ वाकई अच्छी एक्स्टेंसिबिलिटी का समर्थन करेगा (और शायद बाहरी कार्य जिन्हें आसानी से निर्भर किया जा सकता है, दौड़ा आदि)। और रिमोट/एसएसएच सामान को जिम्मेदारियों का एक छोटा सेट होने से लाभ होगा जिससे इसे और अधिक केंद्रित किया जा सके/

मेरे सेंट वैसे भी।

मुझे स्पष्ट करना चाहिए कि मैं दूसरे तरीके से नफरत नहीं करता, मुझे खुशी है कि यह चर्चा बिल्कुल हो रही है :)

@dstufft विचारों के लिए बहुत बहुत धन्यवाद, मैं उस सब से काफी सहमत हूं। आप बायनेरिज़ के बारे में सिर्फ स्टब्स होने के बारे में सही हैं, इस तरह फैब्रिक अब काम करता है, मेरी चिंता पूरी तरह से व्यवहार और उपयोगकर्ता भ्रम के बारे में है।

@dcolish मेरा मतलब यह नहीं था कि सीएलआई एक्सटेंशन करना संभव नहीं है, और नाक निश्चित रूप से जांच करने के लिए एक अच्छी पूर्व कला है।

अगर हम "आह्वान" के साथ जाते हैं, तो शायद फ़ाइल नाम invocations(.py) हो सकता है? मूर्खतापूर्ण/थीमपार्क पक्ष पर एक स्पर्श, लेकिन यह व्याकरणिक रूप से फिट बैठता है, और invokefile.py मुझे थोड़ा अजीब लगता है। या संभवतः रेक सम्मेलन मार्ग पर जाएं और केवल tasks(.py) का उपयोग करें।

आंशिक रूप से संबंधित, मुझे लगता है कि हमें निश्चित रूप से आगे बढ़ने वाले मॉड्यूल/फ़ोल्डर पहलू पर ध्यान देना चाहिए। चूंकि यह जस्ट पायथन है या तो अभी भी समर्थित होगा, लेकिन ट्यूटोरियल सामग्री और डॉक्स के संदर्भ में, invocations/__init__.py डिफ़ॉल्ट होना एक अच्छी बात हो सकती है।

मुझे tasks.py पसंद है। invocations.py टाइप करने के लिए अजीब है।

वैसे ऐसा नहीं है कि आपको इसे बहुत बार टाइप करना होगा, है ना? ;) लेकिन हाँ, tasks/ या tasks.py विश्व स्तर पर कुछ अधिक स्पष्ट है।

टास्कफाइल.py

आप invoke कार्य (.py|/), शब्दांकन वैसे भी अच्छा है :)

हां, "ये tasks हैं, जिसे आप invoke " सेटअप बहुत अच्छी तरह से काम करते हैं, यह कैसे काम करता है, इसके अंग्रेजी विवरण के साथ कीवर्ड को बांधने के दृष्टिकोण से। यह स्पष्ट है, कोई तामझाम नहीं, कोई दंभ नहीं, आदि।

@kennethreitz मैंने कभी भी नामकरण सम्मेलन के रूप में XYZFile का एक बड़ा प्रशंसक नहीं किया है, और विशेष रूप से इन दिनों से यह अक्सर _not_ एक फ़ाइल है, मुझे फैब 1.x के बाहर सम्मेलन जारी रखने की कोई आवश्यकता नहीं है :)

मैं ऐसा होते देखना पूरी तरह से पसंद करूंगा। मैंने हमेशा फैब्रिक को एक प्रोजेक्ट के लिए "कार्यों" को स्टोर करने के लिए एक सामान्य पाइथोनिक तरीके के रूप में देखा है, चाहे वे स्थानीय या रिमोट आधारित हों, रेक/मेक के करीब कुछ। हालाँकि, जब नए लोगों से परिचय करने की कोशिश की गई, तो कई लोग इस दृष्टिकोण से भ्रमित थे और इसे केवल एक परिनियोजन उपकरण के रूप में देखा।

मैं मॉड्यूल/फ़ोल्डर पहलू को दूसरे स्थान पर रखूंगा, ताकि ड्रॉप-इन सक्षम सामान्य कार्यों को आसान बनाया जा सके। नई शैली के कार्य निश्चित रूप से उस ओर एक अच्छा रास्ता तय करते हैं।

@askedrelic हाँ, यह दो-एक-एक होना हमेशा दुर्भाग्य से थोड़ा भ्रमित करने वाला रहा है।

असंबंधित: मैं इस सूत्र पर @tswicegood को समन करता हूं क्योंकि वह और मैं कुछ सप्ताह पहले इस मुद्दे पर चर्चा कर रहे थे और मुझे लगता है कि वह इसमें शामिल होना चाहते हैं। हमेशा की तरह मैं असहमत होने का अधिकार सुरक्षित रखता हूं;)

मुझे बुलाया गया था? :-)

मुझे $#$1 fabfile #$ के बजाय मॉड्यूल के रूप में tasks पर जाने का विचार पसंद है। अधिक समझ में आता है और छोटा होता है। मैं, एक के लिए, आर्मस्ट्रांग के अंदर fab test चलाने में सक्षम होने के लिए पूर्ण डिपो स्टैक स्थापित करने से नफरत करता हूं, इसलिए कुछ भी जो निकालने के लिए किया जा सकता है कि मैं एक बड़ा प्लस वन हूं।

जहां तक ​​​​नामकरण है, बाहरी निष्पादन योग्य होने से स्थानांतरित करने के बारे में क्या है जो लोगों को इसे नीचे से जोड़ने के लिए स्थापित किया गया है:

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

तो आप बस पायथन का उपयोग करें। मैं निष्पादन योग्य के साथ ठीक हूं, बस यह नहीं पता कि यह आवश्यक है या नहीं।

एफडब्ल्यूआईडब्ल्यू, मैंने कुछ हफ्ते पहले flunky नामक पैकेज निर्माण को संभालने के लिए एक परियोजना शुरू की थी। उस परिचर विषय के साथ चिपके हुए, footman या lacky दोनों उपलब्ध हैं (बाद में lackie - एक रूबी परियोजना के साथ संघर्ष है)। दूसरा शुक्रवार होगा, जैसा कि लड़की/पुरुष शुक्रवार में होता है। यह गिटहब/पीईपीआई/होमब्रू परीक्षण पास करता है जिसमें इसका नाम कुछ भी नहीं है। दरअसल, अब जब मैं इसके बारे में सोचता हूं तो यह मेरी पहली पसंद होगी।

साइड बेट, मुझे आश्चर्य है कि जब तक @niran ने एक पीआर प्रस्तुत नहीं किया, तब तक यह स्पष्ट, यद्यपि भयानक थीम गीत को शामिल करने के लिए README को अपडेट कर रहा था।

मुझे लगता है कि एक ऑन-योर- $PATH "बाइनरी" (esp। यह देखते हुए कि यह वर्तमान में _not_ एक वास्तविक बाइनरी है, लेकिन सिर्फ एक सेटपूल-निर्मित स्टब है जो कॉल करता है (invoked|fabric).main() ) सबसे उपयोगकर्ता के अनुकूल है , और मुझे उस स्टब की सामग्री को कार्य मॉड्यूल के अंदर स्वत: उत्पन्न करने के लिए स्थानांतरित करने के लिए कोई लाभ नहीं दिख रहा है (और वास्तव में इसमें कई डाउनसाइड्स देखें।)

और हां, इसका पूरा बिंदु एक ऐसे काम के साथ समाप्त होना है जो आपको बिना किसी एसएसएच/नेटवर्क/क्रिप्टो डिप्स की आवश्यकता के कार्यपूर्ण सामान प्राप्त करने देता है :)

मैं निष्पादन योग्य पर @bitpropet से पूरी तरह सहमत हूं। इससे दौड़ने में आसानी होती है। अगर कोई अपनी निजी परियोजना पर invoke / fab के अलावा कुछ और उपयोग करना चाहता है तो यह सिर्फ एक आधार है जिससे आप आसानी से अपना खुद का बाइनरी बना सकते हैं (और यह आसानी से finalname.__main__.main पर रह सकता है , इस मामले में आप भी केवल python -m finalname यदि आप चाहें तो भी कर सकते हैं।

+1।

बस एक विचार वहाँ फेंक रहा हूँ, मुझे लगता है कि यह अधिक सुविधाजनक भी है। एफडब्ल्यूआईडब्ल्यू, यदि आप इसका उपयोग करना चाहते हैं तो मैंने शुक्रवार को पीईपीआई पर पंजीकरण कराया।

@bitpropet क्षमा करें, मुझे लगा कि आप प्रवेश बिंदुओं का उपयोग करने के बारे में जानते हैं। मैं अपने तरीके से, नाक के समान एक फैशन में फ्रंटएंड करने और नाम को फैब रखने के लिए मतदान कर रहा था।

विचार महान हैं, मुझे विचार पसंद हैं :)

शुक्रवार का दिन थोड़ा बहुत प्यारा है, हालांकि मुझे पॉप संस्कृति संदर्भ पसंद है। वह गाना बहुत बढ़िया है! :ट्रॉल फ़ेस:

मुझे लगता है कि अभी के लिए मैं पैकेज/प्रोजेक्ट, और बाइनरी, नाम दोनों के रूप में सीधे invoke के साथ जा रहा हूं। योइंक! Invoker या Invoked पूर्व के लिए अन्य संभावनाएं थीं (यानी अभी भी invoke बाइनरी के साथ) लेकिन मैं सीधा मार्ग नहीं जाने के किसी भी अच्छे कारण के बारे में नहीं सोच सका।

इस नाम का मुख्य पहलू सामान्यता है, लेकिन यह हर उस परियोजना के साथ एक समस्या है जिसे मैंने कभी लिया है या बनाया है, और इस मामले में अधिक विशिष्ट विकल्पों में से कोई भी मुझे सही नहीं लगा। /औचित्य

@dcolish ने स्वीकार किया, धन्यवाद!

मैंने अभी तक कोई अंतिम निर्णय नहीं लिया है, लेकिन मुझे लगता है कि इस समय समझदार दृष्टिकोण यह है:

• Invoke अपनी ही चीज़ है, अपनी नई पहचान/"ब्रांड", invoke बाइनरी का उपयोग करता है, tasks मॉड्यूल की तलाश करता है, आदि।
  
  
  
  • यह केवल इनवोक का उपयोग करने वाले उपयोगकर्ताओं के लिए साफ, सीधा अवधारणात्मक है, न कि फैब्रिक का, ऐतिहासिक सामान को हटाता है, आदि
  
  
• Invoke किसी भी साझा कोड को उजागर करता है जिसे फैब्रिक (या अन्य उपकरण) सार्वजनिक एपीआई के रूप में उपयोग करना चाहते हैं
• फैब्रिक fab का उपयोग करना जारी रखता है और fabfile मॉड्यूल की तलाश करता है, जबकि इनवोक पर इंस्टॉल-टाइम निर्भरता जोड़ता है, और उस साझा कोड को कॉल करने के लिए इनवोक के एपीआई का उपयोग करता है
  
  
  
  • इसका मतलब यह है कि फैब्रिक को दो बायनेरिज़ में स्थापित करना, लेकिन फैब्रिक पर ध्यान केंद्रित करने वाले उपयोगकर्ताओं के दृष्टिकोण से, उन्हें यह जानने की आवश्यकता नहीं है कि invoke / tasks मौजूद हैं/विकल्प हैं, क्योंकि वे' d कभी उनका उपयोग नहीं कर रहे हैं -- fab अभी भी कार्यक्षमता का एक सुपरसेट है।
  
  
  • जो उपयोगकर्ता अपने स्वयं के लिए इनवोक दोनों का उपयोग करना चाहते हैं (उदाहरण के लिए अन्य परियोजनाओं में जिनमें कोई फैबफाइल नहीं है) _और_ फैब्रिक स्टिकिंग पॉइंट हैं, पुन: कैसे invoke और fabric एक दूसरे से संबंधित हैं और व्यवहार करते हैं . इन लोगों को invoke और fab में एक-दूसरे के साधारण उपनाम होने में कुछ रुचि हो सकती है (यानी फैब्रिक के इंस्टॉल होने से invoke कैसे व्यवहार करता है, जैसे नाक प्लगइन्स कैसे काम करते हैं।)
  
  
  • हालांकि, मुझे लगता है कि दोनों का अलग-अलग व्यवहार करना सबसे अच्छा है - fab _must_ अंतर _at कम से कम_ में "मैं किस कार्य मॉड्यूल की तलाश कर रहा हूं?" अर्थ, किस बिंदु पर हम इसका अपना प्राणी भी हो सकते हैं, और फैब्रिक और इनवोक के बीच का संबंध केवल इस बात में है कि फैब्रिक इनवोक के कोडबेस का उपयोग कैसे करता है।
  
  

संपादित करें: मुझे कुछ भी अंतिम बनाने से पहले _how_ पर एक नज़र डालनी चाहिए, यह जल्दी से काम करेगा। अभ्यास बनाम सिद्धांत और वह सब। कोणों में भाग सकता हूँ मैं यहाँ के बारे में नहीं सोच रहा हूँ।

इनवोक में अब बीटा रिलीज है (हाल ही में इसे बनाने के बहुत सारे काम के बाद)। पहले से मौजूद:

• बेहतर, अधिक स्पष्ट लेकिन फिर भी लगभग शून्य-बॉयलरप्लेट नेमस्पेसिंग
• "रियल" सीएलआई फ्लैग पार्सर, अब और नहीं foo:bar,lol , जिसमें सीएलआई स्पेक में फ़ंक्शन argspec का ऑटो अनुवाद शामिल है
• कार्य निष्पादन बिट्स को एक्स्टेंसिबल/ओवरराइड करने योग्य पुन: डिज़ाइन करने का प्रयास किया गया: समांतरता
• जो समर्थन के लिए किया गया था: पूर्व-कार्य (अन्य कार्यों से पहले चलने वाले कार्यों को इंगित करें)
• कैप्चर-एंड-प्रिंट सक्षम स्थानीय कार्य धावक run (यद्यपि शायद विंडोज़ पर कार्यात्मक नहीं है)
• हो सकता है कि एक और जोड़ी बिट्स भूल रहे हों?

इस पर दौड़ना और प्रोटोटाइप शुरू करने की उम्मीद करना कि इस सप्ताह फैब 2 इस पर कैसे बोल्ट लगाएगा।

स्वच्छ सुनिश्चित करें
सुनिश्चित निर्माण
"सुनिश्चित करें" "राज्य"

फैब्रिक 2 की क्या स्थिति है? क्या वहां कोई कांटा है जो इसे ढक रहा है? मेरा मतलब है कि वह सामान जो फैब्रिक 2 को कवर करना चाहिए जो कि आह्वान नहीं है।

@mvaled यह जल्द ही दिखाई देगा, कपड़े रेपो की एक निजी 'साफ' शाखा में रहा है।

क्षमा करें यदि यह विषय से हटकर है लेकिन मुझे फिर से पूछना है:
मुझे फैब्रिक 2 कहां मिल सकता है?
मुझे वास्तव में आह्वान पसंद है और यह एक बड़े सुधार की तरह लगता है, लेकिन एक आह्वान 1.0 रिलीज के लिए क्या गुम है? (कपड़े 2 के आधार के रूप में वर्णित)

इनवोक और फैब्रिक पर सभी महान कार्यों के लिए धन्यवाद!

@dmr मैं इनवोक के शीर्ष पर फैब्रिक 2 काम करने के बीच में हूं। फैब्रिक 1 से पोर्ट की जाने वाली सुविधाओं का एक गुच्छा इनवोक के लिए डिज़ाइन निर्णयों को सूचित करेगा (नई सुविधाओं या मौजूदा लोगों के लिए - उदाहरण के लिए हालिया कॉन्फ़िगरेशन ओवरहाल इनमें से एक था), इसलिए मैं इनवोक 1.0 को तब तक लेबल नहीं करना चाहता जब तक कि यह " लड़ाई का परीक्षण" पर्याप्त रूप से।

मेरी योजना है कि पायकॉन द्वारा जनता के लिए नवीनतम (आदर्श रूप से बहुत जल्द) फैब्रिक 2 का अल्फा तैयार किया जाए और इससे फैब्रिक 2.0 + इनवोक 1.0 हो जाएगा।

स्पष्टीकरण के लिए धन्यवाद, मैं कहां मदद कर सकता हूं?

मैं इस पर अल्पावधि के लिए एक निजी शाखा में काम कर रहा हूं जब तक कि मुझे कुछ ऐसा नहीं मिलता जिससे मैं खुश हूं और प्रतिक्रिया के लिए तैयार होने के बाद ट्विटर/मेलिंग सूची/आदि पर घोषणा करूंगा, इसलिए कृपया बने रहें।

मैंने शेल कमांड और कुछ पैरामीको के संयोजन में इनवोक करने के लिए स्विच करना शुरू कर दिया क्योंकि फैब्रिक मेरी परियोजना में python3 समर्थन के बिना अंतिम पैकेज है

फैब्रिक 2.0 के लिए कोई ईटीए और 1.0 को आमंत्रित करें क्योंकि पायथन 3.5 कल जारी किया गया था और उबंटू 16.04 एलटीएस में डिफ़ॉल्ट होगा?