इस पेज का अनुवाद Cloud Translation API से किया गया है.

Python नियम

नियम

py_binary
py_library
py_test
py_runtime

py_बाइनरी

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, python_version, restricted_to, srcs_version, stamp, tags, target_compatible_with, testonly, toolchains, visibility)

py_binary एक ऐसा Python प्रोग्राम है जिसे चलाया जा सकता है. इसमें .py सोर्स फ़ाइलों का संग्रह होता है. इसमें शायद अन्य py_library नियम हो सकते हैं. साथ ही, यह एक *.runfiles डायरेक्ट्री ट्री होता है, जिसमें रन टाइम के दौरान ज़रूरी सभी कोड और डेटा होता है. साथ ही, इसमें स्टब स्क्रिप्ट होती है जो शुरू के सही एनवायरमेंट और डेटा के साथ प्रोग्राम शुरू करती है.

उदाहरण

py_binary(
    name = "foo",
    srcs = ["foo.py"],
    data = [":transform"],  # a cc_binary which we invoke at run time
    deps = [
        ":foolib",  # a py_library
    ],
)

अगर आप किसी अन्य बाइनरी या टेस्ट से py_binary चलाना चाहते हैं (उदाहरण के लिए, किसी java_test में कुछ मॉक रिसॉर्स सेट अप करने के लिए Python की बाइनरी चलाना), तो सही तरीका है कि उसके बाइनरी या टेस्ट को उसके डेटा सेक्शन में py_binary पर निर्भर कर दिया जाए. इसके बाद, दूसरी बाइनरी सोर्स डायरेक्ट्री से मिलती-जुलती py_binary को ढूंढ सकती है.

py_binary(
    name = "test_main",
    srcs = ["test_main.py"],
    deps = [":testing"],
)

java_library(
    name = "testing",
    srcs = glob(["*.java"]),
    data = [":test_main"]
)

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम. अगर `main` नहीं बताया गया है, तो यह उस सोर्स फ़ाइल का नाम होना चाहिए जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट है. यहां से, एक्सटेंशन की वैल्यू घटा दी जाती है. उदाहरण के लिए, अगर आपके एंट्री पॉइंट को `main.py` कहा जाता है, तो आपका नाम `main` होना चाहिए.
`deps`	`List of labels; optional` बाइनरी लक्ष्य से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. `deps` के बारे में टिप्पणियां देखें. यहां बिल्डिंग के ज़्यादातर नियमों से तय होने वाले सामान्य एट्रिब्यूट पर जाएं. आम तौर पर, ये `py_library` नियम होते हैं.
`srcs`	`List of labels; required` सोर्स (`.py`) फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. इसमें, आपके चेक इन किए गए सभी कोड और जनरेट की गई सभी सोर्स फ़ाइलें शामिल होती हैं. लाइब्रेरी टारगेट, `deps` में जोड़े जाते हैं. रनटाइम के लिए ज़रूरी अन्य बाइनरी फ़ाइलें `data` में मौजूद होती हैं.
`imports`	`List of strings; optional` `PYTHONPATH` में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के तहत. ये इंपोर्ट डायरेक्ट्री, इस नियम और इस पर निर्भर सभी नियमों के लिए जोड़ी जाएंगी. ध्यान दें: ये नियम इन नियमों पर निर्भर नहीं होते. हर नियम को इस नियम के हिसाब से बने `py_binary` नियमों के हिसाब से, `PYTHONPATH` में जोड़ा जाएगा. ऐब्सलूट पाथ (`/` से शुरू होने वाले पाथ) और एक्ज़ीक्यूशन रूट के ऊपर बने पाथ की अनुमति नहीं है. इस वजह से गड़बड़ी हो जाती है.
`legacy_create_init`	`Integer; optional; default is -1` रनलिस्ट फ़ाइल में, इंप्लिसिट तरीके से खाली __init__.py फ़ाइलें बनाना है या नहीं. ये Python सोर्स कोड या शेयर की गई लाइब्रेरी वाली हर डायरेक्ट्री में बनाए जाते हैं. साथ ही, ये डायरेक्ट्री की हर पैरंट डायरेक्ट्री में भी बनाए जाते हैं. इसमें, repo रूट डायरेक्ट्री शामिल नहीं होती है. डिफ़ॉल्ट, ऑटो, का मतलब है कि जब तक `--incompatible_default_to_explicit_init_py` का इस्तेमाल नहीं किया जाता, तब तक यह सही है. गलत होने पर, उपयोगकर्ता (संभावित रूप से खाली) __init__.py फ़ाइलें बनाने और उन्हें Python टारगेट के `srcs` में जोड़ने के लिए ज़िम्मेदार होता है.
`main`	`Label; optional` उस सोर्स फ़ाइल का नाम जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट है. इस फ़ाइल को `srcs` की सूची में भी शामिल किया जाना चाहिए. अगर जानकारी नहीं दी गई है, तो `name` का इस्तेमाल किया जाता है (ऊपर देखें). अगर `name` का मिलान `srcs` की फ़ाइल के किसी नाम से नहीं होता है, तो `main` की जानकारी देनी होगी.
`python_version`	`String; optional; nonconfigurable; default is "_INTERNAL_SENTINEL"` Python 2 या Python 3 के लिए, इस टारगेट (और इसके ट्रांज़िटिव `deps`) को बनाना है. `"PY2"` और `"PY3"` को डिफ़ॉल्ट रूप से इस्तेमाल किया जा सकता है. Python वर्शन हमेशा (शायद डिफ़ॉल्ट रूप से) इस एट्रिब्यूट की ओर से तय किए गए किसी भी वर्शन पर रीसेट किया जाता है. भले ही, कमांड लाइन पर दिया गया कोई वर्शन या इस पर निर्भर दूसरे टारगेट हों. अगर आप मौजूदा Python वर्शन पर `select()` करना चाहते हैं, तो आप `@rules_python//python:python_version` की वैल्यू देख सकते हैं. ज़्यादा जानकारी के लिए यहां देखें. गड़बड़ी की चेतावनी: यह एट्रिब्यूट उस वर्शन को सेट करता है जिसके लिए बेज़ल आपका टारगेट बनाता है, लेकिन #4815 की वजह से, स्टब स्क्रिप्ट रनटाइम के दौरान अनुवादक का गलत वर्शन चालू कर सकती है. यह तरीका देखें. इसमें, एक ऐसा `py_runtime` टारगेट तय करना है जो Python के वर्शन को ज़रूरत के हिसाब से दिखाता हो. साथ ही, `--python_top` को सेट करके, इस `py_runtime` को चालू करता हो.
`srcs_version`	`String; optional; default is "PY2AND3"` इस एट्रिब्यूट में बताया गया है कि टारगेट `srcs` के Python, 3, या दोनों के साथ काम करता है. असल में Python रनटाइम वर्शन सेट करने के लिए, एक्ज़ीक्यूटेबल Python नियम (`py_binary` या `py_test`) के `python_version` एट्रिब्यूट का इस्तेमाल करें. `"PY2AND3"`, `"PY2"`, और `"PY3"` को वैल्यू के तौर पर इस्तेमाल किया जा सकता है. ऐतिहासिक वजहों से, `"PY2ONLY"` और `"PY3ONLY"` वैल्यू की भी अनुमति है. हालांकि, ये `"PY2"` और `"PY3"` के जैसे ही हैं और इनसे बचना चाहिए. ध्यान दें कि सिर्फ़ एक्ज़ीक्यूटेबल नियमों (`py_binary` और `py_library`) से ही Python का मौजूदा वर्शन पुष्टि होती है. (यह एक सुविधा है; `py_library` से Python का मौजूदा वर्शन नहीं बदलता है. अगर ऐसा होता है, तो `PY2ONLY` और `PY3ONLY` दोनों को एक ही वर्शन में बनाना मुश्किल होगा.) इसके अलावा, अगर कोई वर्शन मेल नहीं खाता, तो गड़बड़ी को सिर्फ़ एक्ज़ीक्यूशन के चरण में रिपोर्ट किया जाता है. खास तौर पर, `bazel build --nobuild` गड़बड़ी में गड़बड़ी नहीं दिखेगी.) किन डिपेंडेंसी के लिए वर्शन से जुड़ी ज़रूरी शर्तें पूरी होती हैं, इसकी जानकारी पाने के लिए, आप अपने टारगेट पर `find_requirements` आसपेक्ट रेशियो चला सकते हैं: bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo इससे सफ़िक्स `-pyversioninfo.txt` वाली फ़ाइल बनेगी. इसमें यह बताया जाएगा कि आपके टारगेट के लिए, Python या अन्य में से किस वर्शन की ज़रूरत है. ध्यान दें कि यह तब भी काम करता है, जब वर्शन से जुड़े विवाद की वजह से, दिया गया टारगेट पूरा नहीं हो पाता.
`stamp`	`Integer; optional; default is -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, restricted_to, srcs_version, tags, target_compatible_with, testonly, visibility)

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`deps`	`List of labels; optional` बाइनरी लक्ष्य से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. `deps` के बारे में टिप्पणियां देखें. यहां बिल्डिंग के ज़्यादातर नियमों से तय होने वाले सामान्य एट्रिब्यूट पर जाएं. आम तौर पर, ये `py_library` नियम होते हैं.
`srcs`	`List of labels; optional` सोर्स (`.py`) फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. इसमें, आपके चेक इन किए गए सभी कोड और जनरेट की गई सभी सोर्स फ़ाइलें शामिल होती हैं.
`imports`	`List of strings; optional` `PYTHONPATH` में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के तहत. ये इंपोर्ट डायरेक्ट्री, इस नियम और इस पर निर्भर सभी नियमों के लिए जोड़ी जाएंगी. ध्यान दें: ये नियम इन नियमों पर निर्भर नहीं होते. हर नियम को इस नियम के हिसाब से बने `py_binary` नियमों के हिसाब से, `PYTHONPATH` में जोड़ा जाएगा. ऐब्सलूट पाथ (`/` से शुरू होने वाले पाथ) और एक्ज़ीक्यूशन रूट के ऊपर बने पाथ की अनुमति नहीं है. इस वजह से गड़बड़ी हो जाती है.
`srcs_version`	`String; optional; default is "PY2AND3"` इस एट्रिब्यूट में बताया गया है कि टारगेट `srcs` के Python, 3, या दोनों के साथ काम करता है. असल में Python रनटाइम वर्शन सेट करने के लिए, एक्ज़ीक्यूटेबल Python नियम (`py_binary` या `py_test`) के `python_version` एट्रिब्यूट का इस्तेमाल करें. `"PY2AND3"`, `"PY2"`, और `"PY3"` को वैल्यू के तौर पर इस्तेमाल किया जा सकता है. ऐतिहासिक वजहों से, `"PY2ONLY"` और `"PY3ONLY"` वैल्यू की भी अनुमति है. हालांकि, ये `"PY2"` और `"PY3"` के जैसे ही हैं और इनसे बचना चाहिए. ध्यान दें कि सिर्फ़ एक्ज़ीक्यूटेबल नियमों (`py_binary` और `py_library`) से ही Python का मौजूदा वर्शन पुष्टि होती है. (यह एक सुविधा है; `py_library` से Python का मौजूदा वर्शन नहीं बदलता है. अगर ऐसा होता है, तो `PY2ONLY` और `PY3ONLY` दोनों को एक ही वर्शन में बनाना मुश्किल होगा.) इसके अलावा, अगर कोई वर्शन मेल नहीं खाता, तो गड़बड़ी को सिर्फ़ एक्ज़ीक्यूशन के चरण में रिपोर्ट किया जाता है. खास तौर पर, `bazel build --nobuild` गड़बड़ी में गड़बड़ी नहीं दिखेगी.) किन डिपेंडेंसी के लिए वर्शन से जुड़ी ज़रूरी शर्तें पूरी होती हैं, इसकी जानकारी पाने के लिए, आप अपने टारगेट पर `find_requirements` आसपेक्ट रेशियो चला सकते हैं: bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo इससे सफ़िक्स `-pyversioninfo.txt` वाली फ़ाइल बनेगी. इसमें यह बताया जाएगा कि आपके टारगेट के लिए, Python या अन्य में से किस वर्शन की ज़रूरत है. ध्यान दें कि यह तब भी काम करता है, जब वर्शन से जुड़े विवाद की वजह से, दिया गया टारगेट पूरा नहीं हो पाता.

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, python_version, restricted_to, shard_count, size, srcs_version, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility)

py_test() नियम टेस्ट को कंपाइल करता है. टेस्ट, कुछ टेस्ट कोड के आस-पास मौजूद बाइनरी रैपर होता है.

उदाहरण

py_test(
    name = "runtest_test",
    srcs = ["runtest_test.py"],
    deps = [
        "//path/to/a/py/library",
    ],
)

मुख्य मॉड्यूल भी बनाया जा सकता है:

py_test(
    name = "runtest_test",
    srcs = [
        "runtest_main.py",
        "runtest_lib.py",
    ],
    main = "runtest_main.py",
)

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`deps`	`List of labels; optional` बाइनरी लक्ष्य से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. `deps` के बारे में टिप्पणियां देखें. यहां बिल्डिंग के ज़्यादातर नियमों से तय होने वाले सामान्य एट्रिब्यूट पर जाएं. आम तौर पर, ये `py_library` नियम होते हैं.
`srcs`	`List of labels; required` सोर्स (`.py`) फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. इसमें, आपके चेक इन किए गए सभी कोड और जनरेट की गई सभी सोर्स फ़ाइलें शामिल होती हैं. लाइब्रेरी टारगेट, `deps` में जोड़े जाते हैं. रनटाइम के लिए ज़रूरी अन्य बाइनरी फ़ाइलें `data` में मौजूद होती हैं.
`imports`	`List of strings; optional` `PYTHONPATH` में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प के तहत. ये इंपोर्ट डायरेक्ट्री, इस नियम और इस पर निर्भर सभी नियमों के लिए जोड़ी जाएंगी. ध्यान दें: ये नियम इन नियमों पर निर्भर नहीं होते. हर नियम को इस नियम के हिसाब से बने `py_binary` नियमों के हिसाब से, `PYTHONPATH` में जोड़ा जाएगा. ऐब्सलूट पाथ (`/` से शुरू होने वाले पाथ) और एक्ज़ीक्यूशन रूट के ऊपर बने पाथ की अनुमति नहीं है. इस वजह से गड़बड़ी हो जाती है.
`legacy_create_init`	`Integer; optional; default is -1` रनलिस्ट फ़ाइल में, इंप्लिसिट तरीके से खाली __init__.py फ़ाइलें बनाना है या नहीं. ये Python सोर्स कोड या शेयर की गई लाइब्रेरी वाली हर डायरेक्ट्री में बनाए जाते हैं. साथ ही, ये डायरेक्ट्री की हर पैरंट डायरेक्ट्री में भी बनाए जाते हैं. इसमें, repo रूट डायरेक्ट्री शामिल नहीं होती है. डिफ़ॉल्ट, ऑटो, का मतलब है कि जब तक `--incompatible_default_to_explicit_init_py` का इस्तेमाल नहीं किया जाता, तब तक यह सही है. गलत होने पर, उपयोगकर्ता (संभावित रूप से खाली) __init__.py फ़ाइलें बनाने और उन्हें Python टारगेट के `srcs` में जोड़ने के लिए ज़िम्मेदार होता है.
`main`	`Label; optional` उस सोर्स फ़ाइल का नाम जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट है. इस फ़ाइल को `srcs` की सूची में भी शामिल किया जाना चाहिए. अगर जानकारी नहीं दी गई है, तो `name` का इस्तेमाल किया जाता है (ऊपर देखें). अगर `name` का मिलान `srcs` की फ़ाइल के किसी नाम से नहीं होता है, तो `main` की जानकारी देनी होगी.
`python_version`	`String; optional; nonconfigurable; default is "_INTERNAL_SENTINEL"` Python 2 या Python 3 के लिए, इस टारगेट (और इसके ट्रांज़िटिव `deps`) को बनाना है. `"PY2"` और `"PY3"` को डिफ़ॉल्ट रूप से इस्तेमाल किया जा सकता है. Python वर्शन हमेशा (शायद डिफ़ॉल्ट रूप से) इस एट्रिब्यूट की ओर से तय किए गए किसी भी वर्शन पर रीसेट किया जाता है. भले ही, कमांड लाइन पर दिया गया कोई वर्शन या इस पर निर्भर दूसरे टारगेट हों. अगर आप मौजूदा Python वर्शन पर `select()` करना चाहते हैं, तो आप `@rules_python//python:python_version` की वैल्यू देख सकते हैं. ज़्यादा जानकारी के लिए यहां देखें. गड़बड़ी की चेतावनी: यह एट्रिब्यूट उस वर्शन को सेट करता है जिसके लिए बेज़ल आपका टारगेट बनाता है, लेकिन #4815 की वजह से, स्टब स्क्रिप्ट रनटाइम के दौरान अनुवादक का गलत वर्शन चालू कर सकती है. यह तरीका देखें. इसमें, एक ऐसा `py_runtime` टारगेट तय करना है जो Python के वर्शन को ज़रूरत के हिसाब से दिखाता हो. साथ ही, `--python_top` को सेट करके, इस `py_runtime` को चालू करता हो.
`srcs_version`	`String; optional; default is "PY2AND3"` इस एट्रिब्यूट में बताया गया है कि टारगेट `srcs` के Python, 3, या दोनों के साथ काम करता है. असल में Python रनटाइम वर्शन सेट करने के लिए, एक्ज़ीक्यूटेबल Python नियम (`py_binary` या `py_test`) के `python_version` एट्रिब्यूट का इस्तेमाल करें. `"PY2AND3"`, `"PY2"`, और `"PY3"` को वैल्यू के तौर पर इस्तेमाल किया जा सकता है. ऐतिहासिक वजहों से, `"PY2ONLY"` और `"PY3ONLY"` वैल्यू की भी अनुमति है. हालांकि, ये `"PY2"` और `"PY3"` के जैसे ही हैं और इनसे बचना चाहिए. ध्यान दें कि सिर्फ़ एक्ज़ीक्यूटेबल नियमों (`py_binary` और `py_library`) से ही Python का मौजूदा वर्शन पुष्टि होती है. (यह एक सुविधा है; `py_library` से Python का मौजूदा वर्शन नहीं बदलता है. अगर ऐसा होता है, तो `PY2ONLY` और `PY3ONLY` दोनों को एक ही वर्शन में बनाना मुश्किल होगा.) इसके अलावा, अगर कोई वर्शन मेल नहीं खाता, तो गड़बड़ी को सिर्फ़ एक्ज़ीक्यूशन के चरण में रिपोर्ट किया जाता है. खास तौर पर, `bazel build --nobuild` गड़बड़ी में गड़बड़ी नहीं दिखेगी.) किन डिपेंडेंसी के लिए वर्शन से जुड़ी ज़रूरी शर्तें पूरी होती हैं, इसकी जानकारी पाने के लिए, आप अपने टारगेट पर `find_requirements` आसपेक्ट रेशियो चला सकते हैं: bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo इससे सफ़िक्स `-pyversioninfo.txt` वाली फ़ाइल बनेगी. इसमें यह बताया जाएगा कि आपके टारगेट के लिए, Python या अन्य में से किस वर्शन की ज़रूरत है. ध्यान दें कि यह तब भी काम करता है, जब वर्शन से जुड़े विवाद की वजह से, दिया गया टारगेट पूरा नहीं हो पाता.
`stamp`	`Integer; optional; default is 0` py_binary() आर्ग्युमेंट का सेक्शन देखें. इसमें, सिर्फ़ टेस्ट के लिए, स्टैंप का तर्क 0 पर सेट होता है.

py_runtime

नियम का सोर्स देखें

py_runtime(name, bootstrap_template, compatible_with, coverage_tool, deprecation, distribs, features, files, interpreter, interpreter_path, licenses, python_version, restricted_to, stub_shebang, tags, target_compatible_with, testonly, visibility)

यह उस Python रनटाइम को दिखाता है जिसका इस्तेमाल Python कोड को चलाने के लिए किया जाता है.

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

प्लैटफ़ॉर्म रनटाइम, अपने-आप काम करता है. यह टारगेट प्लैटफ़ॉर्म पर एक ज़रूरी शर्त लागू करता है. इसके लिए अनुवादक को एक खास पाथ पर ले जाना होता है. इन-बिल्ड रनटाइम "हेमेटिक" हो सकता है या नहीं. यह इस बात पर निर्भर करता है कि सिस्टम में इस्तेमाल किए गए अनुवादक टूल, चेक किए गए अनुवादक पेज पर ले जाते हैं या रैपर स्क्रिप्ट.

उदाहरण:

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`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`bootstrap_template`	`Label; optional; default is @bazel_tools//tools/python:python_bootstrap_template.txt` पहले इसे "Python स्टब स्क्रिप्ट" कहा जाता था. यह हर Python एक्ज़ीक्यूटेबल टारगेट के लिए, एंट्रीपॉइंट है.
`coverage_tool`	`Label; optional` इस टारगेट का इस्तेमाल, `py_binary` और `py_test` टारगेट से कोड कवरेज की जानकारी इकट्ठा करने के लिए किया जाता है. सेट होने पर, टारगेट को एक फ़ाइल या एक्ज़ीक्यूटेबल टारगेट बनाना होगा. Python कवरेज टूल के लिए एंट्री पॉइंट, सिंगल फ़ाइल का पाथ या टारगेट एक्ज़ीक्यूटेबल हो. टारगेट के साथ-साथ इसकी रनफ़ाइल को कवरेज के चालू होने पर, रनफ़ाइल में जोड़ दिया जाएगा. टूल में एंट्री पॉइंट पर पाइथन अनुवादक (जैसे, `.py` या `.pyc` फ़ाइल) लोड होना चाहिए. इसे कवरेज.py के कमांड लाइन आर्ग्युमेंट को स्वीकार करना होगा. साथ ही, कम से कम `run` और `lcov` सबकॉमैंड को शामिल करना होगा.
`files`	`List of labels; optional` बिल्ड-इन रनटाइम के लिए, यह इस रनटाइम वाली फ़ाइलों का सेट होता है. ये फ़ाइलें, इस Python का इस्तेमाल करने वाली Python फ़ाइलों की रनफ़ाइल में जोड़ दी जाएंगी. प्लैटफ़ॉर्म रनटाइम के लिए, यह एट्रिब्यूट सेट नहीं होना चाहिए.
`interpreter`	`Label; optional` इन-बिल्ड रनटाइम के लिए, यह वह लक्ष्य है जिसे अनुवादक के तौर पर इस्तेमाल किया जा सकता है. प्लैटफ़ॉर्म रनटाइम के लिए, यह एट्रिब्यूट सेट नहीं होना चाहिए.
`interpreter_path`	`String; optional` प्लैटफ़ॉर्म रनटाइम के लिए, यह टारगेट प्लैटफ़ॉर्म पर Python अनुवादक का सटीक पाथ है. बिल्ड-इन रनटाइम के लिए, इस एट्रिब्यूट को सेट नहीं करना चाहिए.
`python_version`	`String; optional; default is "_INTERNAL_SENTINEL"` यह रनटाइम Python मेजर वर्शन 2 या 3 के लिए है या नहीं. `"PY2"` और `"PY3"` मान्य वैल्यू हैं. डिफ़ॉल्ट वैल्यू को `--incompatible_py3_is_default` फ़्लैग से कंट्रोल किया जाता है. हालांकि, आने वाले समय में यह एट्रिब्यूट ज़रूरी होगा और उसकी कोई डिफ़ॉल्ट वैल्यू नहीं होगी.
`stub_shebang`	`String; optional; default is "#!/usr/bin/env python3"` "Shebang" एक्सप्रेशन, `py_binary` टारगेट को एक्ज़ीक्यूट करते समय इस्तेमाल की जाने वाली बूटस्ट्रैपिंग Python स्क्रिप्ट के पहले देता है. ज़्यादा जानकारी के लिए, समस्या 8685 देखें. Windows पर लागू नहीं होता है.