নিয়োজিত নিয়ম

এই পৃষ্ঠাটি নিয়ম লেখকদের জন্য যারা তাদের নিয়ম অন্যদের কাছে উপলব্ধ করার পরিকল্পনা করছেন৷

হোস্টিং এবং নামকরণের নিয়ম

নতুন নিয়ম আপনার প্রতিষ্ঠানের অধীনে তাদের নিজস্ব GitHub সংগ্রহস্থলে যেতে হবে। আপনি যদি মনে করেন যে আপনার নিয়মগুলি বেজেলবিল্ড সংস্থার অন্তর্গত আছে তবে bazel-dev মেলিং তালিকার সাথে যোগাযোগ করুন৷

Bazel নিয়মগুলির জন্য সংগ্রহস্থলের নামগুলি নিম্নলিখিত বিন্যাসে প্রমিত করা হয়েছে: $ORGANIZATION/rules_$NAME । GitHub এ উদাহরণ দেখুন। ধারাবাহিকতার জন্য, আপনার Bazel নিয়মগুলি প্রকাশ করার সময় আপনাকে অবশ্যই এই একই বিন্যাসটি অনুসরণ করতে হবে৷

একটি বর্ণনামূলক GitHub সংগ্রহস্থলের বিবরণ এবং README.md শিরোনাম ব্যবহার করা নিশ্চিত করুন, উদাহরণ:

• সংগ্রহস্থলের নাম: bazelbuild/rules_go
• সংগ্রহস্থল বিবরণ: Bazel জন্য নিয়ম যান
• সংগ্রহস্থল ট্যাগ: golang , bazel
• README.md শিরোনাম: বেজেলের জন্য নিয়মগুলি দেখুন (https://bazel.build-এর লিঙ্কটি নোট করুন যা ব্যাজেলের সাথে অপরিচিত ব্যবহারকারীদের সঠিক জায়গায় নিয়ে যাবে)

নিয়মগুলি ভাষা (যেমন স্কালা) বা প্ল্যাটফর্ম (যেমন Android) দ্বারা গোষ্ঠীভুক্ত করা যেতে পারে।

সংগ্রহস্থল বিষয়বস্তু

প্রতিটি নিয়ম সংগ্রহস্থলের একটি নির্দিষ্ট বিন্যাস থাকা উচিত যাতে ব্যবহারকারীরা দ্রুত নতুন নিয়ম বুঝতে পারে।

উদাহরণস্বরূপ, (মেক-বিলিভ) mockascript ভাষার জন্য নতুন নিয়ম লেখার সময়, নিয়ম ভান্ডারের নিম্নলিখিত কাঠামো থাকবে:

/
  LICENSE
  README
  WORKSPACE
  mockascript/
    constraints/
      BUILD
    runfiles/
      BUILD
      runfiles.mocs
    BUILD
    defs.bzl
  tests/
    BUILD
    some_test.sh
    another_test.py
  examples/
    BUILD
    bin.mocs
    lib.mocs
    test.mocs

ওয়ার্কস্পেস

প্রকল্পের WORKSPACE এ, ব্যবহারকারীরা আপনার নিয়ম উল্লেখ করার জন্য যে নামটি ব্যবহার করবে তা আপনাকে সংজ্ঞায়িত করা উচিত। যদি আপনার নিয়মগুলি bazelbuild সংস্থার অন্তর্গত হয়, তাহলে আপনাকে অবশ্যই rules_<lang> (যেমন rules_mockascript ) ব্যবহার করতে হবে। অন্যথায়, আপনার সংগ্রহস্থলের নাম দেওয়া উচিত <org>_rules_<lang> (যেমন build_stack_rules_proto )। অনুগ্রহ করে bazel-dev মেইলিং তালিকার সাথে যোগাযোগ করুন যদি আপনি মনে করেন যে আপনার নিয়মগুলি বেজেলবিল্ড সংস্থার নিয়মগুলির জন্য কনভেনশন অনুসরণ করা উচিত৷

নিম্নলিখিত বিভাগগুলিতে, অনুমান করুন ভান্ডারটি bazelbuild সংস্থার অন্তর্গত৷

workspace(name = "rules_mockascript")

README

শীর্ষ স্তরে, একটি README থাকা উচিত যাতে (অন্তত) আপনার নিয়ম ব্যবহার করার জন্য ব্যবহারকারীদের তাদের WORKSPACE ফাইলে কপি-পেস্ট করতে হবে। সাধারণভাবে, এটি একটি http_archive হবে যা আপনার GitHub রিলিজের দিকে নির্দেশ করে এবং একটি ম্যাক্রো কল যা আপনার নিয়মের প্রয়োজনে যেকোনো সরঞ্জাম ডাউনলোড/কনফিগার করে। উদাহরণস্বরূপ, Go নিয়মগুলির জন্য, এটির মত দেখাচ্ছে:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "rules_go",
    urls = ["https://github.com/bazelbuild/rules_go/releases/download/0.18.5/rules_go-0.18.5.tar.gz"],
    sha256 = "a82a352bffae6bee4e95f68a8d80a70e87f42c4741e6a448bec11998fcc82329",
)
load("@rules_go//go:deps.bzl", "go_rules_dependencies", "go_register_toolchains")
go_rules_dependencies()
go_register_toolchains()

যদি আপনার নিয়মগুলি অন্য রিপোজিটরির নিয়মের উপর নির্ভর করে, তবে নিয়ম ডকুমেন্টেশনে সেটি উল্লেখ করুন (উদাহরণস্বরূপ, Skydoc নিয়মগুলি দেখুন , যা Sass নিয়মের উপর নির্ভর করে), এবং একটি WORKSPACE ম্যাক্রো প্রদান করুন যা সমস্ত নির্ভরতা ডাউনলোড করবে (উপরে rules_go দেখুন)।

নিয়ম

প্রায়শই আপনার সংগ্রহস্থল দ্বারা প্রদত্ত একাধিক নিয়ম থাকবে। ভাষার নামে একটি ডিরেক্টরি তৈরি করুন এবং একটি এন্ট্রি পয়েন্ট প্রদান করুন - defs.bzl ফাইলটি সমস্ত নিয়ম রপ্তানি করে (এছাড়াও একটি BUILD ফাইল অন্তর্ভুক্ত করুন যাতে ডিরেক্টরিটি একটি প্যাকেজ হয়)। rules_mockascript এর জন্য যার মানে mockascript নামে একটি ডিরেক্টরি থাকবে এবং ভিতরে একটি BUILD ফাইল এবং একটি defs.bzl ফাইল থাকবে:

/
  mockascript/
    BUILD
    defs.bzl

সীমাবদ্ধতা

যদি আপনার নিয়ম টুলচেনের নিয়মগুলিকে সংজ্ঞায়িত করে, তাহলে এটা সম্ভব যে আপনাকে কাস্টম constraint_setting এবং/অথবা constraint_value সংজ্ঞায়িত করতে হবে। এগুলিকে একটি //<LANG>/constraints প্যাকেজে রাখুন। আপনার ডিরেক্টরি গঠন এই মত দেখাবে:

/
  mockascript/
    constraints/
      BUILD
    BUILD
    defs.bzl

সর্বোত্তম অনুশীলনের জন্য অনুগ্রহ করে github.com/bazelbuild/platforms পড়ুন, এবং কোন সীমাবদ্ধতাগুলি ইতিমধ্যে উপস্থিত রয়েছে তা দেখতে এবং ভাষা স্বাধীন হলে সেখানে আপনার সীমাবদ্ধতাগুলি অবদান রাখার কথা বিবেচনা করুন৷ কাস্টম সীমাবদ্ধতাগুলি প্রবর্তন করার বিষয়ে সচেতন থাকুন, আপনার নিয়মগুলির সমস্ত ব্যবহারকারী তাদের BUILD ফাইলগুলিতে প্ল্যাটফর্ম নির্দিষ্ট যুক্তি সম্পাদন করতে তাদের ব্যবহার করবে (উদাহরণস্বরূপ, নির্বাচনগুলি ব্যবহার করে)। কাস্টম সীমাবদ্ধতার সাথে, আপনি একটি ভাষা সংজ্ঞায়িত করেন যেটি পুরো Bazel ইকোসিস্টেম কথা বলবে।

রানফাইলস লাইব্রেরি

যদি আপনার নিয়ম রানফাইলগুলি অ্যাক্সেস করার জন্য একটি স্ট্যান্ডার্ড লাইব্রেরি প্রদান করে, তাহলে এটি //<LANG>/runfiles ( //<LANG>/runfiles:runfiles এর একটি সংক্ষিপ্ত রূপ) এ অবস্থিত একটি লাইব্রেরি টার্গেট আকারে হওয়া উচিত। ব্যবহারকারীর লক্ষ্যমাত্রা যাদের তাদের ডেটা নির্ভরতা অ্যাক্সেস করতে হবে তারা সাধারণত তাদের deps অ্যাট্রিবিউটে এই লক্ষ্য যুক্ত করবে।

সংগ্রহস্থলের নিয়ম

নির্ভরতা

আপনার নিয়ম বহিরাগত নির্ভরতা থাকতে পারে. আপনার নিয়মের উপর নির্ভর করে সহজতর করতে, অনুগ্রহ করে একটি WORKSPACE ম্যাক্রো প্রদান করুন যা ঐ বাহ্যিক নির্ভরতার উপর নির্ভরতা ঘোষণা করবে। সেখানে পরীক্ষার নির্ভরতা ঘোষণা করবেন না, শুধুমাত্র সেই নির্ভরতাগুলি যা নিয়মগুলিকে কাজ করতে হবে। WORKSPACE ফাইলে উন্নয়ন নির্ভরতা রাখুন।

<LANG>/repositories.bzl নামে একটি ফাইল তৈরি করুন এবং rules_<LANG>_dependencies নামে একটি একক এন্ট্রি পয়েন্ট ম্যাক্রো প্রদান করুন। আমাদের ডিরেক্টরি নিম্নলিখিত হিসাবে দেখাবে:

/
  mockascript/
    constraints/
      BUILD
    BUILD
    defs.bzl
    repositories.bzl

টুলচেইন নিবন্ধন করা হচ্ছে

আপনার নিয়মগুলি টুলচেইন নিবন্ধন করতে পারে। অনুগ্রহ করে একটি পৃথক ওয়ার্কস্পেস ম্যাক্রো প্রদান করুন যা এই WORKSPACE নিবন্ধন করে৷ এইভাবে ব্যবহারকারীরা পূর্ববর্তী ম্যাক্রো বাদ দেওয়ার সিদ্ধান্ত নিতে পারে এবং ম্যানুয়ালি নির্ভরতা নিয়ন্ত্রণ করতে পারে, যদিও এখনও টুলচেন নিবন্ধন করার অনুমতি দেওয়া হচ্ছে।

তাই <LANG>/repositories.bzl ফাইলে rules_<LANG>_toolchains নামের একটি WORKSPACE ম্যাক্রো যোগ করুন।

নোট করুন যে বিশ্লেষণ পর্বে টুলচেইনগুলি সমাধান করার জন্য Bazel কে নিবন্ধিত সমস্ত toolchain লক্ষ্যগুলি বিশ্লেষণ করতে হবে৷ Bazel কে toolchain.toolchain অ্যাট্রিবিউট দ্বারা উল্লেখ করা সমস্ত লক্ষ্য বিশ্লেষণ করার প্রয়োজন হবে না। টুলচেন নিবন্ধন করার জন্য যদি আপনাকে সংগ্রহস্থলে জটিল গণনা সম্পাদন করতে হয়, তাহলে সংগ্রহস্থল থেকে toolchain টার্গেটের সাথে সংগ্রহস্থলকে <LANG>_toolchain টার্গেটের সাথে বিভক্ত করার কথা বিবেচনা করুন। পূর্ববর্তীটি সর্বদা আনা হবে, এবং পরবর্তীটি তখনই আনা হবে যখন ব্যবহারকারীকে আসলে <LANG> কোড তৈরি করতে হবে।

রিলিজ স্নিপেট

আপনার প্রকাশের ঘোষণায় একটি স্নিপেট প্রদান করুন যা আপনার ব্যবহারকারীরা তাদের WORKSPACE ফাইলে কপি-পেস্ট করতে পারে। সাধারণভাবে এই স্নিপেটটি নিম্নরূপ দেখাবে:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "rules_<LANG>",
    urls = ["<url_to_the_release.zip"],
    sha256 = "4242424242",
)
load("@rules_<LANG>//<LANG>:repositories.bzl", "rules_<LANG>_dependencies", "rules_<LANG>_toolchains")
rules_<LANG>_dependencies()
rules_<LANG>_toolchains()

টেস্ট

এমন পরীক্ষা হওয়া উচিত যা যাচাই করে যে নিয়মগুলি প্রত্যাশিত হিসাবে কাজ করছে। এটি হয় নিয়মগুলি যে ভাষার জন্য প্রমিত অবস্থানে বা শীর্ষ স্তরে একটি tests/ ডিরেক্টরি হতে পারে৷

উদাহরণ (ঐচ্ছিক)

ব্যবহারকারীদের জন্য একটি examples/ ডিরেক্টরি থাকা দরকারী যা ব্যবহারকারীদের কয়েকটি মৌলিক উপায় দেখায় যে নিয়মগুলি ব্যবহার করা যেতে পারে।

পরীক্ষামূলক

ট্র্যাভিস সেট আপ করুন যা তাদের শুরু হওয়া ডক্সে বর্ণিত হয়েছে৷ তারপরে নিম্নলিখিত সামগ্রী সহ আপনার সংগ্রহস্থলে একটি .travis.yml ফাইল যুক্ত করুন:

dist: xenial  # Ubuntu 16.04

# On trusty (or later) images, the Bazel apt repository can be used.
addons:
  apt:
    sources:
    - sourceline: 'deb [arch=amd64] http://storage.googleapis.com/bazel-apt stable jdk1.8'
      key_url: 'https://bazel.build/bazel-release.pub.gpg'
    packages:
    - bazel

script:
  - bazel build //...
  - bazel test //...

যদি আপনার সংগ্রহস্থল bazelbuild সংস্থার অধীনে থাকে, তাহলে আপনি এটিকে ci.bazel.build এ যোগ করতে বলতে পারেন।

ডকুমেন্টেশন

আপনার নিয়মগুলি কীভাবে মন্তব্য করতে হবে তার নির্দেশাবলীর জন্য Stardoc ডকুমেন্টেশন দেখুন যাতে ডকুমেন্টেশন স্বয়ংক্রিয়ভাবে তৈরি করা যায়।

FAQs

কেন আমরা মূল Bazel GitHub সংগ্রহস্থলে আমাদের নিয়ম যোগ করতে পারি না?

আমরা যতটা সম্ভব Bazel রিলিজ থেকে নিয়মগুলিকে দ্বিগুণ করতে চাই৷ ব্যাজেল ডেভেলপারদের উপর লোড কমিয়ে, কে স্বতন্ত্র নিয়মের মালিক তা স্পষ্ট। আমাদের ব্যবহারকারীদের জন্য, ডিকপলিং নিয়মগুলি সংশোধন, আপগ্রেড, ডাউনগ্রেড এবং প্রতিস্থাপন করা সহজ করে তোলে। নিয়মগুলিতে অবদান রাখা বাজেলে অবদান রাখার চেয়ে হালকা ওজনের হতে পারে - নিয়মগুলির উপর নির্ভর করে - সংশ্লিষ্ট GitHub সংগ্রহস্থলে সম্পূর্ণ জমা দেওয়ার অ্যাক্সেস সহ। Bazel-এ সাবমিট অ্যাক্সেস পাওয়া নিজেই অনেক বেশি জড়িত প্রক্রিয়া।

নেতিবাচক দিক হল আমাদের ব্যবহারকারীদের জন্য আরও জটিল এক-সময়ের ইনস্টলেশন প্রক্রিয়া: তাদের WORKSPACE ফাইলে একটি নিয়ম কপি-পেস্ট করতে হবে, যেমনটি উপরের README.md বিভাগে দেখানো হয়েছে।

আমাদের ব্যাজেল সংগ্রহস্থলে ( //tools/build_rules বা //tools/build_defs অধীনে) সমস্ত নিয়ম ছিল। আমরা এখনও সেখানে কিছু নিয়ম আছে, কিন্তু আমরা বাকি নিয়ম সরানোর জন্য কাজ করছি.