Ръководство за овладяване на зависимости във вашия личен проект за Data Science и намиране на възможен начин за справяне с възникващи конфликти.

Въведение

Споделянето на знания е в основата на проекта за публикации в блога на Master Data Science & Intelligent Analytics във FH Kufstein Tirol, където уча. Вижте програмата на адрес https://fh-kufstein.ac.at/Studieren/Master/Data-Science-Intelligent-Analytics-BB.

Нека бъдем честни: Библиотеките са решението за всичко! Имате проблем в рамките на проект или се нуждаете от специална функционалност, която бихте искали да избегнете сами да кодирате? Вероятно ще има някой, който е имал същия проблем преди и може вече да е разработил библиотека за това! Въпреки това, както често в живота, не всичко, което блести, е злато.

Библиотеките са много полезни, разбира се, но също толкова бързо могат да ви доведат до ситуация, в която трябва да се справите с някои „Конфликти на зависимости“. Рано или късно почти всеки разработчик на софтуер ще се окаже в този момент. Избягването му е малко по-лесно, ако проектът остане малък, но определено трябва да сте по-внимателни, щом стане по-голям.

Всъщност няма значение на какъв език за програмиране пишете своя код; за съжаление, може да се появи в почти всеки един от тях. Например, Python е добре познат език за програмиране, който идва на ум на повечето хора, когато чуят „Конфликти на зависимости“.

Какво представляват конфликтите на зависимости?

Първо, нека започнем с изясняването на термина „зависимост“ в контекста на разработката на софтуер. Зависимост е, когато част от софтуера, например пакет или библиотека, разчита на друга част от софтуера, обикновено написана от други (код на трета страна). Като цяло всеки път, когато използвате нов пакет или библиотека във вашия проект, вие също добавяте неговите зависимости. [1]

Ще ви дам прост пример как могат да изглеждат зависимостите.

Започвате работа по нов софтуерен проект; нека просто го наречем APP в текущата му версия 1. В това приложение се нуждаете от определени функционалности, които включвате чрез добавяне на нови библиотеки, LIB A (версия 1) и LIB B (версия 1). И двете, LIB A и LIB B, използват друга функционалност в своя код, LIB C (версия 1).

Един ден LIB B получава актуализация до версия 2, която внедрява най-новата версия 2 на LIB C. Засега това не засяга вашето ПРИЛОЖЕНИЕ, тъй като то все още използва версия 1 на LIB A и LIB B.

Конфликтите на зависимости възникват веднага щом искате да актуализирате вашето ПРИЛОЖЕНИЕ до версия 2, където включвате най-новата версия на LIB B. Сега това ще доведе до проблем, защото LIB A все още използва версия 1 на LIB C, докато LIB B вече зависи от LIB C (версия 2) — но е възможно да се използва само една версия на LIB C едновременно.

За да се отървете от този проблем със зависимостта, сега трябва да включите най-новата версия на LIB A, която се надяваме да зависи от същата версия на LIB C, както LIB B. Ако (все още) няма поддръжка на LIB A за използване на най-новата версия на LIB C — ДОБРЕ ДОШЛИ В СВЯТ, ПЪЛЕН С КОНФЛИКТИ НА ЗАВИСИМОСТИ!

Защо може да възникне конфликт на зависимост?

Както се опитах да ви покажа в опростена версия в раздела по-горе, една от причините може да е несъвместимостта на различни библиотеки или пакети един с друг. Обикновено, ако се използват много различни библиотеки и пакети, те са разработени от много различни хора в различни моменти от време и в много случаи тези библиотеки вече не се поддържат.

Едва ли имате контрол над всички тези библиотеки. Ако разработчикът на една библиотека, която използвате, реши да актуализира своята и да добави функционалност или да премахне части от кода (по каквато и да е причина), това може да е началото на нови конфликти на зависимости.

Конфликт може да възникне и защото библиотеката на трета страна може да не използва добре написан код или може да има липса на добра документация за тази библиотека. И в двата случая може да бъде много досадно, когато внезапно се появи бъг, но нямате (или едва ли) имате възможност да се отървете от него.

Но мога ли да го избегна?

На теория, разбира се, можете да го избегнете. Но - особено ако не използвате мениджъри на пакети в някои езици за програмиране, като например "Anaconda" - вероятно е почти невъзможно НАИСТИНА да избегнете конфликти на зависимости. Въпреки това има няколко съвета, които може да имате предвид, които могат да ви помогнат да го избегнете възможно най-добре. И така, започваме:

Преди да използвате библиотека:

  • Възможно ли е по някакъв начин да се използва мениджър на пакети като „Anaconda“? Ако отговорът е да, силно се препоръчва да го направите.
  • Помислете за проблема, който искате да разрешите. Колко усилия би било да кодирате сами? Би ли било възможно (сега или на по-късен етап от разработката) да се отървете от тази конкретна библиотека в даден момент?
  • Ако е възможно, проверете брояча на изтеглянията и рейтинга на библиотеката. Популярен ли е, който много хора вече използват, или не е толкова известен?
  • Библиотеката включва ли и много зависимости? Ако това е така, това може да доведе до конфликти още по-рано.
  • Проверете документацията: добре ли е написана и достатъчно подробна, за да работите с тази библиотека?
  • Колко версии/актуализации/поправки на грешки са пуснати досега за тази библиотека? Дали е добре поддържан и актуализиран редовно, или все още има версия 0.0.1, която беше пусната преди десет години и никога повече не е пипана?

Докато използвате библиотека:

  • Проверете манифеста, ако сте добавили/премахнали много пакети и библиотеки. Съвпада ли манифестът с пакетите, които наистина използвате?
  • Има ли други налични библиотеки, които предлагат същата функционалност? (Може би тази стъпка включва няколко адаптации на кода.) Ако да, можете да замените библиотеките.
  • Ако е възможно, можете да опитате да разклоните и поправите библиотеки с отворен код, да натиснете тези промени и да се надявате, че поддържащият приеме корекцията.

Още два съвета:

  • Наблюдавайте как библиотеката влияе на производителността на вашето приложение. Подобрява ли работата си? Или му се отразява по лош начин? Може би има наличен по-лек.
  • Можете да заключите версията на вашия проект, което определено ви помага да избегнете конфликти на зависимости. Тази стъпка обаче означава, че вече не можете да прилагате нови функции или подобрения на използваните от вас библиотеки, тъй като трябва да се придържате към избраната версия. [2]

Как да управлявате вашите зависимости

Вече чухте няколко съвета, които може да обмислите по време на следващия си проект Data Science. Като следваща стъпка, позволете ми да ви кажа някои възможни начини за това как можете да управлявате зависимостите си по правилен начин.

Първоначално е необходимо да зададете някои насоки в екипа как искате да се справите със зависимостите. Искате ли да се придържате към конкретна версия, знаейки, че може да е уязвима в даден момент? Или поемате риска, който идва с актуализирането на зависимост? [3] Създайте правила, които всеки член на екипа трябва да следва; това ще ви помогне по време на проекта и със сигурност предотвратява разочарованието!

Приоритетизирането на вашите зависимости също е много важно. Не всеки един е толкова важен, колкото друг. Ако е възможно, опитайте първо да актуализирате вашата приоритетна зависимост. Това има няколко предимства: имате по-добър преглед на зависимостите, които все още трябва да бъдат актуализирани, и тези, които вече сте актуализирали, и тези актуализации могат да коригират потенциални проблеми със сигурността.

Управлението на зависимостите с Anaconda може да бъде малко по-лесно, тъй като ще следи средата, която използвате. Независимо от това, без да се грижите за околната среда, тя може да стане доста голяма за кратък период от време.

Обобщение

Конфликт на зависимост може да възникне в почти всеки проект за разработка на софтуер. Комбинацията от използване на много библиотеки на трети страни (особено библиотеки, които може да не се поддържат по правилен начин) в проект за по-дълъг период от време може да доведе до няколко проблема, свързани с различни версии на тези библиотеки поради преходни зависимости. Наистина е трудно напълно да избегнете попадането в тази ситуация, но може би някои от съветите, които прочетете в тази статия, ще помогнат.

  • Използвайте мениджъри на пакети, ако е възможно
  • Опитайте се да отървете от конкретна библиотека
  • Използвайтепопулярни библиотеки
  • Опитайте да избягвате библиотеки, които вече имат много зависимости
  • Проверете доколко е добра документацията
  • Използвайтедобре поддържанибиблиотеки
  • Следете вашияманифест
  • Използвайте други библиотеки със същата функционалност
  • Поправете сами библиотеки с отворен код
  • Използвайте олекотени библиотеки, ако е възможно
  • Заключване на версия на вашия проект

Заключение

Библиотеки, пакети, зависимости като цяло — използването им е и вероятно винаги ще бъде част от това да си разработчик, специалист по данни или софтуерен инженер. Обикновено те могат да ни спестят много време в сравнение с кодирането на важна функционалност от нулата. Конфликтите на зависимости може да изглеждат страшни в началото и е още по-лесно да се справите с тях, но ако имате предвид няколко лесни съвета, можете да победите конфликтите и да овладеете зависимостите!

Надявам се да ви е харесало да прочетете тази статия и може би тя ще ви помогне малко в следващия ви проект. Благодаря ти!

Препратки

[1] Prana, G.A.A., Sharma, A., Shar, L.K. и др. Извън полезрението, далеч от ума? Как уязвимите зависимости влияят върху проектите с отворен код. Empir Software Eng 26,59 (2021). https://doi.org/10.1007/s10664-021-09959-3

[2] Танабе Й., Аотани Т. и Масухара Х. 2018 г. Контекстно-ориентиран програмен подход към ада на зависимостите. В сборника на 10-ия международен семинар по контекстно-ориентирано програмиране: Разширена модулност за композиция по време на изпълнение (COP ‘18). Асоциация за компютърни машини, Ню Йорк, Ню Йорк, САЩ, 8–14. DOI: https://doi.org/10.1145/3242921.3242923

[3] Pashchenko I., Vu D. и Massacci F. 2020. Качествено изследване на управлението на зависимостите и неговите последици за сигурността. В сборника на конференцията ACM SIGSAC за компютърна и комуникационна сигурност (CCS ‘20) през 2020 г. Асоциация за компютърни машини, Ню Йорк, Ню Йорк, САЩ, 1513–1531. DOI: https://doi.org/10.1145/3372297.3417232