किसी समस्या की शिकायत करेंopen_in_new
सोर्स देखेंopen_in_new
Nightly
·
7.4
.
7.3
·
7.2
·
7.1
·
7.0
·
6.5
नियम
py_binary
नियम का सोर्स देखेंopen_in_new
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` एट्रिब्यूट](https://bazel.build/reference/be/common-definitions#typical-attributes) के बारे में टिप्पणियां देखें.
आम तौर पर, ये `py_library` के नियम होते हैं.
सिर्फ़ रनटाइम के दौरान इस्तेमाल की जाने वाली डेटा फ़ाइलें देने वाले टारगेट, `data` एट्रिब्यूट के दायरे में आते हैं.
|
srcs
|
लेबल की सूची; ज़रूरी है
टारगेट बनाने के लिए प्रोसेस की गई Python सोर्स फ़ाइलों की सूची. इसमें, आपका चेक इन किया गया सारा कोड शामिल होता है. साथ ही, इसमें जनरेट की गई सोर्स फ़ाइलें भी शामिल हो सकती हैं. '.py' फ़ाइलें `srcs` में और लाइब्रेरी टारगेट `deps` में होती हैं. रन टाइम के दौरान ज़रूरी हो सकने वाली अन्य बाइनरी फ़ाइलें `data` में होती हैं.
|
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
|
पूर्णांक; डिफ़ॉल्ट वैल्यू -1 है
runfiles ट्री में, खाली `__init__.py` फ़ाइलें अपने-आप बननी चाहिए या नहीं.
ये हर उस डायरेक्ट्री में बनाई जाती हैं जिसमें Python सोर्स कोड या शेयर की गई लाइब्रेरी होती हैं. साथ ही, ये उन डायरेक्ट्री की हर पैरंट डायरेक्ट्री में बनाई जाती हैं. हालांकि, इनमें रिपॉज़िटरी की रूट डायरेक्ट्री शामिल नहीं होती. डिफ़ॉल्ट तौर पर, `-1` (अपने-आप) का मतलब 'सही' होता है. ऐसा तब तक होता है, जब तक कि `--incompatible_default_to_explicit_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 से, डाउनस्ट्रीम बाइनरी में संकलित फ़ाइलों को शामिल करने के तरीके पर असर पड़ता है.
* `disabled`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल न करें.
* `if_generated_source`: Python सोर्स फ़ाइलों को सिर्फ़ तब कॉम्पाइल करें, जब वे जनरेट की गई फ़ाइल हों.
:::{seealso}
* {flag}`--precompile` फ़्लैग, जो कुछ मामलों में इस एट्रिब्यूट को बदल सकता है
और बिल्ड करते समय सभी टारगेट पर असर डालेगा.
* {obj}`pyc_collection` एट्रिब्यूट, जिससे हर टारगेट के हिसाब से, पहले से कॉम्पाइल करने की सुविधा को ट्रांज़िटिव तरीके से चालू किया जा सकता है.
* पहले से कॉम्पाइल करने की सुविधा का इस्तेमाल करने के बारे में गाइड के लिए, [पहले से कॉम्पाइल करने की सुविधा](precompiling) वाले दस्तावेज़.
:::
|
precompile_invalidation_mode
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "auto"
पहले से कंपाइल की गई फ़ाइलों की पुष्टि कैसे की जानी चाहिए, ताकि यह पता चल सके कि वे अपनी सोर्स फ़ाइलों के साथ अप-टू-डेट हैं या नहीं. ये वैल्यू हो सकती हैं:
* `auto`: असरदार वैल्यू, अन्य बिल्ड सेटिंग के हिसाब से अपने-आप तय हो जाएगी.
* `checked_hash`: अगर सोर्स फ़ाइल का हैश, pyc फ़ाइल में रिकॉर्ड किए गए हैश से मैच करता है, तो pyc फ़ाइल का इस्तेमाल करें. यह सुविधा तब सबसे ज़्यादा काम की होती है, जब ऐसे कोड पर काम किया जा रहा हो जिसमें बदलाव किया जा सकता है.
* `unchecked_hash`: हमेशा pyc फ़ाइल का इस्तेमाल करें. साथ ही, pyc फ़ाइल के हैश की तुलना सोर्स फ़ाइल से न करें. यह तब सबसे ज़्यादा काम आता है, जब कोड में बदलाव नहीं किया जाएगा.
pyc को अमान्य करने के मोड के बारे में ज़्यादा जानने के लिए, https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode पर जाएं
|
precompile_optimize_level
|
पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है
पहले से कंपाइल की गई फ़ाइलों के लिए ऑप्टिमाइज़ेशन लेवल.
ऑप्टिमाइज़ेशन लेवल के बारे में ज़्यादा जानकारी के लिए, https://docs.python.org/3/library/functions.html#compile पर जाएं और `compile()` फ़ंक्शन के `optimize` आर्ग्युमेंट के दस्तावेज़ देखें
ध्यान दें: वैल्यू `-1` का मतलब "मौजूदा इंटरप्रेटर" है. यह वह इंटरप्रेटर होगा जिसका इस्तेमाल _बिल्ड के समय, pycs जनरेट होने पर_ किया जाएगा. यह वह इंटरप्रेटर नहीं होगा जिसका इस्तेमाल कोड के रनटाइम के दौरान किया जाता है.
|
precompile_source_retention
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"
यह तय करता है कि किसी सोर्स फ़ाइल को कंपाइल करने के बाद, उस सोर्स फ़ाइल को आउटपुट में शामिल किया जाएगा या नहीं. मान्य वैल्यू ये हैं:
* `inherit`: {flag}`--precompile_source_retention` फ़्लैग से वैल्यू इनहेरिट करें.
* `keep_source`: ओरिजनल Python सोर्स को शामिल करें.
* `omit_source`: ओरिजनल py सोर्स शामिल न करें.
* `omit_if_generated_source`: अगर सोर्स फ़ाइल सामान्य है, तो ओरिजनल सोर्स को बनाए रखें. हालांकि, अगर यह जनरेट की गई फ़ाइल है, तो इसे हटा दें.
|
pyc_collection
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"
यह तय करता है कि डिपेंडेंसी से मिली pyc फ़ाइलों को मैन्युअल तरीके से शामिल किया जाना चाहिए या नहीं.
ध्यान दें: यह सेटिंग सिर्फ़ {flag}`--precompile_add_to_runfiles=decided_elsewhere` के साथ काम करती है.
मान्य वैल्यू ये हैं:
* `inherit`: {flag}`--pyc_collection` से वैल्यू इनहेरिट करें.
* `include_pyc`: बाइनरी में डिपेंडेंसी से pyc फ़ाइलें जोड़ें (इसके लिए, {obj}`PyInfo.transitive_pyc_files` का इस्तेमाल करें.
* `disabled`: डिपेंडेंसी से 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
नियम का सोर्स देखेंopen_in_new
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` के नियम होते हैं.
सिर्फ़ रनटाइम के दौरान इस्तेमाल की जाने वाली डेटा फ़ाइलें देने वाले टारगेट, `data` एट्रिब्यूट के दायरे में आते हैं.
|
srcs
|
लेबल की सूची; डिफ़ॉल्ट [] है
टारगेट बनाने के लिए प्रोसेस की गई Python सोर्स फ़ाइलों की सूची. इसमें, आपका चेक इन किया गया सारा कोड शामिल होता है. साथ ही, इसमें जनरेट की गई सोर्स फ़ाइलें भी शामिल हो सकती हैं. '.py' फ़ाइलें `srcs` में और लाइब्रेरी टारगेट `deps` में होती हैं. रन टाइम के दौरान ज़रूरी हो सकने वाली अन्य बाइनरी फ़ाइलें `data` में होती हैं.
|
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 के हिसाब से होती हैं.
इसमें ऐसे पाथ इस्तेमाल नहीं किए जा सकते जो '/' से शुरू होते हैं. साथ ही, ऐसे पाथ भी इस्तेमाल नहीं किए जा सकते जो एक्सीक्यूशन रूट से ऊपर के पाथ का रेफ़रंस देते हैं. ऐसा करने पर गड़बड़ी का मैसेज दिखेगा.
|
precompile
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"
**इस टारगेट के लिए**, py सोर्स फ़ाइलों को पहले से कंपाइल किया जाना चाहिए या नहीं.
वैल्यू:
* `inherit`: {flag}`--precompile` फ़्लैग से वैल्यू तय करें.
* `enabled`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल करें. ध्यान दें कि
--precompile_add_to_runfiles से, डाउनस्ट्रीम बाइनरी में संकलित फ़ाइलों को शामिल करने के तरीके पर असर पड़ता है.
* `disabled`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल न करें.
* `if_generated_source`: Python सोर्स फ़ाइलों को सिर्फ़ तब कॉम्पाइल करें, जब वे जनरेट की गई फ़ाइल हों.
:::{seealso}
* {flag}`--precompile` फ़्लैग, जो कुछ मामलों में इस एट्रिब्यूट को बदल सकता है
और बिल्ड करते समय सभी टारगेट पर असर डालेगा.
* {obj}`pyc_collection` एट्रिब्यूट, जिससे हर टारगेट के हिसाब से, पहले से कॉम्पाइल करने की सुविधा को ट्रांज़िटिव तरीके से चालू किया जा सकता है.
* पहले से कॉम्पाइल करने की सुविधा का इस्तेमाल करने के बारे में गाइड के लिए, [पहले से कॉम्पाइल करने की सुविधा](precompiling) वाले दस्तावेज़.
:::
|
precompile_invalidation_mode
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "auto"
पहले से कंपाइल की गई फ़ाइलों की पुष्टि कैसे की जानी चाहिए, ताकि यह पता चल सके कि वे अपनी सोर्स फ़ाइलों के साथ अप-टू-डेट हैं या नहीं. ये वैल्यू हो सकती हैं:
* `auto`: असरदार वैल्यू, अन्य बिल्ड सेटिंग के हिसाब से अपने-आप तय हो जाएगी.
* `checked_hash`: अगर सोर्स फ़ाइल का हैश, pyc फ़ाइल में रिकॉर्ड किए गए हैश से मैच करता है, तो pyc फ़ाइल का इस्तेमाल करें. यह सुविधा तब सबसे ज़्यादा काम की होती है, जब ऐसे कोड पर काम किया जा रहा हो जिसमें बदलाव किया जा सकता है.
* `unchecked_hash`: हमेशा pyc फ़ाइल का इस्तेमाल करें. साथ ही, pyc फ़ाइल के हैश की तुलना सोर्स फ़ाइल से न करें. यह तब सबसे ज़्यादा काम आता है, जब कोड में बदलाव नहीं किया जाएगा.
pyc को अमान्य करने के मोड के बारे में ज़्यादा जानने के लिए, https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode पर जाएं
|
precompile_optimize_level
|
पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है
पहले से कंपाइल की गई फ़ाइलों के लिए ऑप्टिमाइज़ेशन लेवल.
ऑप्टिमाइज़ेशन लेवल के बारे में ज़्यादा जानकारी के लिए, https://docs.python.org/3/library/functions.html#compile पर जाएं और `compile()` फ़ंक्शन के `optimize` आर्ग्युमेंट के दस्तावेज़ देखें
ध्यान दें: वैल्यू `-1` का मतलब "मौजूदा इंटरप्रेटर" है. यह वह इंटरप्रेटर होगा जिसका इस्तेमाल _बिल्ड के समय, pycs जनरेट होने पर_ किया जाएगा. यह वह इंटरप्रेटर नहीं होगा जिसका इस्तेमाल कोड के रनटाइम के दौरान किया जाता है.
|
precompile_source_retention
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"
यह तय करता है कि किसी सोर्स फ़ाइल को कंपाइल करने के बाद, उस सोर्स फ़ाइल को आउटपुट में शामिल किया जाएगा या नहीं. मान्य वैल्यू ये हैं:
* `inherit`: {flag}`--precompile_source_retention` फ़्लैग से वैल्यू इनहेरिट करें.
* `keep_source`: ओरिजनल Python सोर्स को शामिल करें.
* `omit_source`: ओरिजनल py सोर्स शामिल न करें.
* `omit_if_generated_source`: अगर सोर्स फ़ाइल सामान्य है, तो ओरिजनल सोर्स को बनाए रखें. हालांकि, अगर यह जनरेट की गई फ़ाइल है, तो इसे हटा दें.
|
srcs_version
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "PY2AND3"
यह सुविधा अब काम नहीं करती और इसका इस्तेमाल नहीं किया जाता.
|
py_test
नियम का सोर्स देखेंopen_in_new
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` एट्रिब्यूट](https://bazel.build/reference/be/common-definitions#typical-attributes) के बारे में टिप्पणियां देखें.
आम तौर पर, ये `py_library` के नियम होते हैं.
सिर्फ़ रनटाइम के दौरान इस्तेमाल की जाने वाली डेटा फ़ाइलें देने वाले टारगेट, `data` एट्रिब्यूट में आते हैं.
|
srcs
|
लेबल की सूची; ज़रूरी है
टारगेट बनाने के लिए प्रोसेस की गई Python सोर्स फ़ाइलों की सूची. इसमें, आपका चेक इन किया गया सारा कोड शामिल होता है. साथ ही, इसमें जनरेट की गई सोर्स फ़ाइलें भी शामिल हो सकती हैं. '.py' फ़ाइलें `srcs` में और लाइब्रेरी टारगेट `deps` में होती हैं. रन टाइम के दौरान ज़रूरी हो सकने वाली अन्य बाइनरी फ़ाइलें `data` में होती हैं.
|
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
|
पूर्णांक; डिफ़ॉल्ट वैल्यू -1 है
runfiles ट्री में, खाली `__init__.py` फ़ाइलें अपने-आप बननी चाहिए या नहीं.
ये हर उस डायरेक्ट्री में बनाई जाती हैं जिसमें Python सोर्स कोड या शेयर की गई लाइब्रेरी होती हैं. साथ ही, ये उन डायरेक्ट्री की हर पैरंट डायरेक्ट्री में बनाई जाती हैं. हालांकि, इनमें रिपॉज़िटरी की रूट डायरेक्ट्री शामिल नहीं होती. डिफ़ॉल्ट तौर पर, `-1` (अपने-आप) का मतलब 'सही' होता है. ऐसा तब तक होता है, जब तक कि `--incompatible_default_to_explicit_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 से, डाउनस्ट्रीम बाइनरी में संकलित फ़ाइलों को शामिल करने के तरीके पर असर पड़ता है.
* `disabled`: बिल्ड के समय Python सोर्स फ़ाइलों को कंपाइल न करें.
* `if_generated_source`: Python सोर्स फ़ाइलों को सिर्फ़ तब कॉम्पाइल करें, जब वे जनरेट की गई फ़ाइल हों.
:::{seealso}
* {flag}`--precompile` फ़्लैग, जो कुछ मामलों में इस एट्रिब्यूट को बदल सकता है
और बिल्ड करते समय सभी टारगेट पर असर डालेगा.
* {obj}`pyc_collection` एट्रिब्यूट, जिससे हर टारगेट के हिसाब से, पहले से कॉम्पाइल करने की सुविधा को ट्रांज़िटिव तरीके से चालू किया जा सकता है.
* पहले से कॉम्पाइल करने की सुविधा का इस्तेमाल करने के बारे में गाइड के लिए, [पहले से कॉम्पाइल करने की सुविधा](precompiling) वाले दस्तावेज़.
:::
|
precompile_invalidation_mode
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "auto"
पहले से कंपाइल की गई फ़ाइलों की पुष्टि कैसे की जानी चाहिए, ताकि यह पता चल सके कि वे अपनी सोर्स फ़ाइलों के साथ अप-टू-डेट हैं या नहीं. ये वैल्यू हो सकती हैं:
* `auto`: असरदार वैल्यू, अन्य बिल्ड सेटिंग के हिसाब से अपने-आप तय हो जाएगी.
* `checked_hash`: अगर सोर्स फ़ाइल का हैश, pyc फ़ाइल में रिकॉर्ड किए गए हैश से मैच करता है, तो pyc फ़ाइल का इस्तेमाल करें. यह सुविधा तब सबसे ज़्यादा काम की होती है, जब ऐसे कोड पर काम किया जा रहा हो जिसमें बदलाव किया जा सकता है.
* `unchecked_hash`: हमेशा pyc फ़ाइल का इस्तेमाल करें. साथ ही, pyc फ़ाइल के हैश की तुलना सोर्स फ़ाइल से न करें. यह तब सबसे ज़्यादा काम आता है, जब कोड में बदलाव नहीं किया जाएगा.
pyc को अमान्य करने के मोड के बारे में ज़्यादा जानने के लिए, https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode पर जाएं
|
precompile_optimize_level
|
पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है
पहले से कंपाइल की गई फ़ाइलों के लिए ऑप्टिमाइज़ेशन लेवल.
ऑप्टिमाइज़ेशन लेवल के बारे में ज़्यादा जानकारी के लिए, https://docs.python.org/3/library/functions.html#compile पर जाएं और `compile()` फ़ंक्शन के `optimize` आर्ग्युमेंट के दस्तावेज़ देखें
ध्यान दें: वैल्यू `-1` का मतलब "मौजूदा इंटरप्रेटर" है. यह वह इंटरप्रेटर होगा जिसका इस्तेमाल _बिल्ड के समय, pycs जनरेट होने पर_ किया जाएगा. यह वह इंटरप्रेटर नहीं होगा जिसका इस्तेमाल कोड के रनटाइम के दौरान किया जाता है.
|
precompile_source_retention
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"
यह तय करता है कि किसी सोर्स फ़ाइल को कंपाइल करने के बाद, उस सोर्स फ़ाइल को आउटपुट में शामिल किया जाएगा या नहीं. मान्य वैल्यू ये हैं:
* `inherit`: {flag}`--precompile_source_retention` फ़्लैग से वैल्यू इनहेरिट करें.
* `keep_source`: ओरिजनल Python सोर्स को शामिल करें.
* `omit_source`: ओरिजनल py सोर्स शामिल न करें.
* `omit_if_generated_source`: अगर सोर्स फ़ाइल सामान्य है, तो ओरिजनल सोर्स को बनाए रखें. हालांकि, अगर यह जनरेट की गई फ़ाइल है, तो इसे हटा दें.
|
pyc_collection
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "inherit"
यह तय करता है कि डिपेंडेंसी से मिली pyc फ़ाइलों को मैन्युअल तरीके से शामिल किया जाना चाहिए या नहीं.
ध्यान दें: यह सेटिंग सिर्फ़ {flag}`--precompile_add_to_runfiles=decided_elsewhere` के साथ काम करती है.
मान्य वैल्यू ये हैं:
* `inherit`: {flag}`--pyc_collection` से वैल्यू इनहेरिट करें.
* `include_pyc`: बाइनरी में डिपेंडेंसी से pyc फ़ाइलें जोड़ें (इसके लिए, {obj}`PyInfo.transitive_pyc_files` का इस्तेमाल करें.
* `disabled`: डिपेंडेंसी से pyc फ़ाइलों को साफ़ तौर पर न जोड़ें. ध्यान दें कि अगर कोई टारगेट, pyc फ़ाइलों को अपने रनफ़ाइल के हिस्से के तौर पर शामिल करता है, तो वे अब भी डिपेंडेंसी से आ सकती हैं. जैसे, {obj}`--precompile_add_to_runfiles=always` का इस्तेमाल करने पर.
|
python_version
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "PY3"
यह सुविधा अब काम नहीं करती और इसका इस्तेमाल नहीं किया जाता.
|
srcs_version
|
स्ट्रिंग; डिफ़ॉल्ट रूप से "PY2AND3"
यह सुविधा अब काम नहीं करती और इसका इस्तेमाल नहीं किया जाता.
|
stamp
|
पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है
बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. ये वैल्यू हो सकती हैं:
* `stamp = 1`: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. भले ही, `--nostamp` बिल्ड में भी ऐसा किया जाए. **इस सेटिंग से बचना चाहिए**, क्योंकि इससे बाइनरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल बंद हो सकता है.
* `stamp = 0`: हमेशा बिल्ड की जानकारी को कॉन्सटेंट वैल्यू से बदलें. इससे, बेहतर तरीके से बने नतीजों को कैश मेमोरी में सेव किया जा सकता है.
* `stamp = -1`: बाइल्ड की जानकारी को एम्बेड करने की सुविधा को `--[no]stamp` फ़्लैग से कंट्रोल किया जाता है.
स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो जाए.
चेतावनी: स्टैंपिंग की वजह से कैश मेमोरी में हिट की संख्या कम हो सकती है. इससे बिल्ड की परफ़ॉर्मेंस पर असर पड़ सकता है. इसलिए, अगर हो सके, तो स्टैंपिंग से बचें.
|
py_runtime
नियम का सोर्स देखेंopen_in_new
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 स्क्रिप्ट को चलाने में सक्षम होती है. साथ ही, यह स्टैंडर्ड CPython इंटरप्रेटर के नियमों का पालन करती है.
प्लैटफ़ॉर्म का रनटाइम, अपने-आप सुरक्षित नहीं होता. यह टारगेट प्लैटफ़ॉर्म पर, किसी खास पाथ पर इंटरप्रिटर मौजूद होने की ज़रूरी शर्त लागू करता है. इन-बिल्ड रनटाइम, हर्मेटिक हो सकता है या नहीं. यह इस बात पर निर्भर करता है कि यह, चेक-इन किए गए इंटरप्रिटर पर ले जाता है या सिस्टम इंटरप्रिटर को ऐक्सेस करने वाली रैपर स्क्रिप्ट पर.
उदाहरण
```
load("@rules_python//python:py_runtime.bzl", "py_runtime")
py_runtime(
name = "python-2.7.12",
files = glob(["python-2.7.12/**"]),
interpreter = "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 के नियमों को Bazel से बाहर ले जाया जाएगा, तब इसका इस्तेमाल करना ज़रूरी हो जाएगा.
बड़े किए गए वेरिएबल के सटीक नाम, एक अस्थिर एपीआई हैं और इनमें बदलाव हो सकता है.
Python के नियमों को Bazel से हटाने के बाद, एपीआई ज़्यादा स्टेबल हो जाएगा.
ज़्यादा वैरिएबल के लिए, @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) की कमांड लाइन आर्ग्युमेंट स्वीकार करनी चाहिए. इसमें कम से कम, `run` और `lcov` सब-कमांड शामिल होने चाहिए.
|
files
|
लेबल की सूची; डिफ़ॉल्ट [] है
इन-बिल्ड रनटाइम के लिए, यह इस रनटाइम की फ़ाइलों का सेट होता है.
इन फ़ाइलों को, इस रनटाइम का इस्तेमाल करने वाली Python बाइनरी के रनफ़ाइल में जोड़ दिया जाएगा. प्लैटफ़ॉर्म के रनटाइम के लिए, यह एट्रिब्यूट सेट नहीं किया जाना चाहिए.
|
implementation_name
|
स्ट्रिंग; डिफ़ॉल्ट रूप से ""
Python लागू करने का नाम (`sys.implementation.name`)
|
interpreter
|
लेबल; डिफ़ॉल्ट None है
इन-बिल्ड रनटाइम के लिए, यह टारगेट है जिसे इंटरप्रेटर के तौर पर लागू किया जाता है. यह इनमें से कोई एक हो सकता है:
* एक फ़ाइल, जो इंटरप्रेटर बाइनरी होगी. यह माना जाता है कि ऐसे interpreter, एक फ़ाइल वाले ऐसे ऐप्लिकेशन होते हैं जिनमें सभी ज़रूरी फ़ाइलें मौजूद होती हैं या फिर `files` में उनसे जुड़ी सभी ज़रूरी फ़ाइलों के बारे में बताया गया होता है.
* कोई ऐसा टारगेट जिसे चलाया जा सकता हो. टारगेट का एक्सीक्यूटेबल, इंटरप्रेटर बाइनरी होगा.
कोई भी अन्य डिफ़ॉल्ट आउटपुट (`target.files`) और सामान्य फ़ाइलें, रनफ़ाइलें
(`runfiles.files`) अपने-आप शामिल हो जाएंगी, जैसे कि
`files` एट्रिब्यूट में बताया गया हो.
ध्यान दें: हो सकता है कि टारगेट के रनफ़ाइल को अब तक टूलचैन/इंटरप्रेटर के उपभोक्ताओं के लिए सही तरीके से लागू/प्रचारित न किया गया हो. इसके बारे में ज़्यादा जानने के लिए,
bazelbuild/rules_python/issues/1612 पर जाएं
प्लैटफ़ॉर्म के रनटाइम (यानी `interpreter_path` सेट किया जा रहा है) के लिए, यह एट्रिब्यूट सेट नहीं किया जाना चाहिए.
|
interpreter_path
|
स्ट्रिंग; डिफ़ॉल्ट रूप से ""
प्लैटफ़ॉर्म के रनटाइम के लिए, यह टारगेट प्लैटफ़ॉर्म पर मौजूद Python इंटरप्रेटर का ऐब्सलूट पाथ होता है. इन-बिल्ड रनटाइम के लिए, यह एट्रिब्यूट सेट नहीं किया जाना चाहिए.
|
interpreter_version_info
|
डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; डिफ़ॉल्ट तौर पर {}
इस रनटाइम से मिलने वाले इंटरप्रिटर के वर्शन की जानकारी.
अगर यह नहीं बताया गया है, तो {obj}`--python_version` का इस्तेमाल किया जाता है
काम करने वाली कुंजियां, `sys.version_info` के नाम से मेल खाती हैं. इनपुट वैल्यू स्ट्रिंग होती हैं, लेकिन ज़्यादातर को int में बदल दिया जाता है. इस्तेमाल की जा सकने वाली कुंजियां:
* major: int, मुख्य वर्शन का नंबर
* minor: int, मामूली वर्शन का नंबर
* micro: वैकल्पिक int, मामूली वर्शन का नंबर
* releaselevel: वैकल्पिक str, रिलीज़ लेवल
* serial: वैकल्पिक int, रिलीज़ का सीरियल नंबर
:::{versionchanged} 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"` हैं.
डिफ़ॉल्ट वैल्यू को `--incompatible_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/bazelbuild/bazel/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` फ़ील्ड.
:::
|
