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

Python नियम

नियम

py_binary
py_library
py_test
py_रनटाइम

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, 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 चलाना चाहते हैं (उदाहरण के लिए, किसी Python_टेस्ट में कुछ नकली संसाधन को सेट अप करने के लिए पाइथन बाइनरी चलाना), तो दूसरे बाइनरी या टेस्ट, अपने डेटा सेक्शन की py_binary पर निर्भर करता है. इसके बाद अन्य बाइनरी स्रोत डायरेक्ट्री के मुताबिक py_binary खोज सकती है.

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

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 स्रोत कोड या शेयर की गई लाइब्रेरी वाली हर डायरेक्ट्री में बनाई जाती हैं. साथ ही, रेपो रूट रूट को छोड़कर इन डायरेक्ट्री की हर पैरंट डायरेक्ट्री भी बनाई जाती हैं. डिफ़ॉल्ट, अपने-आप, तब तक सही होता है, जब तक कि `--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"` क्या यह टारगेट बनाना है (और उसका ट्रांज़िट`deps` Python 2 या Python के लिए) 3. `"PY2"` और `"PY3"` (डिफ़ॉल्ट मान) मान्य हैं. Python का वर्शन हमेशा इस विशेषता में बताए गए किसी भी वर्शन पर रीसेट (डिफ़ॉल्ट तौर पर) होता है. भले ही, निर्देश लाइन में दिए गए वर्शन या इस पर आधारित दूसरे टारगेट की वजह से ऐसा हो. अगर आप Python के मौजूदा वर्शन में `select()` चाहते हैं, तो आप `@rules_python//python:python_version` की वैल्यू देख सकते हैं. ज़्यादा जानकारी के लिए यहां देखें. गड़बड़ी की चेतावनी: यह एट्रिब्यूट उस वर्शन को सेट करता है जिसके लिए Bezel आपका टारगेट बनाता है. हालांकि, #4815 की वजह से, नतीजे में मौजूद स्टब स्क्रिप्ट अब भी गलत हो सकती है रनटाइम पर अनुवादक मोड का वर्शन. यह हल देखें, जिसमें ज़रूरत के मुताबिक Python के लिए वर्शन बनाने वाले `py_runtime` टारगेट के बारे में बताया गया है. साथ ही, सेटिंग के हिसाब से इस `py_runtime` को चालू किया जा सकता है `--python_top`.
`srcs_version`	`String; optional; default is "PY2AND3"` यह एट्रिब्यूट, टारगेट के `srcs` को Python 2, Python 3 या दोनों के साथ काम करने लायक बनाता है. असल में Python रनटाइम वर्शन को सेट करने के लिए, `python_version` एट्रिब्यूट का इस्तेमाल करें, जो एक्ज़ीक्यूटेबल Python नियम (`py_binary` या `py_test`) में हो. ये मान इस्तेमाल किए जा सकते हैं: `"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 2, Python 3 या दोनों के साथ काम करने लायक बनाता है. असल में Python रनटाइम वर्शन को सेट करने के लिए, `python_version` एट्रिब्यूट का इस्तेमाल करें, जो एक्ज़ीक्यूटेबल Python नियम (`py_binary` या `py_test`) का हो. ये मान इस्तेमाल किए जा सकते हैं: `"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 स्रोत कोड या शेयर की गई लाइब्रेरी वाली हर डायरेक्ट्री में बनाई जाती हैं. साथ ही, रेपो रूट रूट को छोड़कर इन डायरेक्ट्री की हर पैरंट डायरेक्ट्री भी बनाई जाती हैं. डिफ़ॉल्ट, अपने-आप, तब तक सही होता है, जब तक कि `--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"` क्या यह टारगेट बनाना है (और उसका ट्रांज़िट`deps` Python 2 या Python के लिए) 3. `"PY2"` और `"PY3"` (डिफ़ॉल्ट मान) मान्य हैं. Python का वर्शन हमेशा इस विशेषता में बताए गए किसी भी वर्शन पर रीसेट (डिफ़ॉल्ट तौर पर) होता है. भले ही, निर्देश लाइन में दिए गए वर्शन या इस पर आधारित दूसरे टारगेट की वजह से ऐसा हो. अगर आप Python के मौजूदा वर्शन में `select()` चाहते हैं, तो आप `@rules_python//python:python_version` की वैल्यू देख सकते हैं. ज़्यादा जानकारी के लिए यहां देखें. गड़बड़ी की चेतावनी: यह एट्रिब्यूट उस वर्शन को सेट करता है जिसके लिए Bazel आपका टारगेट बनाता है. हालांकि, #4815 की वजह से, नतीजे में दिया गया स्टब स्क्रिप्ट अब भी गलत सेट हो सकता है रनटाइम पर अनुवादक मोड का वर्शन. यह समाधान देखें, जिसमें ज़रूरत के मुताबिक Python के किसी वर्शन पर ले जाने वाले `py_runtime` टारगेट के बारे में बताया गया है. साथ ही, सेटिंग के हिसाब से इस `py_runtime` को चालू किया जा सकता है `--python_top`.
`srcs_version`	`String; optional; default is "PY2AND3"` यह एट्रिब्यूट, टारगेट के `srcs` को Python 2, Python 3 या दोनों के साथ काम करने लायक बनाता है. असल में Python रनटाइम वर्शन को सेट करने के लिए, `python_version` एट्रिब्यूट का इस्तेमाल करें, जो एक्ज़ीक्यूटेबल Python नियम (`py_binary` या `py_test`) का हो. ये मान इस्तेमाल किए जा सकते हैं: `"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() तर्कों पर सेक्शन देखें, सिवाय इसके कि स्टैंप तर्क, टेस्ट के लिए डिफ़ॉल्ट रूप से शून्य पर सेट होता है.

py_रनटाइम

py_runtime(name, compatible_with, 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` इस टारगेट के लिए कोई यूनीक नाम.
`files`	`List of labels; optional` पहले से मौजूद रनटाइम के लिए, यह रनटाइम वाली फ़ाइलों का सेट है. इन फ़ाइलों को इस रनटाइम का इस्तेमाल करने वाली 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" एक्सप्रेशन को पहले से चालू Python stub स्क्रिप्ट से पहले `py_binary` टारगेट लागू करते समय इस्तेमाल किया गया. इस बारे में जानने के लिए, समस्या 8685 देखें. Windows पर लागू नहीं होता है.