Servo: किसी भी सपोर्ट क्रेट को साफ-सुथरा या लाइसेंस-चेक नहीं किया जा रहा है

प्लेटफ़ॉर्म निर्देशिका में एक समान समस्या है

अनदेखी फाइलों की

"हमारे" कोड का एक गुच्छा (जिसे https://github.com/servo/ के तहत गैर-कांटे के रूप में परिभाषित किया जा सकता है) अलग-अलग भंडारों में है और कार्गो के माध्यम से उपयोग किया जाता है, और इसलिए tidy.py लिए दृश्यमान नहीं है। तो यह नहीं किया गया है, और अब पहले की तुलना में हमने कार्गो पर स्विच किया और सब कुछ एक सबमॉड्यूल था।

क्या हम प्रत्येक रेपो में एक अलग कॉन्फ़िगरेशन के साथ साफ-सुथरा नहीं रख सकते हैं? वे रेपो सभी सीआई सिस्टम में होने चाहिए, ताकि एक ही लक्ष्य को प्राप्त किया जा सके।

प्रत्येक रेपो का अपना अलग सीआई होता है जिसमें tidy.py की एक प्रति हो सकती है, लेकिन इसका मतलब है कि जब हम कुछ जोड़ना चाहते हैं तो अपडेट करने के लिए कई प्रतियां।

एक सबमॉड्यूल में व्यवस्थित करें? इसे डाउनलोड करें और इसे CI के दौरान चलाएं? उस समस्या को कम करने के लिए कुछ उपाय हैं।

विचार करने का एक विकल्प: tidy को PyPi में servo_tidy रूप में अपलोड करना और जब भी हम साफ करना चाहते हैं तो नवीनतम संस्करण डाउनलोड करें

संपादित करें: जैक ने मुझे हरा दिया

@frewsxcv लेकिन मुझे कोरी के सुझाव का अधिक ठोस संस्करण सबसे अच्छा लगता है।

ठीक है। मैंने इस बारे में थोड़ा सोचा है और सोचता हूं कि मैं चुनौती के लिए तैयार हूं। मैं कुछ भी लागू करने से पहले अपने विचारों के साथ रिपोर्ट करूंगा; मैं इसके साथ #6999 एक साथ ठीक करने में सक्षम हो सकता हूं।

कुछ सोचने के बाद, मैं यहाँ प्रस्तावित करता हूँ:

1. आभासी वातावरण (ब्लीह?) किसी भी mach कमांड को चलाने पर, पायथन एक आभासी वातावरण (जो कहीं .pyenv/ या python/.pyenv/ ) बना/सक्रिय करेगा। फिर हम python/requirements.txt फ़ाइल के अनुसार अपनी निर्भरता को स्थापित/अपडेट करेंगे)। यह हमें अपने पेड़ से निम्नलिखित को हटाने और उन्हें PyPi आवश्यकताओं के रूप में जोड़ने की अनुमति देगा:
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

इससे #6999 भी ठीक हो जाएगा। इस पर निर्भर करते हुए कि क्या बिल्डर्स प्रत्येक निर्माण के बाद कार्यशील निर्देशिका को उड़ा देते हैं, हमें पाइथन वर्चुअलएन्व निर्दिष्ट करने के लिए किसी प्रकार का कैशिंग विकल्प या मच पैरामीटर जोड़ने की आवश्यकता हो सकती है।

1. पैकेज tidy.py । इसका मतलब सिर्फ python/tidy/tidy.py और python/tidy/setup.py ।
2. अन्य रेपो में tidy.py । ऐसा करने के कुछ तरीके हैं:
   
   
   
   1. इसे PyPi पर रिलीज़ करें। जब तक हम पाइथन पैकेज को बदलने पर स्वचालित रूप से प्रकाशित करने के लिए एक प्रणाली नहीं बनाते, इसे जारी करना एक दर्द हो सकता है।
   
   
   2. अन्य सभी भंडार बस करें:
   
   

pip install -e git+https://github.com/servo/servo.git#egg=servo_tidy&subdirectory=python/tidy

मुझे बताएं कि क्या किसी के पास कोई अन्य विचार या विचार है

वेब-प्लेटफ़ॉर्म-परीक्षणों के लिए हमारे पास पहले से ही वर्चुअलएन्व है, शायद इसका उपयोग इसके लिए भी किया जा सकता है।

वेब-प्लेटफ़ॉर्म-परीक्षणों के लिए हमारे पास पहले से ही वर्चुअलएन्व है, शायद इसका उपयोग इसके लिए भी किया जा सकता है।

अच्छा विचार। मैं यह सुझाव देने वाला था कि हम पेड़ से tests/wpt/harness (wptrunner) को भी हटा दें (और इसे एक पाइप निर्भरता बना दें), लेकिन ऐसा लगता है कि आपने हमारी कॉपी-इन-ट्री में कुछ संपादन किए हैं: पी

उसके लिए अपस्ट्रीम https://github.com/w3c/wptrunner है , और हमारी कॉपी में किए गए बदलाव अपस्ट्रीम किए जाने वाले हैं। मुझे नहीं पता कि यह एक सबमॉड्यूल क्यों नहीं है या पीईपीआई से स्थापित नहीं है। लेकिन यह थोड़े विषय से हटकर है, बेझिझक एक और मुद्दा खोलें।

मैं tests/wpt/_virtualenv (जो तब बनता है जब आप ./mach test-wpt चलाते हैं) के बारे में सोच रहा था, न कि tests/wpt/harness ।

इसके अलावा अगर वह _virtualenv अधिक कर्तव्यों (जो ठीक है) करने जा रहा है, तो शायद इसे पेड़ से ऊपर ले जाना चाहिए।

मैं परीक्षण/wpt/_virtualenv के बारे में सोच रहा था (जो तब बनाया जाता है जब आप ./mach test-wpt चलाते हैं), परीक्षण/wpt/हार्नेस नहीं।

सही, अच्छा लगता है। एक नया आभासी वातावरण उत्पन्न/सक्रिय करने के लिए पायथन कोड बहुत अधिक नहीं है, इसलिए यदि हम कभी भी भविष्य में WPT आवश्यकताओं और साफ-सुथरी आवश्यकताओं को अलग करना चाहते हैं (असंगतताओं या जो भी हो) तो यह उतना मुश्किल नहीं होना चाहिए।

मैं वर्चुअलएन्व पथ को python/_virtualenv जैसे अधिक सामान्य स्थान पर ले जाने का भी विरोध नहीं कर रहा हूं

और फिर भी, जैक ने मुझे हरा दिया

python/_virtualenv एक अच्छी जगह की तरह लगता है।

मच अब python/_virtualenv का उपयोग करता है, #6999 के संकल्प के लिए धन्यवाद।

पैकेज को प्रकाशित करने का लाभ जहां से यह सर्वो पेड़ में रहता है, यह है कि अगर हम अंततः इसे विभाजित करते हैं तो हमें अन्य सभी रेपो को बदलना नहीं पड़ेगा; दोष यह है कि हमें पीपीआई के लिए क्रेडेंशियल के एक और सेट का प्रबंधन करना होगा और सुनिश्चित करना होगा कि अपेक्षित परिवर्तन आगे बढ़े।

pypi पर प्रकाशित करने के लिए, किसी के पास .pypirc की एक प्रति होगी जो pypi खाते का उपयोगकर्ता नाम और पासवर्ड रखता है, फिर पैकेज को पंजीकृत करने और अपलोड करने के लिए कमांड चलाएँ। यदि इस मामले में "कोई" बिल्डमास्टर होस्ट है, तो हम पैकेज को अपडेट करने की प्रक्रिया को स्वचालित कर सकते हैं।

इसके साथ ही, मैं या तो पीपीआई या प्रत्यक्ष स्थापना के साथ ठीक हूं। पीपीआई अब अधिक काम है, भविष्य में एक अनिश्चित बिंदु पर प्रत्यक्ष स्थापना एक बड़ी परेशानी है, और दोनों को एक पैकेज में साफ-सुथरा बनाने की आवश्यकता होती है।

@shinglyu , क्या आप साफ-सुथरा चलना चाहते हैं और इसे पायथन पैकेज के रूप में स्थापित करना चाहते हैं, या मैं करूंगा?

@edunham : मैं यह कर सकता हूँ। :)

मेरे सहयोगी @askeing को इस मुद्दे में बहुत दिलचस्पी है, इसलिए मैं इसे उन पर छोड़ दूँगा।

हाय @edunham ,
मैं इसे यहां पायथन पैकेज (परीक्षणों के साथ) के रूप में स्थापित करने का प्रयास करता हूं: https://github.com/askeing/servo_tidy

@askeing धन्यवाद! ऐसा लगता है कि आपने ज़्यादातर मेहनत पहले ही कर ली है। मेरा एकमात्र नाइटपिक यह है कि setup() में setup.py में कुछ ऐसा शामिल होना मददगार होगा

entry_points={
        'console_scripts': [
            'servo-tidy=servo_tidy:scan',
        ],
    },

ताकि हम पैकेज स्थापित होने के बाद किसी अन्य प्रोजेक्ट के .travis.yml के स्क्रिप्ट अनुभाग में सीधे servo-tidy आह्वान कर सकें।

@frewsxcv @larsbergstrom @metajack सर्वो ट्री बनाम अपने स्वयं के रेपो में रहने वाले tidy पर आपके क्या विचार हैं? वर्तमान पेड़ से tidy git इतिहास को रखना परियोजना के लिए कितना महत्वपूर्ण है? मैं व्यक्तिगत रूप से जब भी संभव हो इतिहास रखना पसंद करता हूं, लेकिन इस मामले में आवश्यकता से अधिक राय के साथ करना अधिक है।

मेरी ओर से कोई मजबूत वरीयता नहीं। उल्लेखनीय है कि tidy.py कुछ नए योगदानकर्ताओं के लिए एक प्रारंभिक बिंदु प्रतीत होता है, और उस फ़ाइल को एक अलग भंडार में रहने से उन योगदानकर्ताओं की बाधा बढ़ सकती है।

मुझे लगता है कि सबसे महत्वपूर्ण चिंता यह है कि tidy.py को संशोधित करना और यह देखना संभव है कि वे परिवर्तन न्यूनतम संभव मध्यवर्ती चरणों के साथ ./mach test-tidy को कैसे प्रभावित करते हैं।

ओह, उस पीआर में "फिक्स" कहना थोड़ा दूर जा रहा था। क्रेट वास्तव में अभी तक अपने सीआई में इसका उपयोग नहीं कर रहे हैं।

मुझे पूरा यकीन है कि यह अब तक कम हो गया है, या कि अन्य मुद्दों ने इसे हटा दिया है।