Python नियम

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें नाइटली · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

py_binary

नियम का सोर्स देखें 
py_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs, env, exec_compatible_with, exec_properties, features, imports, legacy_create_init, licenses, main, output_licenses, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyc_collection, python_version, restricted_to, srcs_version, stamp, tags, target_compatible_with, testonly, toolchains, visibility)

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
deps

लेबल की सूची; डिफ़ॉल्ट [] है

टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. इस बारे में टिप्पणियां देखें [`deps` एट्रिब्यूट आम तौर पर, rules](https://bazel.build/reference/be/common-definitions#typical-attributes). आम तौर पर, ये `py_library` नियम होते हैं. रनटाइम के दौरान इस्तेमाल की जाने वाली डेटा फ़ाइलों को ही उपलब्ध कराने वाले टारगेट, `डेटा` में शामिल होते हैं एट्रिब्यूट की वैल्यू सबमिट करें.
srcs

लेबल की सूची; ज़रूरी है

टारगेट बनाने के लिए प्रोसेस की गई Python सोर्स फ़ाइलों की सूची. यह इसमें आपके चेक-इन किए गए सभी कोड शामिल होते हैं. साथ ही, इसमें जनरेट की गई सोर्स फ़ाइलें भी शामिल हो सकती हैं. कॉन्टेंट बनाने `.py` फ़ाइलें `srcs` में हैं और लाइब्रेरी टारगेट `deps` में हैं. अन्य बाइनरी रन टाइम के दौरान जिन फ़ाइलों की ज़रूरत पड़ती है वे `डेटा` में होती हैं.
data

लेबल की सूची; डिफ़ॉल्ट रूप से [] है

रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. आम तौर पर नियमों से तय किए गए [`data` एट्रिब्यूट](https://bazel.build/reference/be/common-definitions#typical-attributes) के बारे में टिप्पणियां देखें. `cc_embed_data` और `go_embed_data` की तरह कोई `py_embed_data` नहीं है. ऐसा इसलिए होता है, क्योंकि Python में रनटाइम रिसॉर्स का एक कॉन्सेप्ट मौजूद होता है.
imports

स्ट्रिंग की सूची; [] डिफ़ॉल्ट है

PYTHONPATH में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के हिसाब से बदला जा सकता है. ये इंपोर्ट डायरेक्ट्री जोड़ दी जाएंगी इस नियम और इस पर निर्भर सभी नियमों के लिए (नोट: इस नियम के नियम नहीं निर्भर करता है. `py_binary` नियमों के तहत, हर डायरेक्ट्री को `PYTHONPATH` में जोड़ दिया जाएगा जो इस नियम पर निर्भर करती हैं. ये स्ट्रिंग, repo-runfiles-root के हिसाब से होती हैं. इसमें ऐसे पाथ इस्तेमाल नहीं किए जा सकते जो '/' से शुरू होते हैं. साथ ही, ऐसे पाथ भी इस्तेमाल नहीं किए जा सकते जो एक्सीक्यूशन रूट से ऊपर के पाथ का रेफ़रंस देते हैं. ऐसा करने पर गड़बड़ी का मैसेज दिखेगा.
legacy_create_init

Integer; -1 डिफ़ॉल्ट है

runfiles ट्री में, खाली `__init__.py` फ़ाइलें अपने-आप बननी चाहिए या नहीं. इन्हें Python सोर्स कोड वाली या शेयर की जाने वाली हर डायरेक्ट्री में बनाया जाता है लाइब्रेरी और उन डायरेक्ट्री की हर पैरंट डायरेक्ट्री, जिसमें रेपो को छोड़कर रूट डायरेक्ट्री. डिफ़ॉल्ट तौर पर, `-1` (अपने-आप) होता है. इसका मतलब तब तक सही होता है, जब तक यह सही न हो `--insupported_default_to_ नोटिंग_init_py` का इस्तेमाल किया जाता है. अगर यह विकल्प 'गलत' पर सेट है, तो उपयोगकर्ता को `__init__.py` फ़ाइलें बनानी होंगी. ये फ़ाइलें खाली हो सकती हैं. साथ ही, उन्हें ज़रूरत के हिसाब से Python टारगेट के `srcs` में जोड़ना होगा.
main

लेबल; डिफ़ॉल्ट None है

ज़रूरी नहीं; वह सोर्स फ़ाइल का नाम है जो का इस्तेमाल करें. इस फ़ाइल को `srcs` में भी शामिल किया जाना चाहिए. अगर इसे शामिल नहीं किया जाता है, तो इसके बजाय, `name` के साथ `.py` का इस्तेमाल किया जाता है. अगर `name`, `srcs` में मौजूद किसी भी फ़ाइल के नाम से मेल नहीं खाता है, तो `main` की वैल्यू देना ज़रूरी है.
precompile

स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"

**इस टारगेट के लिए** py सोर्स फ़ाइलें पहले से कंपाइल की जानी चाहिए या नहीं. वैल्यू: * `inherit`: {flag}`--precompile` फ़्लैग से वैल्यू तय करें. * `enabled`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल करें. ध्यान दें कि --precompile_add_to_runfiles से, डाउनस्ट्रीम बाइनरी में संकलित फ़ाइलों को शामिल करने के तरीके पर असर पड़ता है. * `अक्षम`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल न करें. * `if_generate_source`: Python सोर्स फ़ाइलों को कंपाइल करें, लेकिन सिर्फ़ तब, जब वे जनरेट की गई फ़ाइल है. :::{seealso} * {flag}`--precompile` फ़्लैग, जो कुछ मामलों में इस एट्रिब्यूट को बदल सकता है और प्रॉडक्ट बनाते समय इसका सभी टारगेट पर असर पड़ेगा. * {obj}`pyc_collection` एट्रिब्यूट, जिससे हर टारगेट के हिसाब से, पहले से कॉम्पाइल करने की सुविधा को ट्रांज़िटिव तरीके से चालू किया जा सकता है. * पहले से कॉम्पाइल करने की सुविधा का इस्तेमाल करने के बारे में गाइड के लिए, [पहले से कॉम्पाइल करने की सुविधा](precompiling) वाले दस्तावेज़. :::
precompile_invalidation_mode

String; "auto" डिफ़ॉल्ट है

पहले से कंपाइल की गई फ़ाइलों की पुष्टि करने का तरीका, उनसे जुड़ी फ़ाइलों के अप-टू-डेट होने के लिए होना चाहिए सोर्स फ़ाइलें शामिल हैं. आपको ये वैल्यू दिख सकती हैं: * `ऑटो`: असरदार वैल्यू, अन्य बिल्ड से अपने-आप तय हो जाएगी सेटिंग. * `checked_hash`: अगर सोर्स फ़ाइल का हैश हैश से मेल खाता है, तो pyc फ़ाइल का इस्तेमाल करें को pyc फ़ाइल में रिकॉर्ड किया जाता है. यह सुविधा तब सबसे ज़्यादा काम की होती है, जब ऐसे कोड पर काम किया जा रहा हो जिसमें बदलाव किया जा सकता है. * `unchecked_hash`: हमेशा pyc फ़ाइल का इस्तेमाल करें; के लिए पाइसी हैश की जांच न करें स्रोत फ़ाइल होगी. यह तब सबसे ज़्यादा काम आता है, जब कोड में बदलाव नहीं किया जाएगा. pyc को अमान्य करने के मोड के बारे में ज़्यादा जानने के लिए, https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode पर जाएं
precompile_optimize_level

Integer; 0 डिफ़ॉल्ट है

पहले से कंपाइल की गई फ़ाइलों के लिए ऑप्टिमाइज़ेशन लेवल. ऑप्टिमाइज़ेशन लेवल के बारे में ज़्यादा जानकारी के लिए, `compile()` फ़ंक्शन का https://docs.python.org/3/library/Functions.html#compile पर `ऑप्टिमाइज़` दस्तावेज़ ध्यान दें: `-1` वैल्यू का मतलब "मौजूदा अनुवादक" है, जो अनुवादक होगा _at बिल्ड समय जब pycs जनरेट होते हैं_, का उपयोग किया गया, न कि इस पर उपयोग किया गया अनुवादक रनटाइम को तब ट्रिगर करता है, जब कोड असल में काम करता है.
precompile_source_retention

स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"

यह तय करता है कि किसी सोर्स फ़ाइल को कंपाइल करने के बाद, उस सोर्स फ़ाइल को आउटपुट में शामिल किया जाएगा या नहीं. मान्य वैल्यू ये हैं: * `इनहेरिट`: {flag}`--precompile_source_retention` फ़्लैग से वैल्यू इनहेरिट करें. * `keep_source`: ओरिजनल Python सोर्स को शामिल करें. * `omit_source`: मूल py सोर्स को शामिल न करें. * `omit_if_generated_source`: अगर सोर्स फ़ाइल सामान्य है, तो ओरिजनल सोर्स को बनाए रखें. अगर सोर्स फ़ाइल जनरेट की गई है, तो उसे हटा दें.
pyc_collection

स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"

यह तय करता है कि डिपेंडेंसी से मिली pyc फ़ाइलों को मैन्युअल तरीके से शामिल किया जाना चाहिए या नहीं. ध्यान दें: यह सेटिंग सिर्फ़ {flag}`--precompile_add_to_runfiles=descded_elsewhere` के साथ काम करती है. मान्य वैल्यू ये हैं: * `inherit`: {flag}`--pyc_collection` से वैल्यू इनहेरिट करें. * `include_pyc`: बाइनरी में डिपेंडेंसी से pyc फ़ाइलें जोड़ें (यहां से) {obj}`PyInfo.transitive_pyc_files`. * `disable`: डिपेंडेंसी से चुनी गई pyc फ़ाइलों को साफ़ तौर पर न जोड़ें. ध्यान दें कि अगर कोई टारगेट, pyc फ़ाइलों को अपने रनफ़ाइल के हिस्से के तौर पर शामिल करता है, तो वे अब भी डिपेंडेंसी से आ सकती हैं. जैसे, {obj}`--precompile_add_to_runfiles=always` का इस्तेमाल करने पर.
python_version

स्ट्रिंग; डिफ़ॉल्ट रूप से "PY3"

यह सुविधा अब काम नहीं करती और इसका इस्तेमाल नहीं किया जाता.
srcs_version

स्ट्रिंग; डिफ़ॉल्ट रूप से "PY2AND3"

इस्तेमाल में नहीं है, कुछ नहीं करता.
stamp

पूर्णांक; डिफ़ॉल्ट वैल्यू -1 है

बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. ये वैल्यू हो सकती हैं: * `stamp = 1`: बाइनरी में हमेशा बिल्ड की जानकारी को स्टैंप करें. भले ही, `--nostamp` वाले बिल्ड में भी ऐसा करें. **इस सेटिंग से बचना चाहिए**, क्योंकि इससे बाइनरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल बंद हो सकता है. * `stamp = 0`: बिल्ड की जानकारी को हमेशा कॉन्स्टेंट वैल्यू से बदलें. इससे ये फ़ायदे मिलते हैं अच्छा बिल्ड परिणाम कैशिंग. * `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की प्रोसेस, `--[no]stamp` फ़्लैग. स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो जाए. चेतावनी: स्टैंपिंग की वजह से कैश मेमोरी में हिट की संख्या कम हो सकती है. इससे बिल्ड की परफ़ॉर्मेंस पर असर पड़ सकता है. इसलिए, अगर हो सके, तो स्टैंपिंग से बचें.

py_library

नियम का सोर्स देखें 
py_library(name, deps, srcs, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, imports, licenses, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, restricted_to, srcs_version, tags, target_compatible_with, testonly, toolchains, visibility)
 Python कोड की ऐसी लाइब्रेरी जिस पर भरोसा किया जा सकता है. डिफ़ॉल्ट आउटपुट: * इनपुट Python सोर्स * सोर्स से पहले से कंपाइल किए गए आर्टफ़ैक्ट. ध्यान दें: पहले से कंपाइल करने से, इस बात पर असर पड़ता है कि कौनसे डिफ़ॉल्ट आउटपुट, रनफ़ाइल में शामिल किए जाएंगे. ज़्यादा जानकारी के लिए, पहले से कंपाइल करने से जुड़े एट्रिब्यूट और फ़्लैग देखें.

तर्क

विशेषताएं
name

नाम; आवश्यक

इस टारगेट के लिए यूनीक नाम.
deps

लेबल की सूची; डिफ़ॉल्ट रूप से [] है

टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. आम तौर पर, नियमों से तय किए गए [`deps` एट्रिब्यूट](https://bazel.build/reference/be/common-definitions#typical-attributes) के बारे में टिप्पणियां देखें. आम तौर पर, ये `py_library` के नियम होते हैं. रनटाइम के दौरान इस्तेमाल की जाने वाली डेटा फ़ाइलों को ही उपलब्ध कराने वाले टारगेट, `डेटा` में शामिल होते हैं एट्रिब्यूट की वैल्यू सबमिट करें.
srcs

लेबल की सूची; डिफ़ॉल्ट रूप से [] है

टारगेट बनाने के लिए प्रोसेस की गई Python सोर्स फ़ाइलों की सूची. यह इसमें आपके चेक-इन किए गए सभी कोड शामिल होते हैं. साथ ही, इसमें जनरेट की गई सोर्स फ़ाइलें भी शामिल हो सकती हैं. '.py' फ़ाइलें `srcs` में और लाइब्रेरी टारगेट `deps` में होती हैं. रन टाइम के दौरान ज़रूरी अन्य बाइनरी फ़ाइलें `data` में होती हैं.
data

लेबल की सूची; डिफ़ॉल्ट [] है

रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. इस बारे में टिप्पणियां देखें आम तौर पर, [`डेटा` एट्रिब्यूट, नियमों से तय होता है](https://batz.build/reference/be/common- परिभाषाs#typical-attributes). `cc_embed_data` और `go_embed_data` की तरह, `py_embed_data` नहीं है. ऐसा इसलिए है, क्योंकि Python में रनटाइम संसाधनों का कॉन्सेप्ट है.
imports

स्ट्रिंग की सूची; [] डिफ़ॉल्ट है

PYTHONPATH में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के हिसाब से बदला जा सकता है. ये इंपोर्ट डायरेक्ट्री जोड़ दी जाएंगी इस नियम और इस पर निर्भर सभी नियमों के लिए (नोट: इस नियम के नियम नहीं निर्भर करता है. `py_binary` नियमों के तहत, हर डायरेक्ट्री को `PYTHONPATH` में जोड़ दिया जाएगा जो इस नियम पर निर्भर करती हैं. ये स्ट्रिंग रेपो-रनफ़ाइल-रूट रिलेटिव होती हैं, ऐब्सलूट पाथ (`/` से शुरू होने वाले पाथ) और पाथ का रेफ़रंस देने वाले पाथ के बाद वाले उदाहरण को इस्तेमाल करने की अनुमति नहीं है और इससे गड़बड़ी हो सकती है.
precompile

String; "inherit" डिफ़ॉल्ट है

**इस टारगेट के लिए** py सोर्स फ़ाइलें पहले से कंपाइल की जानी चाहिए या नहीं. वैल्यू: * `inherit`: {flag}`--precompile` फ़्लैग से वैल्यू तय करें. * `enabled`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल करें. ध्यान दें कि --precompile_add_to_runfiles से, डाउनस्ट्रीम बाइनरी में संकलित फ़ाइलों को शामिल करने के तरीके पर असर पड़ता है. * `अक्षम`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल न करें. * `if_generate_source`: Python सोर्स फ़ाइलों को कंपाइल करें, लेकिन सिर्फ़ तब, जब वे जनरेट की गई फ़ाइल है. :::{seealso} * {flag}`--precompile` फ़्लैग, जो कुछ मामलों में इस एट्रिब्यूट को बदल सकता है और प्रॉडक्ट बनाते समय इसका सभी टारगेट पर असर पड़ेगा. * {obj}`pyc_collection` एट्रिब्यूट, जिससे हर टारगेट के हिसाब से, पहले से कॉम्पाइल करने की सुविधा को ट्रांज़िटिव तरीके से चालू किया जा सकता है. * पहले से कॉम्पाइल करने की सुविधा का इस्तेमाल करने के बारे में गाइड के लिए, [पहले से कॉम्पाइल करने की सुविधा](precompiling) वाले दस्तावेज़. :::
precompile_invalidation_mode

String; "auto" डिफ़ॉल्ट है

पहले से कंपाइल की गई फ़ाइलों की पुष्टि करने का तरीका, उनसे जुड़ी फ़ाइलों के अप-टू-डेट होने के लिए होना चाहिए सोर्स फ़ाइलें शामिल हैं. आपको ये वैल्यू दिख सकती हैं: * `ऑटो`: असरदार वैल्यू, अन्य बिल्ड से अपने-आप तय हो जाएगी सेटिंग. * `checked_hash`: अगर सोर्स फ़ाइल का हैश हैश से मेल खाता है, तो pyc फ़ाइल का इस्तेमाल करें को pyc फ़ाइल में रिकॉर्ड किया जाता है. यह सुविधा तब सबसे ज़्यादा काम की होती है, जब ऐसे कोड पर काम किया जा रहा हो जिसमें बदलाव किया जा सकता है. * `unchecked_hash`: हमेशा pyc फ़ाइल का इस्तेमाल करें; के लिए पाइसी हैश की जांच न करें स्रोत फ़ाइल होगी. यह तब सबसे ज़्यादा काम आता है, जब कोड में बदलाव नहीं किया जाएगा. pyc को अमान्य करने के मोड के बारे में ज़्यादा जानने के लिए, https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode पर जाएं
precompile_optimize_level

Integer; 0 डिफ़ॉल्ट है

पहले से कंपाइल की गई फ़ाइलों के लिए ऑप्टिमाइज़ेशन लेवल. ऑप्टिमाइज़ेशन लेवल के बारे में ज़्यादा जानकारी के लिए, `compile()` फ़ंक्शन का https://docs.python.org/3/library/Functions.html#compile पर `ऑप्टिमाइज़` दस्तावेज़ ध्यान दें: `-1` वैल्यू का मतलब "मौजूदा अनुवादक" है, जो अनुवादक होगा _at बिल्ड समय जब pycs जनरेट होते हैं_, का उपयोग किया गया, न कि इस पर उपयोग किया गया अनुवादक रनटाइम को तब ट्रिगर करता है, जब कोड असल में काम करता है.
precompile_source_retention

स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"

यह तय करता है कि किसी सोर्स फ़ाइल को कंपाइल करने के बाद, उस सोर्स फ़ाइल को आउटपुट में शामिल किया जाएगा या नहीं. मान्य वैल्यू ये हैं: * `इनहेरिट`: {flag}`--precompile_source_retention` फ़्लैग से वैल्यू इनहेरिट करें. * `keep_source`: ओरिजनल Python सोर्स को शामिल करें. * `omit_source`: ओरिजनल py सोर्स शामिल न करें. * `omit_if_generated_source`: अगर सोर्स फ़ाइल सामान्य है, तो ओरिजनल सोर्स को बनाए रखें. अगर सोर्स फ़ाइल जनरेट की गई है, तो उसे हटा दें.
srcs_version

स्ट्रिंग; डिफ़ॉल्ट रूप से "PY2AND3"

यह सुविधा अब काम नहीं करती और इसका इस्तेमाल नहीं किया जाता.

py_test

नियम का सोर्स देखें 
py_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, imports, legacy_create_init, licenses, local, main, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyc_collection, python_version, restricted_to, shard_count, size, srcs_version, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility)

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
deps

लेबल की सूची; डिफ़ॉल्ट रूप से [] है

टारगेट से लिंक की जाने वाली अतिरिक्त लाइब्रेरी की सूची. इस बारे में टिप्पणियां देखें [`deps` एट्रिब्यूट आम तौर पर, rules](https://bazel.build/reference/be/common-definitions#typical-attributes). आम तौर पर, ये `py_library` नियम होते हैं. सिर्फ़ रनटाइम के दौरान इस्तेमाल की जाने वाली डेटा फ़ाइलें देने वाले टारगेट, `data` एट्रिब्यूट में आते हैं.
srcs

लेबल की सूची; आवश्यक

टारगेट बनाने के लिए प्रोसेस की गई Python सोर्स फ़ाइलों की सूची. इसमें, आपका चेक-इन किया गया सारा कोड शामिल होता है. साथ ही, इसमें जनरेट की गई सोर्स फ़ाइलें भी शामिल हो सकती हैं. कॉन्टेंट बनाने `.py` फ़ाइलें `srcs` में हैं और लाइब्रेरी टारगेट `deps` में हैं. अन्य बाइनरी रन टाइम के दौरान जिन फ़ाइलों की ज़रूरत पड़ती है वे `डेटा` में होती हैं.
data

लेबल की सूची; डिफ़ॉल्ट रूप से [] है

रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. आम तौर पर नियमों से तय किए गए [`data` एट्रिब्यूट](https://bazel.build/reference/be/common-definitions#typical-attributes) के बारे में टिप्पणियां देखें. `cc_embed_data` और `go_embed_data` की तरह कोई `py_embed_data` नहीं है. ऐसा इसलिए होता है, क्योंकि Python में रनटाइम रिसॉर्स का एक कॉन्सेप्ट मौजूद होता है.
imports

स्ट्रिंग की सूची; [] डिफ़ॉल्ट है

PYTHONPATH में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के हिसाब से बदला जा सकता है. ये इंपोर्ट डायरेक्ट्री जोड़ दी जाएंगी इस नियम और इस पर निर्भर सभी नियमों के लिए (नोट: इस नियम के नियम नहीं निर्भर करता है. `py_binary` नियमों के तहत, हर डायरेक्ट्री को `PYTHONPATH` में जोड़ दिया जाएगा जो इस नियम पर निर्भर करती हैं. ये स्ट्रिंग, repo-runfiles-root के हिसाब से होती हैं. इसमें ऐसे पाथ इस्तेमाल नहीं किए जा सकते जो '/' से शुरू होते हैं. साथ ही, ऐसे पाथ भी इस्तेमाल नहीं किए जा सकते जो एक्सीक्यूशन रूट से ऊपर के पाथ का रेफ़रंस देते हैं. ऐसा करने पर गड़बड़ी का मैसेज दिखेगा.
legacy_create_init

Integer; -1 डिफ़ॉल्ट है

क्या रनफ़ाइल ट्री में साफ़ तौर पर खाली `__init__.py` फ़ाइलें बनानी हैं. ये हर उस डायरेक्ट्री में बनाई जाती हैं जिसमें Python सोर्स कोड या शेयर की गई लाइब्रेरी होती हैं. साथ ही, ये उन डायरेक्ट्री की हर पैरंट डायरेक्ट्री में बनाई जाती हैं. हालांकि, ये रिपॉज़िटरी की रूट डायरेक्ट्री में नहीं बनाई जाती हैं. डिफ़ॉल्ट तौर पर, `-1` (अपने-आप) होता है. इसका मतलब तब तक सही होता है, जब तक यह सही न हो `--insupported_default_to_ नोटिंग_init_py` का इस्तेमाल किया जाता है. अगर यह विकल्प 'गलत' पर सेट है, तो उपयोगकर्ता को `__init__.py` फ़ाइलें बनानी होंगी. ये फ़ाइलें खाली हो सकती हैं. साथ ही, उन्हें ज़रूरत के हिसाब से Python टारगेट के `srcs` में जोड़ना होगा.
main

लेबल; डिफ़ॉल्ट None है

ज़रूरी नहीं; सोर्स फ़ाइल का नाम, जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट है. इस फ़ाइल को `srcs` में भी शामिल किया जाना चाहिए. अगर इसे शामिल नहीं किया जाता है, तो इसके बजाय, `name` के साथ `.py` का इस्तेमाल किया जाता है. अगर `नाम` किसी से मेल नहीं खाता `srcs` में फ़ाइल नाम, `main` के बारे में बताया जाना चाहिए.
precompile

स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"

**इस टारगेट के लिए** py सोर्स फ़ाइलें पहले से कंपाइल की जानी चाहिए या नहीं. वैल्यू: * `inherit`: {flag}`--precompile` फ़्लैग से वैल्यू तय करें. * `enabled`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल करें. ध्यान दें कि --precompile_add_to_runfiles से, डाउनस्ट्रीम बाइनरी में संकलित फ़ाइलों को शामिल करने के तरीके पर असर पड़ता है. * `अक्षम`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल न करें. * `if_generate_source`: Python सोर्स फ़ाइलों को कंपाइल करें, लेकिन सिर्फ़ तब, जब वे जनरेट की गई फ़ाइल है. :::{seealso} * {flag}`--precompile` फ़्लैग, जो कुछ मामलों में इस एट्रिब्यूट को बदल सकता है और प्रॉडक्ट बनाते समय इसका सभी टारगेट पर असर पड़ेगा. * {obj}`pyc_collection` एट्रिब्यूट, जिससे हर टारगेट के हिसाब से, पहले से कॉम्पाइल करने की सुविधा को ट्रांज़िटिव तरीके से चालू किया जा सकता है. * पहले से कॉम्पाइल करने की सुविधा का इस्तेमाल करने के बारे में गाइड के लिए, [पहले से कॉम्पाइल करने की सुविधा](precompiling) वाले दस्तावेज़. :::
precompile_invalidation_mode

String; "auto" डिफ़ॉल्ट है

पहले से कंपाइल की गई फ़ाइलों की पुष्टि करने का तरीका, उनसे जुड़ी फ़ाइलों के अप-टू-डेट होने के लिए होना चाहिए सोर्स फ़ाइलें शामिल हैं. आपको ये वैल्यू दिख सकती हैं: * `ऑटो`: असरदार वैल्यू, अन्य बिल्ड से अपने-आप तय हो जाएगी सेटिंग. * `checked_hash`: अगर सोर्स फ़ाइल का हैश हैश से मेल खाता है, तो pyc फ़ाइल का इस्तेमाल करें को pyc फ़ाइल में रिकॉर्ड किया जाता है. यह सुविधा तब सबसे ज़्यादा काम की होती है, जब ऐसे कोड पर काम किया जा रहा हो जिसमें बदलाव किया जा सकता है. * `unchecked_hash`: हमेशा pyc फ़ाइल का इस्तेमाल करें; के लिए पाइसी हैश की जांच न करें स्रोत फ़ाइल होगी. यह तब सबसे ज़्यादा काम आता है, जब कोड में बदलाव नहीं किया जाएगा. pyc को अमान्य करने के मोड के बारे में ज़्यादा जानने के लिए, https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode पर जाएं
precompile_optimize_level

Integer; 0 डिफ़ॉल्ट है

पहले से कंपाइल की गई फ़ाइलों के लिए ऑप्टिमाइज़ेशन लेवल. ऑप्टिमाइज़ेशन लेवल के बारे में ज़्यादा जानकारी के लिए, `compile()` फ़ंक्शन का https://docs.python.org/3/library/Functions.html#compile पर `ऑप्टिमाइज़` दस्तावेज़ ध्यान दें: `-1` वैल्यू का मतलब "मौजूदा अनुवादक" है, जो अनुवादक होगा _at बिल्ड समय जब pycs जनरेट होते हैं_, का उपयोग किया गया, न कि इस पर उपयोग किया गया अनुवादक रनटाइम को तब ट्रिगर करता है, जब कोड असल में काम करता है.
precompile_source_retention

स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"

यह तय करता है कि किसी सोर्स फ़ाइल को कंपाइल करने के बाद, उस सोर्स फ़ाइल को आउटपुट में शामिल किया जाएगा या नहीं. मान्य वैल्यू ये हैं: * `इनहेरिट`: {flag}`--precompile_source_retention` फ़्लैग से वैल्यू इनहेरिट करें. * `keep_source`: ओरिजनल Python सोर्स को शामिल करें. * `omit_source`: मूल py सोर्स को शामिल न करें. * `omit_if_generated_source`: अगर सोर्स फ़ाइल सामान्य है, तो ओरिजनल सोर्स को बनाए रखें. अगर सोर्स फ़ाइल जनरेट की गई है, तो उसे हटा दें.
pyc_collection

स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"

यह तय करता है कि डिपेंडेंसी से मिली pyc फ़ाइलों को मैन्युअल तरीके से शामिल किया जाना चाहिए या नहीं. ध्यान दें: यह सेटिंग सिर्फ़ {flag}`--precompile_add_to_runfiles=descded_elsewhere` के साथ काम करती है. मान्य वैल्यू ये हैं: * `inherit`: {flag}`--pyc_collection` से वैल्यू इनहेरिट करें. * `include_pyc`: बाइनरी में डिपेंडेंसी से pyc फ़ाइलें जोड़ें (यहां से) {obj}`PyInfo.transitive_pyc_files`. * `disable`: डिपेंडेंसी से चुनी गई pyc फ़ाइलों को साफ़ तौर पर न जोड़ें. ध्यान दें कि अगर कोई टारगेट, pyc फ़ाइलों को अपने रनफ़ाइल के हिस्से के तौर पर शामिल करता है, तो वे अब भी डिपेंडेंसी से आ सकती हैं. जैसे, {obj}`--precompile_add_to_runfiles=always` का इस्तेमाल करने पर.
python_version

स्ट्रिंग; डिफ़ॉल्ट रूप से "PY3"

यह सुविधा अब काम नहीं करती और इसका इस्तेमाल नहीं किया जाता.
srcs_version

स्ट्रिंग; डिफ़ॉल्ट रूप से "PY2AND3"

यह सुविधा अब काम नहीं करती और इसका इस्तेमाल नहीं किया जाता.
stamp

Integer; 0 डिफ़ॉल्ट है

बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. वैल्यू, इनमें से कोई हो सकती है: * `stamp = 1`: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें, भले ही `--nostamp` बनाता है. **इस सेटिंग से बचना चाहिए**, क्योंकि इससे बाइनरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल बंद हो सकता है. * `stamp = 0`: बिल्ड की जानकारी को हमेशा कॉन्स्टेंट वैल्यू से बदलें. इससे ये फ़ायदे मिलते हैं अच्छा बिल्ड परिणाम कैशिंग. * `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की सुविधा, `--[no]stamp` फ़्लैग से कंट्रोल की जाती है. स्टैंप वाली बाइनरी तब तक फिर से नहीं बनाई जाती, जब तक उनकी डिपेंडेंसी नहीं बदलती है. चेतावनी: स्टैंप लगाने से, कैश मेमोरी के हिट कम हो सकते हैं. इससे बिल्ड परफ़ॉर्मेंस पर बुरा असर पड़ सकता है. अगर हो सके, तो ऐसा करने से बचें.

py_runtime

नियम का सोर्स देखें 
py_runtime(name, bootstrap_template, compatible_with, coverage_tool, deprecation, distribs, exec_compatible_with, exec_properties, features, files, implementation_name, interpreter, interpreter_path, interpreter_version_info, pyc_tag, python_version, restricted_to, stage2_bootstrap_template, stub_shebang, tags, target_compatible_with, testonly, toolchains, visibility, zip_main_template)
 यह Python कोड को एक्ज़ीक्यूट करने के लिए इस्तेमाल किए जाने वाले Python रनटाइम को दिखाता है. `py_runtime` टारगेट से *प्लैटफ़ॉर्म रनटाइम* या *इन-बिल्ड को दिखाया जा सकता है रनटाइम* के लिए किया जा सकता है. प्लैटफ़ॉर्म रनटाइम, सिस्टम पर इंस्टॉल किए गए अनुवादक को ऐक्सेस करता है पाथ शामिल होता है, जबकि इन-बिल्ड रनटाइम, ऐसे एक्ज़ीक्यूटेबल टारगेट पर ले जाता है जो अनुवादक. दोनों ही मामलों में, "अनुवादक" का मतलब है, एक्ज़ीक्यूटेबल बाइनरी या रैपर स्क्रिप्ट, जो निर्देश पर पास की गई Python स्क्रिप्ट को चलाने में सक्षम है . प्लैटफ़ॉर्म का रनटाइम, अपनी वजह से नॉन-हर्मेटिक होता है. यह इस तरह के कॉन्टेंट पर एक शर्त लागू करता है: टारगेट प्लैटफ़ॉर्म को, किसी खास पाथ पर एक अनुवादक की सुविधा दी जाए. अगर आप इन-बिल्ड रनटाइम, हर्मेटिक हो सकता है और नहीं भी. यह इस बात पर निर्भर करता है कि यह सिस्टम को ऐक्सेस करने वाला चेक-इन इंटरप्रेटर या रैपर स्क्रिप्ट अनुवादक. उदाहरण ``` लोड("@rules_python//python:py_runtime.bzl", "py_runtime") py_runtime( name = "Python-2.7.12", फ़ाइलें = ग्लोब(["python-2.7.12/**"]), अनुवादक = "python-2.7.12/bin/python", ) py_runtime( name = "Python-3.6.0", interpreter_path = "/opt/pyenv/versions/3.6.0/bin/python", ) ```

तर्क

विशेषताएं
name

नाम; आवश्यक

इस टारगेट के लिए यूनीक नाम.
bootstrap_template

लेबल; डिफ़ॉल्ट रूप से "@rules_python//python/private:bootstrap_template" है

इस्तेमाल करने के लिए, बूटस्ट्रैप स्क्रिप्ट टेंप्लेट फ़ाइल. इसमें %python_binary%, %workspace_name%, %main%, और %imports% शामिल होने चाहिए. बड़ा किए जाने के बाद, यह टेंप्लेट एक्ज़ीक्यूटेबल फ़ाइल बन जाता है. इसका इस्तेमाल प्रोसेस शुरू करने के लिए किया जाता है. इसलिए, यह शुरुआती बूटस्ट्रैपिंग कार्रवाइयों के लिए ज़िम्मेदार होता है. जैसे, Python इंटरप्रेटर, रनफ़ाइलें ढूंढना, और टारगेट किए गए Python ऐप्लिकेशन को चलाने के लिए एक एनवायरमेंट बनाना. फ़िलहाल, यह एट्रिब्यूट ज़रूरी नहीं है. हालांकि, यह तब ज़रूरी होगा, जब Python के नियमों को खुद बेज़ल से हटा दिया गया है. वैरिएबल के जिन नामों को बड़ा किया गया है वे ठीक से काम नहीं कर रहे हैं. साथ ही, इनमें बदलाव हो सकता है. जब Python के नियमों को Basel से बाहर ले जाया जाएगा, तब एपीआई ज़्यादा स्थिर हो जाएगा वह भी ऐसा कर सकता है. ज़्यादा वैरिएबल के लिए, @bazel_tools//tools/python:python_bootstrap_template.txt देखें.
coverage_tool

लेबल; डिफ़ॉल्ट रूप से None है

यह टारगेट, कोड कवरेज की जानकारी इकट्ठा करने के लिए है {Rule}`py_binary` और {Rule}`py_test` टारगेट. अगर यह सेट है, तो टारगेट से एक फ़ाइल जनरेट होनी चाहिए या यह एक ऐसा टारगेट होना चाहिए जिसे चलाया जा सके. एक फ़ाइल का पाथ या टारगेट के एक्ज़ीक्यूटेबल होने पर, एक्ज़ीक्यूटेबल से python कवरेज टूल के एंट्री पॉइंट का पता चलता है. कवरेज चालू होने पर, टारगेट और उसकी रनफ़ाइलें, रनफ़ाइलों में जोड़ दी जाएंगी. टूल का एंट्री पॉइंट ऐसा होना चाहिए जिसे Python इंटरप्रेटर से लोड किया जा सके (उदाहरण के लिए, `.py` या `.pyc` फ़ाइल). इसे कमांड लाइन आर्ग्युमेंट स्वीकार किए जाने चाहिए कम से कम [`coverage.py`](https://coverage.readthedocs.io) का हिस्सा `दौड़ने` और `एलकोव` सब-कमांड.
files

लेबल की सूची; डिफ़ॉल्ट रूप से [] है

इन-बिल्ड रनटाइम के लिए, यह इस रनटाइम की फ़ाइलों का सेट होता है. इन फ़ाइलों को, इस रनटाइम का इस्तेमाल करने वाली Python बाइनरी के रनफ़ाइल में जोड़ दिया जाएगा. प्लैटफ़ॉर्म के रनटाइम के लिए, यह एट्रिब्यूट सेट नहीं किया जाना चाहिए.
implementation_name

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

Python लागू करने का नाम (`sys.अपना लागू करने का नाम`)
interpreter

लेबल; डिफ़ॉल्ट रूप से None है

इन-बिल्ड रनटाइम के लिए, इस टारगेट का इस्तेमाल एक अनुवादक के तौर पर किया जाना है. यह इनमें से कोई एक हो सकता है: * एक फ़ाइल, जो इंटरप्रेटर बाइनरी होगी. यह माना जाता है कि ऐसे interpreter, एक फ़ाइल वाले ऐसे ऐप्लिकेशन होते हैं जिन्हें खुद से चलाया जा सकता है या जिनके साथ काम करने वाली सभी फ़ाइलें, `files` में दी गई होती हैं. * एक ऐसा टारगेट जिसे चलाया जा सकता है. टारगेट का एक्सीक्यूटेबल, इंटरप्रेटर बाइनरी होगा. कोई भी अन्य डिफ़ॉल्ट आउटपुट (`target.files`) और सामान्य फ़ाइलें, रनफ़ाइलें (`runfiles.files`) अपने-आप शामिल हो जाएंगी, जैसे कि `files` एट्रिब्यूट में बताया गया हो. ध्यान दें: हो सकता है कि टारगेट के रनफ़ाइल को अब तक टूलचैन/इंटरप्रेटर के उपभोक्ताओं के लिए सही तरीके से लागू/प्रचारित न किया गया हो. इसके बारे में ज़्यादा जानने के लिए, bazelbuild/rules_python/issues/1612 पर जाएं प्लैटफ़ॉर्म के रनटाइम (यानी `interpreter_path` सेट किया जा रहा है) के लिए, यह एट्रिब्यूट सेट नहीं किया जाना चाहिए.
interpreter_path

String; "" डिफ़ॉल्ट है

प्लैटफ़ॉर्म के रनटाइम के लिए, यह टारगेट प्लैटफ़ॉर्म पर मौजूद Python इंटरप्रेटर का ऐब्सलूट पाथ होता है. इन-बिल्ड रनटाइम के लिए, इस एट्रिब्यूट को सेट नहीं करना चाहिए.
interpreter_version_info

शब्दकोश: स्ट्रिंग -> String; {} डिफ़ॉल्ट है

इस रनटाइम से मिलने वाले इंटरप्रिटर के वर्शन की जानकारी. अगर बताया नहीं गया है, तो {obj}`--python_version` का इस्तेमाल करता है `sys.version_info` के नाम से काम करने वाली कुंजियां मेल खाती हैं. इनपुट के दौरान वैल्यू, स्ट्रिंग होती हैं. इनमें से ज़्यादातर वैल्यू, इनपुट में बदली जाती हैं. इस्तेमाल की जा सकने वाली कुंजियां हैं: * मेजर: पूर्णांक, मेजर वर्शन नंबर * माइनर: पूर्णांक, माइनर वर्शन नंबर * माइक्रो: वैकल्पिक पूर्णांक, माइक्रो वर्शन नंबर * रिलीज़ लेवल: वैकल्पिक एसटीआर, रिलीज़ लेवल * सीरियल: वैकल्पिक पूर्णांक, रिलीज़ का सीरियल नंबर :::{versionturned} 0.36.0 {obj}`--python_version` डिफ़ॉल्ट वैल्यू तय करता है. :::
pyc_tag

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

ज़रूरी नहीं है; pyc फ़ाइल के नाम का टैग हिस्सा, जैसे कि `foo.cpython-39.pyc` का `cpython-39` इनफ़िक्स. PEP 3147 देखें. अगर यह जानकारी नहीं दी गई है, तो इसे `implementation_name` और `interpreter_version_info` से कैलकुलेट किया जाएगा. अगर कोई pyc_tag उपलब्ध नहीं है, तो सिर्फ़ सोर्स-लेस pyc जनरेशन सही तरीके से काम करेगा.
python_version

स्ट्रिंग; डिफ़ॉल्ट रूप से "PY3"

यह रनटाइम, Python मेजर वर्शन 2 या 3 के लिए है या नहीं. मान्य वैल्यू `"PY2"` हैं और `"PY3"` हैं. डिफ़ॉल्ट वैल्यू को `--insupported_py3_is_default` फ़्लैग से कंट्रोल किया जाता है. हालांकि, आने वाले समय में यह एट्रिब्यूट ज़रूरी होगा और इसे डिफ़ॉल्ट के तौर पर सेट नहीं किया जाएगा वैल्यू.
stage2_bootstrap_template

लेबल; डिफ़ॉल्ट रूप से "@rules_python//python/private:stage2_bootstrap_template" है

दो चरणों में बूटस्ट्रैप करने की सुविधा चालू होने पर इस्तेमाल किया जाने वाला टेंप्लेट :::{seealso} {obj}`PyRuntimeInfo.stage2_bootstrap_template` और {obj}`--bootstrap_impl` :::
stub_shebang

स्ट्रिंग; डिफ़ॉल्ट रूप से "#!/usr/bin/env python3"

"शैबैंग" एक्सप्रेशन, बूटस्ट्रैपिंग Python स्टब स्क्रिप्ट के शुरू में जोड़ा जाता है. इसका इस्तेमाल, {rule}`py_binary` टारगेट को लागू करते समय किया जाता है. इस बारे में जानने के लिए, https://github.com/bazibuild/ba आवाज़ों/issues/8685 पर जाएं प्रेरणा देते हैं. Windows पर लागू नहीं होता है.
zip_main_template

लेबल; डिफ़ॉल्ट "@rules_python//python/private:zip_main_template" है

टेंप्लेट, जिसका इस्तेमाल zip की टॉप-लेवल `__main__.py` फ़ाइल के लिए किया जाता है. यह एंट्री पॉइंट बन जाता है, जो `python foo.zip` को चलाने पर लागू होता है. :::{seealso} {obj}`PyRuntimeInfo.zip_main_template` फ़ील्ड. :::