फ़ंक्शन

सामग्री

• पैकेज
• package_group
• exports_files
• glob
• select
• subpackages

पैकेज

package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)

यह फ़ंक्शन, पैकेज के हर नियम पर लागू होने वाले मेटाडेटा के बारे में बताता है. इसका इस्तेमाल, किसी पैकेज (BUILD फ़ाइल) में ज़्यादा से ज़्यादा एक बार किया जा सकता है.

_डेटाबेस_ के हर नियम पर लागू होने वाले मेटाडेटा के बारे में बताने के लिए, अपने डेटाबेस के रूट में मौजूद REPO.bazel फ़ाइल में repo() फ़ंक्शन का इस्तेमाल करें. repo() फ़ंक्शन, package() के जैसे ही आर्ग्युमेंट लेता है.

package() फ़ंक्शन को, फ़ाइल में सबसे ऊपर मौजूद सभी load() स्टेटमेंट के ठीक बाद और किसी भी नियम से पहले कॉल किया जाना चाहिए.

तर्क

उदाहरण

package(default_visibility = ["//foo:target"])

package_group

package_group(name, packages, includes)

यह फ़ंक्शन, पैकेज का सेट तय करता है और सेट के साथ एक लेबल जोड़ता है. लेबल का रेफ़रंस, visibility एट्रिब्यूट में दिया जा सकता है.

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

किसी पैकेज को ग्रुप में तब माना जाता है, जब वह packages एट्रिब्यूट से मेल खाता हो या includes एट्रिब्यूट में बताए गए किसी अन्य पैकेज ग्रुप में पहले से शामिल हो.

पैकेज ग्रुप, तकनीकी तौर पर टारगेट होते हैं. हालांकि, इन्हें नियमों से नहीं बनाया जाता. साथ ही, इनमें विज़िबिलिटी से जुड़ी कोई सुरक्षा नहीं होती.

तर्क

उदाहरण

package_group के नीचे दिए गए एलान में, "tropical" नाम का एक पैकेज ग्रुप तय किया गया है. इसमें ट्रॉपिकल फल शामिल हैं.

package_group(
    name = "tropical",
    packages = [
        "//fruits/mango",
        "//fruits/orange",
        "//fruits/papaya/...",
    ],
)

नीचे दिए गए एलान में, किसी काल्पनिक ऐप्लिकेशन के पैकेज ग्रुप तय किए गए हैं:

package_group(
    name = "fooapp",
    includes = [
        ":controller",
        ":model",
        ":view",
    ],
)

package_group(
    name = "model",
    packages = ["//fooapp/database"],
)

package_group(
    name = "view",
    packages = [
        "//fooapp/swingui",
        "//fooapp/webui",
    ],
)

package_group(
    name = "controller",
    packages = ["//fooapp/algorithm"],
)

exports_files

exports_files([label, ...], visibility, licenses)

exports_files() , इस पैकेज से जुड़ी उन फ़ाइलों की सूची तय करता है जिन्हें अन्य पैकेज में एक्सपोर्ट किया जाता है.

किसी पैकेज की BUILD फ़ाइल, सोर्स फ़ाइलों का रेफ़रंस सीधे तौर पर सिर्फ़ तब दे सकती है, जब उन्हें किसी दूसरे पैकेज से संबंधित होने पर exports_files() स्टेटमेंट के साथ साफ़ तौर पर एक्सपोर्ट किया गया हो. फ़ाइलों की विज़िबिलिटी के बारे में ज़्यादा पढ़ें .

पुराने तरीके के मुताबिक, किसी नियम के इनपुट के तौर पर बताई गई फ़ाइलों को भी डिफ़ॉल्ट विज़िबिलिटी के साथ एक्सपोर्ट किया जाता है. ऐसा तब तक होता है, जब तक फ़्लैग --incompatible_no_implicit_file_export फ़्लिप नहीं किया जाता. हालांकि, इस तरीके पर भरोसा नहीं करना चाहिए और इससे धीरे-धीरे माइग्रेट करना चाहिए.

तर्क

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

उदाहरण

नीचे दिए गए उदाहरण में, golden.txt को test_data पैकेज की टेक्स्ट फ़ाइल के तौर पर एक्सपोर्ट किया गया है, ताकि अन्य पैकेज इसका इस्तेमाल कर सकें. उदाहरण के लिए, टेस्ट के data एट्रिब्यूट में.

# from //test_data/BUILD

exports_files(["golden.txt"])

glob

glob(include, exclude=[], exclude_directories=1, allow_empty=True)

Glob एक हेल्पर फ़ंक्शन है. यह पाथ के कुछ पैटर्न से मेल खाने वाली सभी फ़ाइलें ढूंढता है. साथ ही, उनके पाथ की नई, बदली जा सकने वाली, क्रम से लगाई गई सूची दिखाता है. Glob सिर्फ़ अपने पैकेज में फ़ाइलें खोजता है. साथ ही, सिर्फ़ सोर्स फ़ाइलें ढूंढता है. जनरेट की गई फ़ाइलें या अन्य टारगेट नहीं.

अगर फ़ाइल का पैकेज-रिलेटिव पाथ, include के किसी भी पैटर्न से मेल खाता है और exclude के किसी भी पैटर्न से मेल नहीं खाता है, तो सोर्स फ़ाइल का लेबल, नतीजे में शामिल किया जाता है.

include और exclude सूचियों में, मौजूदा पैकेज के हिसाब से पाथ के पैटर्न शामिल होते हैं. हर पैटर्न में, पाथ के एक या उससे ज़्यादा सेगमेंट हो सकते हैं. Unix पाथ की तरह, इन सेगमेंट को / से अलग किया जाता है. सेगमेंट में * वाइल्डकार्ड शामिल हो सकता है. यह वाइल्डकार्ड, पाथ सेगमेंट में मौजूद किसी भी सबस्ट्रिंग (खाली सबस्ट्रिंग भी) से मेल खाता है. हालांकि, यह डायरेक्ट्री सेपरेटर / से मेल नहीं खाता. इस वाइल्डकार्ड का इस्तेमाल, पाथ के एक सेगमेंट में कई बार किया जा सकता है. इसके अलावा, ** वाइल्डकार्ड, पाथ के शून्य या उससे ज़्यादा सेगमेंट से मेल खा सकता है. हालांकि, इसे पाथ के अलग सेगमेंट के तौर पर एलान करना ज़रूरी है.

• foo/bar.txt , इस पैकेज में मौजूद foo/bar.txt फ़ाइल से पूरी तरह मेल खाता है
• foo/*.txt , foo/ डायरेक्ट्री में मौजूद हर फ़ाइल से मेल खाता है. हालांकि, यह तब होता है, जब फ़ाइल .txt से खत्म होती है. इसके अलावा, अगर foo/ कोई सबपैकेज है, तो यह मेल नहीं खाएगा
• foo/a*.htm* , foo/ डायरेक्ट्री में मौजूद हर फ़ाइल से मेल खाता है. हालांकि, यह तब होता है, जब फ़ाइल a से शुरू होती है, उसके बाद कोई भी स्ट्रिंग (खाली भी हो सकती है), फिर .htm और आखिर में कोई भी स्ट्रिंग हो. जैसे, foo/axx.htm और foo/a.html या foo/axxx.html
• **/a.txt , इस पैकेज की हर सबडायरेक्ट्री में मौजूद a.txt फ़ाइल से मेल खाता है
• **/bar/**/*.txt इस पैकेज की हर .txt फ़ाइल से मेल खाता है. हालांकि, यह तब होता है, जब नतीजे के तौर पर मिलने वाले पाथ में कम से कम एक डायरेक्ट्री का नाम bar हो. जैसे, xxx/bar/yyy/zzz/a.txt या bar/a.txt (ध्यान रखें कि ** , शून्य सेगमेंट से भी मेल खाता है) या bar/zzz/a.txt
• ** , इस पैकेज की हर सबडायरेक्ट्री में मौजूद हर फ़ाइल से मेल खाता है
• foo**/a.txt , अमान्य पैटर्न है. ऐसा इसलिए, क्योंकि ** को सेगमेंट के तौर पर अलग से इस्तेमाल करना ज़रूरी है

अगर exclude_directories आर्ग्युमेंट चालू है (इसे 1 पर सेट किया गया है), तो नतीजों में डायरेक्ट्री टाइप की फ़ाइलें शामिल नहीं की जाएंगी. डिफ़ॉल्ट रूप से, यह 1 पर सेट होता है.

अगर allow_empty आर्ग्युमेंट को False पर सेट किया जाता है, तो glob फ़ंक्शन गड़बड़ी दिखाएगा. ऐसा तब होगा, जब नतीजे के तौर पर खाली सूची मिलेगी.

इसकी कुछ अहम सीमाएं और चेतावनियां हैं:

1. glob() , BUILD फ़ाइल के आकलन के दौरान चलता है. इसलिए, glob() सिर्फ़ आपके सोर्स ट्री में मौजूद फ़ाइलों से मेल खाता है. जनरेट की गई फ़ाइलों से नहीं. अगर आपको ऐसा टारगेट बनाना है जिसके लिए सोर्स और जनरेट की गई, दोनों तरह की फ़ाइलों की ज़रूरत है, तो आपको glob में जनरेट की गई फ़ाइलों की साफ़ तौर पर सूची जोड़नी होगी. नीचे दिया गया उदाहरण देखें. इसमें :mylib और :gen_java_srcs का इस्तेमाल किया गया है.

2. अगर किसी नियम का नाम, मेल खाने वाली सोर्स फ़ाइल के नाम जैसा है, तो नियम "शैडो" करेगा.

   इसे समझने के लिए, ध्यान रखें कि glob() पाथ की सूची दिखाता है. इसलिए, अन्य नियमों के एट्रिब्यूट में glob() का इस्तेमाल करने पर (जैसे, srcs = glob(["*.cc"])), मेल खाने वाले पाथ को साफ़ तौर पर लिस्ट करने जैसा ही असर होता है. उदाहरण के लिए, अगर glob() , ["Foo.java", "bar/Baz.java"] दिखाता है, लेकिन पैकेज में "Foo.java" नाम का एक नियम भी है (हालांकि, Bazel इसके बारे में चेतावनी देता है), तो glob() का इस्तेमाल करने वाला व्यक्ति, "Foo.java" फ़ाइल के बजाय "Foo.java" नियम (इसके आउटपुट) का इस्तेमाल करेगा. ज़्यादा जानकारी के लिए, GitHub पर समस्या #10395 देखें.

3. Glob, सबडायरेक्ट्री में मौजूद फ़ाइलों से मेल खा सकता है. साथ ही, सबडायरेक्ट्री के नामों में वाइल्डकार्ड का इस्तेमाल किया जा सकता है. हालांकि...

4. लेबल को पैकेज की सीमा से बाहर इस्तेमाल नहीं किया जा सकता. साथ ही, glob, सबपैकेज में मौजूद फ़ाइलों से मेल नहीं खाता.

   उदाहरण के लिए, पैकेज x में मौजूद glob एक्सप्रेशन **/*.cc में, x/y/z.cc शामिल नहीं है. ऐसा तब होता है, जब x/y एक पैकेज के तौर पर मौजूद हो. यह x/y/BUILD के तौर पर या पैकेज-पाथ पर कहीं और मौजूद हो सकता है. इसका मतलब है कि glob एक्सप्रेशन का नतीजा, BUILD फ़ाइलों के मौजूद होने पर निर्भर करता है. यानी, अगर x/y नाम का कोई पैकेज मौजूद नहीं है या --deleted_packages फ़्लैग का इस्तेमाल करके, उसे मिटाया गया है, तो वही glob एक्सप्रेशन x/y/z.cc को शामिल करेगा.

5. ऊपर दी गई पाबंदी, सभी glob एक्सप्रेशन पर लागू होती है. भले ही, उनमें किसी भी वाइल्डकार्ड का इस्तेमाल किया गया हो.
6. जिस फ़ाइल का नाम . से शुरू होता है उसे ** और * , दोनों वाइल्डकार्ड से पूरी तरह मैच किया जा सकता है. अगर आपको किसी छिपी हुई फ़ाइल को किसी कंपोज़िट पैटर्न से मैच करना है, तो आपका पैटर्न . से शुरू होना चाहिए. उदाहरण के लिए, * और .*.txt , .foo.txt से मैच करेंगे, लेकिन *.txt मैच नहीं करेगा. छिपी हुई डायरेक्ट्री भी इसी तरह मैच की जाती हैं. छिपी हुई डायरेक्ट्री में ऐसी फ़ाइलें शामिल हो सकती हैं जो इनपुट के तौर पर ज़रूरी नहीं हैं. इससे, बिना वजह glob की गई फ़ाइलों की संख्या और मेमोरी की खपत बढ़ सकती है. छिपी हुई डायरेक्ट्री को बाहर रखने के लिए, उन्हें "exclude" लिस्ट आर्ग्युमेंट में जोड़ें.
7. वाइल्डकार्ड "**" का एक कॉर्नर केस है: पैटर्न "**" , पैकेज के डायरेक्ट्री पाथ से मैच नहीं करता. इसका मतलब है कि glob(["**"], exclude_directories = 0) , मौजूदा पैकेज की डायरेक्ट्री के तहत आने वाली सभी फ़ाइलों और डायरेक्ट्री से ट्रांज़िटिव तौर पर मैच करता है. हालांकि, यह सबपैकेज की डायरेक्ट्री में नहीं जाता. इसके बारे में पिछली टिप्पणी देखें.

आम तौर पर, glob पैटर्न के लिए, सिर्फ़ '*' का इस्तेमाल करने के बजाय, सही एक्सटेंशन (जैसे, *.html) देने की कोशिश करनी चाहिए. साफ़ तौर पर नाम देने से, यह खुद ही दस्तावेज़ बन जाता है. साथ ही, इससे यह पक्का होता है कि आपने गलती से बैकअप फ़ाइलों या emacs/vi/... की अपने-आप सेव होने वाली फ़ाइलों को मैच नहीं किया है.

बिल्ड के नियम लिखते समय, glob के एलिमेंट की गिनती की जा सकती है. इससे हर इनपुट के लिए अलग-अलग नियम जनरेट किए जा सकते हैं. उदाहरण के लिए, नीचे, glob के बड़े किए गए उदाहरण वाला सेक्शन देखें.

Glob के उदाहरण

इस डायरेक्ट्री में मौजूद सभी Java फ़ाइलों और :gen_java_srcs नियम से जनरेट की गई सभी फ़ाइलों से, Java लाइब्रेरी बनाएं.

java_library(
    name = "mylib",
    srcs = glob(["*.java"]) + [":gen_java_srcs"],
    deps = "...",
)

genrule(
    name = "gen_java_srcs",
    outs = [
        "Foo.java",
        "Bar.java",
    ],
    ...
)

testdata डायरेक्ट्री में मौजूद सभी txt फ़ाइलों को शामिल करें. हालांकि, experimental.txt को शामिल न करें. ध्यान दें कि testdata की सबडायरेक्ट्री में मौजूद फ़ाइलें शामिल नहीं की जाएंगी. अगर आपको उन फ़ाइलों को शामिल करना है, तो रिकर्सिव glob (**) का इस्तेमाल करें.

sh_test(
    name = "mytest",
    srcs = ["mytest.sh"],
    data = glob(
        ["testdata/*.txt"],
        exclude = ["testdata/experimental.txt"],
    ),
)

रिकर्सिव Glob के उदाहरण

टेस्ट को testdata डायरेक्ट्री और उसकी किसी भी सबडायरेक्ट्री (और उनकी सबडायरेक्ट्री वगैरह) में मौजूद सभी txt फ़ाइलों पर निर्भर बनाएं. BUILD फ़ाइल वाली सबडायरेक्ट्री को अनदेखा किया जाता है. (ऊपर दी गई सीमाएं और चेतावनियां देखें.)

sh_test(
    name = "mytest",
    srcs = ["mytest.sh"],
    data = glob(["testdata/**/*.txt"]),
)

इस डायरेक्ट्री और सभी सबडायरेक्ट्री में मौजूद सभी Java फ़ाइलों से एक लाइब्रेरी बनाएं. हालांकि, उन सबडायरेक्ट्री को शामिल न करें जिनके पाथ में testing नाम की डायरेक्ट्री शामिल है. अगर हो सके, तो इस पैटर्न का इस्तेमाल नहीं करना चाहिए. इससे बिल्ड की इंक्रीमेंटैलिटी कम हो सकती है. इसलिए, बिल्ड में लगने वाला समय बढ़ सकता है.

java_library(
    name = "mylib",
    srcs = glob(
        ["**/*.java"],
        exclude = ["**/testing/**"],
    ),
)

Glob के बड़े किए गए उदाहरण

मौजूदा डायरेक्ट्री में *_test.cc के लिए, अलग-अलग genrule बनाएं. इससे फ़ाइल में मौजूद लाइनों की संख्या गिनी जाएगी.

# Conveniently, the build language supports list comprehensions.
[genrule(
    name = "count_lines_" + f[:-3],  # strip ".cc"
    srcs = [f],
    outs = ["%s-linecount.txt" % f[:-3]],
    cmd = "wc -l $< >$@",
 ) for f in glob(["*_test.cc"])]

अगर ऊपर दी गई BUILD फ़ाइल, //foo पैकेज में है और पैकेज में तीन मेल खाने वाली फ़ाइलें, a_test.cc, b_test.cc, और c_test.cc हैं, तो bazel query '//foo:all' चलाने पर, जनरेट किए गए सभी नियम दिखेंगे:

$ bazel query '//foo:all' | sort
//foo:count_lines_a_test
//foo:count_lines_b_test
//foo:count_lines_c_test

select

select(
    {conditionA: valuesA, conditionB: valuesB, ...},
    no_match_error = "custom message"
)

select() एक हेल्पर फ़ंक्शन है. इसकी मदद से, नियम के एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है. यह लगभग किसी भी एट्रिब्यूट असाइनमेंट के दाईं ओर की वैल्यू को बदल सकता है. इसलिए, इसकी वैल्यू, कमांड-लाइन Bazel फ़्लैग पर निर्भर करती है. उदाहरण के लिए, इसका इस्तेमाल प्लैटफ़ॉर्म के हिसाब से डिपेंडेंसी तय करने या किसी नियम को "डेवलपर" बनाम "रिलीज़" मोड में बनाने के आधार पर अलग-अलग संसाधन एम्बेड करने के लिए किया जा सकता है.

इसका बुनियादी इस्तेमाल इस तरह किया जाता है:

sh_binary(
    name = "mytarget",
    srcs = select({
        ":conditionA": ["mytarget_a.sh"],
        ":conditionB": ["mytarget_b.sh"],
        "//conditions:default": ["mytarget_default.sh"]
    })
)

इससे, srcs एट्रिब्यूट को sh_binary कॉन्फ़िगर किया जा सकता है. इसके लिए, सामान्य लेबल सूची असाइनमेंट को select कॉल से बदलें. यह कॉल, कॉन्फ़िगरेशन की शर्तों को मेल खाने वाली वैल्यू पर मैप करता है. हर शर्त, config_setting या constraint_value का लेबल रेफ़रंस होती है. यह तब "मेल खाती है", जब टारगेट का कॉन्फ़िगरेशन, वैल्यू के अनुमानित सेट से मेल खाता है. इसके बाद, mytarget#srcs की वैल्यू, वह लेबल सूची बन जाती है जो मौजूदा कॉल से मेल खाती है.

ध्यान दें:

• किसी भी कॉल पर, सिर्फ़ एक शर्त चुनी जाती है.
• अगर एक से ज़्यादा शर्तें मेल खाती हैं और उनमें से एक, अन्य शर्तों का स्पेशलाइज़ेशन है, स्पेशलाइज़ेशन को प्राथमिकता दी जाती है. शर्त B को, शर्त A का स्पेशलाइज़ेशन तब माना जाता है, जब B में वे सभी फ़्लैग और कंस्ट्रेंट वैल्यू हों जो A में हैं. साथ ही, उसमें कुछ अतिरिक्त फ़्लैग या कंस्ट्रेंट वैल्यू भी हों. इसका मतलब यह भी है कि स्पेशलाइज़ेशन रिज़ॉल्यूशन को, ऑर्डरिंग बनाने के लिए डिज़ाइन नहीं किया गया है. इसके बारे में, नीचे दिए गए दूसरे उदाहरण में बताया गया है.
• अगर एक से ज़्यादा शर्तें मेल खाती हैं और उनमें से कोई एक, अन्य सभी शर्तों का स्पेशलाइज़ेशन नहीं है, तो Bazel गड़बड़ी दिखाता है. हालांकि, ऐसा तब नहीं होता, जब सभी शर्तों की वैल्यू एक ही हो.
• अगर कोई अन्य शर्त मेल नहीं खाती है, तो खास स्यूडो-लेबल //conditions:default को मेल खाने वाली शर्त माना जाता है. अगर इस शर्त को छोड़ दिया जाता है, तो गड़बड़ी से बचने के लिए, किसी अन्य नियम का मेल खाना ज़रूरी है.
• select को, बड़े एट्रिब्यूट असाइनमेंट के अंदर एम्बेड किया जा सकता है. इसलिए, srcs = ["common.sh"] + select({ ":conditionA": ["myrule_a.sh"], ...}) और srcs = select({ ":conditionA": ["a.sh"]}) + select({ ":conditionB": ["b.sh"]}) मान्य एक्सप्रेशन हैं.
• select, ज़्यादातर एट्रिब्यूट के साथ काम करता है. हालांकि, सभी के साथ नहीं. असंगत एट्रिब्यूट को उनके दस्तावेज़ में nonconfigurable के तौर पर मार्क किया जाता है.

  subpackages

  subpackages(include, exclude=[], allow_empty=True)

  subpackages() , glob() की तरह एक हेल्पर फ़ंक्शन है. यह फ़ाइलों और डायरेक्ट्री के बजाय, सबपैकेज की सूची दिखाता है. यह glob() के जैसे ही पाथ पैटर्न का इस्तेमाल करता है. साथ ही, यह मौजूदा समय में लोड हो रही BUILD फ़ाइल के सीधे तौर पर डिसेंडेंट वाले किसी भी सबपैकेज से मेल खा सकता है. शामिल करने और बाहर रखने के पैटर्न के बारे में ज़्यादा जानकारी और उदाहरण के लिए, glob देखें.

  नतीजे के तौर पर मिलने वाली सबपैकेज की सूची, क्रम से लगाई जाती है. इसमें मौजूदा समय में लोड हो रहे पैकेज के हिसाब से पाथ शामिल होते हैं. ये पाथ, में दिए गए पैटर्न से मेल खाते हैं और include में दिए गए पैटर्न से मेल नहीं खाते.exclude

  उदाहरण

  नीचे दिए गए उदाहरण में, foo/BUILD पैकेज के सभी डायरेक्ट सबपैकेज की सूची दिखाई गई है

  # The following BUILD files exist:
  # foo/BUILD
  # foo/bar/baz/BUILD
  # foo/sub/BUILD
  # foo/sub/deeper/BUILD
  #
  # In foo/BUILD a call to
  subs = subpackages(include = ["**"])
  
  # results in subs == ["sub", "bar/baz"]
  #
  # 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of
  # 'foo'
  

  आम तौर पर, यह सुझाव दिया जाता है कि उपयोगकर्ता इस फ़ंक्शन को सीधे तौर पर कॉल करने के बजाय कि उपयोगकर्ता skylib के 'subpackages' मॉड्यूल का इस्तेमाल करें .