Package manager ها – بخش 3

در سومین و چهارمین مقاله‌ی آموزش برنامه‌نویسی زبان python از سری مقالات مرتبط با برنامه‌نویسی در بازار‌ها‌ی مالی به شرح و  بررسی «package manager ها» پرداختیم.، در این بخش موضوع را پی گرفته و بیشتر در مورد آن صحبت خواهیم پرداخت.

Package manager ها و استفاده از Channelها

در این بخش از آموزش برنامه‌نویسی پایتون مطالب مربوط به آموزش Package manager ها با تمرکز بر Conda را پی گرفته و مطالب مربوط به این بخش را جمع‌بندی می‌کنیم. گاهی اوقات، بسته‌هایی را که می‌خواهید نصب کنید در کانال‌های پیش‌فرض پیکربندی شده توسط نصب کننده پیدا نمی‌کنید. به عنوان مثال، نحوه نصب pytorch، بسته دیگر machine learning از طریق فرمان زیر حاصل می‌شود.

(base) C:\Users\IEUser>conda search pytorch
//

می‌توانید کانال را اضافه کنید تا Conda از آن برای جستجوی بسته‌هایی برای نصب استفاده کند. برای فهرست کردن کانال‌های فعلی مورد استفاده، می‌توانید “conda config –get channels“ را اجرا کنید:

(base) C:\Users\IEUser>conda config --get channels
--add channels 'defaults'   # lowest priority

(base) C:\Users\IEUser>

نصب کننده Miniconda فقط شامل کانال‌های پیش‌فرض است. هنگامی که کانال‌های بیشتری گنجانده می شود، لازم است اولویت آنها را تعیین کنید تا مشخص شود در صورتی که یک بسته از بیش از یک کانال در دسترس باشد، از کدام کانال نصب می‌شود.

برای افزودن کانالی با کمترین اولویت به لیست، باید

“<conda config –append channels <channel name“

را اجرا کنید.

برای افزودن کانالی با بالاترین اولویت به لیست، باید

“<conda config –prepend channels <channel name“

را اجرا کنید.

• توصیه می‌شود کانال‌های جدید با اولویت کم اضافه کنید تا از کانال‌های پیش فرض قبل از کانال‌های دیگر استفاده کنید. بنابراین، می‌توانید pytorch را نصب کنید، کانال pytorch را اضافه کنید و conda install pytorch را اجرا کنید:

(base) C:\Users\IEUser>conda config --append channels pytorch

(base) C:\Users\IEUser>conda config --get channels
--add channels 'pytorch'   # lowest priority
--add channels 'defaults'   # highest priority

(base) C:\Users\IEUser>conda install pytorch
Solving environment: done
...

همه بسته ها در کانال‌های کوندا در دسترس نیستند. با این حال، این مشکلی نیست، زیرا شما همچنین می‌توانید از pip برای نصب بسته‌ها در محیط های Conda استفاده کنید. بیایید ببینیم چگونه این کار را انجام دهیم.

در مباحث پیشین به بررسی تفاوت بین Conda و Pip پرداختیم در این بخش این بررسی را تکمیل می‌‌کنیم و به نکات باقی‌مانده می‌پردازیم.

فراتر از پایتون خالص: پکیج کردن پسوندهای کامپایل شده

در روزهای اولیه بسته‌بندی پایتون، یک بسته شامل کد منبعی بود که باید نصب می‌شد. برای بسته‌های پایتون خالص، این به خوبی کار می‌کرد، و هنوز هم همین است. اما چه اتفاقی می‌افتد زمانی که شما نیاز به کامپایل کدهای Rust یا C یا ++C یا Fortran به عنوان بخشی از ساخت package دارید؟

برای این موضوع راه‌حل‌های مختلفی وجود دارد که در این‌جا به برخی از آن‌ها اشاره می‌کنیم.:

راه حل شماره 1: Compile it yourself

راه‌حل اصلی این بود که هر کاربر کد را خودش در زمان نصب کامپایل کند. این می‌تواند بسیار کند باشد، منابع را هدر می‌دهد، اغلب پیکربندی آن دردناک است، و هنوز هم بخش بزرگی از مشکل را حل نمی‌کند: وابستگی‌های کتابخانه‌های به اشتراک گذاشته‌شده.

برای مثال، کتابخانه گرافیکی Pillow، به کتابخانه‌های به اشتراک گذاشته‌شده شخص ثالث مانند libpng و libjpeg متکی است. برای اینکه خودتان Pillow را کامپایل کنید، باید همه آنها را به اضافه هدرهای توسعه آنها را نصب کنید. در لینوکس یا macOS می‌توانید بسته‌های سیستمی یا بسته‌های Homebrew را نصب کنید. برای ویندوز این می‌تواند دشوارتر باشد. اما برای هر سیستم عامل و حتی توزیع لینوکس باید پیکربندی متفاوتی بنویسید.

راه حل شماره 2: Pip wheels

راهی که پیپ این مشکل را حل می‌کند با بسته‌هایی به نام “wheels” است که می‌تواند شامل کدهای کامپایل شده باشد. برای تعامل با وابستگی‌های کتابخانه‌های به اشتراک گذاشته‌ شده مانند libpng، هر وابستگی خارجی کتابخانه به اشتراک گذاشته‌ شده در داخل خود wheel قرار می‌گیرد.

به عنوان مثال، بیایید به Pillow wheel برای لینوکس نگاه کنیم. wheel فقط یک فایل ZIP است تا بتوانیم از ابزارهای ZIP استاندارد استفاده کنیم:

$ zipinfo Pillow.whl
...
Pillow.libs/libpng16-213e245f.so.16.37.0
Pillow.libs/libjpeg-183418da.so.9.4.0
...
PIL/FpxImagePlugin.py
PIL/PalmImagePlugin.py
...
PIL/_imagingcms.cpython-39-x86_64-linux-gnu.so
...

wheel شامل کدهای پایتون(Python code)، پسوند پایتون کامپایل‌ شده(a compiled Python extension) و کتابخانه‌های شخص ثالث(third-party shared libraries) به اشتراک گذاشته‌ شده مانند libpng و libjpeg است. این گاهی اوقات می‌تواند بسته‌ها را بزرگ‌تر کند، زیرا ممکن است چندین نسخه از کتابخانه‌های به اشتراک گذاشته‌ شده شخص ثالث نصب شود، یکی در هر wheel.

راه حل شماره 3: Conda packages

بسته‌های Conda رویکرد متفاوتی نسبت به کتابخانه‌های به اشتراک گذاشته‌ شده شخص ثالث دارند. libjpeg و libpng به عنوان بسته‌های اضافی Conda پکیج می شوند:

$ conda install -c conda-forge pillow
...
The following NEW packages will be INSTALLED:

...
  jpeg               conda-forge/linux-64::jpeg-9d-h36c2ea0_0
...
  libpng             conda-forge/linux-64::libpng-1.6.37-h21135ba_2
...
  pillow             conda-forge/linux-64::pillow-7.2.0-py38h9776b28_2
  zstd               conda-forge/linux-64::zstd-1.5.0-ha95c52a_0
...

پکیج‌های نصب‌ شده‌ libjpeg و libpng می‌توانند در وابستگی‌های پکیج‌های دیگر باشند و یا به پکیج‌های دیگری وابستگی داشته باشند. نکته‌ مهم دیگر این که آن‌ها نه صرفا در wheel که برای هر package ای در محیط Conda در دسترس هستند.

مثلا Conda می‌تواند این کار را انجام دهد زیرا یک سیستم packaging فقط برای کد پایتون نیست. به همین راحتی می‌تواند کتابخانه های به اشتراک گذاشته‌ شده یا فایل‌های اجرایی را package کند.

conda در مقابل Pip

تفاوت اساسی بین packaging این دو در چیزی است که آن‌ها در packageها قرار می‌دهند.

بسته های Pip کتابخانه‌های پایتون مانند NumPy یا matplotlib هستند.

بسته‌های Conda شامل کتابخانه‌های پایتون (NumPy یا matplotlib)، کتابخانه‌های C (libjpeg) و فایل‌های اجرایی (مانند کامپایلرهای C و حتی خود مفسر پایتون) هستند.

سوالی که در این بخش مطرح می‌شود این است که چرا Conda همه چیز را package می‌کند.؛ در واقع چرا Conda تصمیم گرفته است که همه چیز از جمله مفسر پایتون را package کند؟ این کار چه سودی می‌تواند داشته باشد؟ تا حدودی در مورد portable بودن و تکرارپذیری است.

Portability across operating systems

به جای نصب پایتون به سه روش مختلف در لینوکس، macOS و ویندوز، می‌توانید از محیطی یکسان در هر سه استفاده کنید.

Reproducibility

امکان پین کردن تقریباً کل stack، از مفسر پایتون به بالا وجود دارد.

Consistent configuration

شما نیازی به نصب packageهای سیستمی و packageهای پایتون به دو روش مختلف ندارید. (تقریباً) همه چیز می‌تواند در یک فایل، environment.yml قرار گیرد.

اما مشکل دیگری را نیز برطرف می کند: نحوه برخورد با کتابخانه‌های پایتون که به کد کامپایل شده نیاز دارند.

PyPI vs. Conda-Forge

در این بخش از آموزش Package manager ها از آموزش برنامه‌نویسی پایتون به مقایسه‌ اجمالی دستورات Conda-Forge و PyPi می‌پردازیم. یکی دیگر از تفاوت‌های اساسی بین pip و Conda کمتر در مورد خود ابزارها است، و بیشتر در مورد repositoryهای پکیج‌هایی است که با آن‌ها کار می‌کنند. و نحوه کار آن‌ها.

به طور خاص، بیشتر برنامه‌های پایتون به کتابخانه‌های open source متکی هستند و اینها باید از جایی دانلود شوند. برای این موارد، pip به PyPI متکی است، در حالی که Conda از چندین “channel” مختلف میزبانی شده در Anaconda پشتیبانی می‌کند.

کانال پیش‌فرض Conda توسط Anaconda Inc، شرکتی که Conda را ایجاد کرده است، نگهداری می‌شود. که معمولاً انتخاب بسته محدودی دارد و تا حدودی کمتر به‌روز است، با برخی از مزایای بالقوه در مورد پایداری(stability) و پشتیبانی GPU.

اما کانال دیگری به نام Conda-Forge نیز وجود دارد که بسته‌های بسیار بیشتری را پکیج می‌کند، به‌روز است و احتمالاً جایی است که می‌خواهید بیشتر اوقات بسته‌های Conda خود را دریافت کنید.

اگر بسته‌های GPU کانال پیش‌فرض را می‌خواهید، می‌توانید پکیج‌های مورد نیاز خود را از کانال پیش‌فرض و Conda-Forge استخراج کرده و استفاده کنید.

بیایید PyPI را با Conda-Forge مقایسه کنیم.

PyPI

بسته‌ها در PyPI معمولاً توسط خود تیم مرکزی توسعه‌ Python آپلود می‌شوند. به عنوان مثال، توسعه‌دهند‌ه ی Fil memory profiler ، بسته  PyPI package را نیز ایجاد کرده است.

هر توسعه‌دهنده‌ پکیجی ممکن است بسته‌های خود را به روش خاص خود کامپایل کرده یا بسازد، زیرساخت خود را حفظ کند، گزینه‌های کامپایل خود را انتخاب کند و غیره.

به عنوان مثال، NumPy می‌تواند به چندین کتابخانه مختلف BLAS برای عملیات جبر خطی سریع تکیه کند. نگهدارندگان تصمیم گرفته‌اند پکیج‌های PyPI خود را با OpenBLAS بسازند. اگر گزینه دیگری مانند MKL سریعتر اینتل (شاید؟) می‌خواهید، شانسی ندارید مگر اینکه بخواهید خودتان کد را کامپایل کنید.

Conda-Forge

Conda-Forge یک پروژه جمعی است که در آن توسعه‌دهندگان پکیج‌ها می‌توانند با مولف‌های اصلی آن‌ها متفاوت باشند.

به‌جای ساخت‌های سفارشی که توسط هر نگهدارنده بسته‌‌ای متفاوت انجام می‌شود، Conda-Forge سیستم‌های ساخت متمرکزی دارد که کتابخانه‌ها را دوباره کامپایل می‌کنند، مخازن دستورها را به‌روزرسانی می‌کنند و به طور کلی همه چیز را به طور انبوه خودکار می‌کنند.

به عنوان مثال، هنگامی که نسخه جدیدی از پایتون 3 منتشر می شود، یک به روزرسانی متمرکز اتفاق می افتد، همه نگهدارنده‌های بسته فردی با افزودن بسته‌های جدید، PR دریافت می کنند. در PyPI این به تک تک نگهدارنده‌ها بستگی دارد که بفهمند.

از آنجایی که زیرساخت پکیج کردن متمرکز است، Conda-Forge می‌تواند به شما اجازه دهد که مثلا در کتابخانه‌هایی نظیر NumPy و SciPy و هر بسته دیگری که استفاده می‌کنید که به BLAS متکی است انتخاب کنید که از کدام BLAS استفاده کنید.

خودتان کدی را برای Conda-Forge پکیج کنید

از آنجایی که Conda-Forge برای پکیج کردن نیازی به توسعه‌دهندگان کد ندارد، هر کسی می تواند داوطلب شود تا بسته‌ای را به Conda-Forge اضافه کند.

برای بسیاری از بسته‌های پایتون، این فرآیند به‌طور شگفت‌انگیزی آسان و کاملاً خودکار است، بنابراین مدیریت نسخه‌های جدید اغلب به آسانی تأیید یک PR ایجاد شده خودکار است.

استفاده از pip در داخل Conda Environments 

گاهی اوقات ممکن است به pure Python packages(بسته‌هایی که عموما صرفا در PyPI موجودند.) نیاز داشته باشید و به طور کلی این بسته‌ها در کانال‌های Conda در دسترس نیستند.

در حالی که Conda-Forge بسته‌های زیادی دارد، اما همه آنها را ندارد. بسیاری از بسته‌های پایتون را فقط می‌توان در PyPI پیدا کرد. شما می‌توانید با کمبود این بسته‌ها به روش‌های مختلفی تعامل کنید.

محیط‌های Conda در واقع wrapperهایی برای virtualenvs هستند. به این ترتیب شما فقط می‌توانید pip install را در این محیط‌ها نیز فراخوانی کنید. و به طور کلی اگر از این محیط‌ها برای نصب بسته های Conda خود استفاده می‌کنید، می‌توانید بسته‌های پیپ را نیز اضافه کنید.

name: myenv
channels:
  - conda-forge
dependencies:
  - python=3.9
  - numpy
  - pandas
  - gnuplot
  - pip:
      # Package that is only on PyPI
      - sandu

به عنوان مثال، اگر unipath را جستجو کنید، بسته‌ای که با مسیرهای فایل در پایتون سروکار دارد، Conda نمی‌تواند آن را پیدا کند.

می توانید بسته را در اینجا جستجو کنید و از کانال دیگری برای نصب آن استفاده کنید. با این حال، از آنجایی که unipath یک بسته پایتون خالص است، می‌توانید از pip برای نصب آن استفاده کنید، همانطور که در یک راه‌اندازی معمولی پایتون انجام می‌دهید.

تنها تفاوت این است که باید از پیپ نصب شده توسط پیپ پکیج کوندا استفاده کنید. برای نشان دادن آن، اجازه دهید یک محیط جدید به نام newproject ایجاد کنیم. همانطور که قبلا ذکر شد، می توانید “… conda create”  را اجرا کنید.:

conda create --name newproject
//

در مرحله بعد برای نصب pip باید محیط را فعال کرده و فرمان نصب بسته pip به وسیله‌ی Conda را اجرا کنید:

(base) C:\Users\IEUser>conda activate newproject

(newproject) C:\Users\IEUser>conda install pip
Solving environment: done
...

در نهایت، از pip برای نصب بسته unipath استفاده کنید:

(newproject) C:\Users\IEUser>pip install unipath

پس از نصب، می‌توانید بسته‌های نصب شده را با conda list لیست کنید و بررسی کنید که Unipath با استفاده از pip نصب شده است:

(newproject) C:\Users\IEUser>conda list

همچنین امکان نصب بسته‌ها از سیستم کنترل نسخه (VCS) با استفاده از pip وجود دارد. به عنوان مثال، اجازه دهید supervisor، نسخه 4.0.0dev0 را نصب کنیم، که در یک مخزن Git موجود است. از آنجایی که Git در محیط newproject نصب نشده است، ابتدا باید آن را نصب کنید:

(newproject) C:\Users\IEUser> conda install git

سپس، supervisor را با استفاده از pip برای نصب آن از مخزن Git نصب کنید:

(newproject) pip install -e git://github.com/Supervisor/supervisor@abef0a2be35f4aae4a4edeceadb7a213b729ef8d#egg=supervisor

پس از اتمام نصب، می‌توانید مشاهده کنید که supervisor در لیست بسته‌های نصب شده لیست شده است:

(newproject) C:\Users\IEUser>conda list
#
# Name                    Version                   Build  Channel
certifi                   2018.8.24                py37_1
git                       2.18.0               h6bb4b03_0
meld3                     1.0.2                     <pip>
pip                       10.0.1                   py37_0
python                    3.7.0                hea74fb7_0
setuptools                40.2.0                   py37_0
supervisor                4.0.0.dev0                <pip>

... (more)

بررسی اجمالی تفاوت دستور‌ها در Conda و Pip

در پایان بخش پایانی از آموزش Package manager ها از آموزش برنامه‌نویسی پایتون به مقایسه‌ اجمالی دستورات Conda و Pip می‌پردازیم.

در مقالات بعدی آموزش مبانی زبان Python، مطالب را پی گرفته و بیش‌تر در مورد package manager ها صحبت خواهیم کرد.

همچنین می‌توانید از سسله مقالات آموزش مبانی زبان MQL5 سایت جهان بورس استفاده نمایید.