אתם בטח שואלים את עצמכם - למה שאכתוב פוסט על גרסה כל כך ספציפית של pip?
אז התשובה פשוטה. לפני מספר חודשים המפתחים של pip הכריזו על גרסה עם שינוי גדול ולפני כשבועיים בתאריך 30/11/20 יצאה גרסה 20.3 שכוללת שינוי די רציני. כל כך רציני שהמפתחים אשכרה עשו על זה סרטון.
חשוב לי לציין שפוסט הזה לא הולך לדבר על היכולות של pip או על איך משתמשים בו, כתבתי על זה קצת כאן.
מה בעצם הגרסה מגיעה לפתור?
אחד הפיצ׳רים החסרים של pip, שמשתמשים לא הפסיקו לבקש הוא dependency resolver.
עד היום בכל פעם כשהתקנו חבילות באמצעות pip הוא היה מתאמץ מאוד לספק לנו מבנה תלויות נכון לפי התלויות שסיפקנו לו אבל לא תמיד היה מצליח.
למה אני מתכוון:
נניח שביקשנו מ pip להתקין את החבילות הבאות:
pip install "six<1.12" "virtualenv==20.0.2"
בתמימותינו אנחנו נצפה שתתוקן לנו גרסה קטנה מ1.12 של הספריה six וגרסה 20.0.2 של virtualenv.
אבל מה קורה אם אחת מתתי התלויות של virtualenv בגרסה 20.0.2 היא six בגרסה שגדולה מ-1.12?
כלומר - בהרצת הפקודה שראינו למעלה, pip ינסה להתקין את החבילה six עם ההגבלה שניתנה לו, ימצא את גרסה 1.11 ויתקין אותה, לאחר מכן ינסה להתקין את virtualenv ואז יתקל בקונפליקט.
מה שעשינו כאן זה בעצם לבקש מ pip להתקין את six גם בגרסה קטנה מ1.12 וגם בגרסה גדולה מ1.12.
מה היה עד עכשיו?
עד הגרסה הנוכחית, שורת התקנה כזו הייתה מספקת לנו את הגרסאות הללו six==1.11.0
virtualenv==20.0.2. כלומר, six הייתה מותקנת בניגוד להנחיות של virtualenv, דבר שמן הסתם יכל לגרום לנו לבעיות בעבודה עם virtualenv. הרי כנראה לא סתם virtualenv ביקשו במיוחד גרסה שגדולה מ1.12.0.
מה קורה החל מגרסה 20.3?
החל מהגרסה החדשה pip לא יקבל יותר קונפליקטים כאלו ויזרוק שגיאה בעת התקנה כמו שניסינו לעשות.
הפלט שאנחנו הולכים לקבל במקרה יראה כך:
ERROR: Cannot install six<1.12 and virtualenv 20.0.2 because these package versions have conflicting dependencies.
The conflict is caused by:
The user requested six<1.12
virtualenv 20.0.2 depends on six<2 and >=1.12.0
To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict
למזלנו החברה של pip עבדו חזק על חווית המשתמש וקיבלנו פלט פשוט ואינטואיטיבי שמסביר לנו בדיוק מה קורה, ואפילו נותן לנו המלצות להתמודדות.
במקרה כמו שלנו עלינו לשאול את עצמינו - למה אנחנו מגיבילים את עצמנו לגרסה ישנה של six? עלינו להבין בדיוק
איך עוברים לגרסה החדשה בשלום?
החבר׳ה של pip פינקו אותנו בגרסאות 20.1 ו20.2 שמאפשרות לנו להשתמש בפיצ׳ר של החדש של dependency resolver בעת ההתקנה ולראות מה יקרה כשננסה להתקין.
לפני שנשדרג לגרסה החדשה, אנחנו נרצה לשדרג לגרסה 20.2 עם הפקודה: pip install pip==20.2
ה-flag יפעיל את הפיצ׳ר החדש של הגרסה ויתן לנו מידע מהימן בנוגע לתקינות התלויות שלנו.
סיכום
בפוסט דיברנו על הגרסה החדשה של pip בה נכנס לראשונה dependency resolver כברירת מחדל.
ניתן להבין למה המפתחים של pip טוענים שזה שינוי גדול - לאחר שדרוג לגרסה החדשה, הרבה מפתחים לא יוכלו להתקין את תלויות הפרוייקט שלהם וזה ידרוש מהם לבצע שינויים בתלויות.
על אף שהשינוי הופך את התקנת התלויות למגבילה יותר, זהו שינוי מאוד חיובי.
על מנת שהמערכות, היישומים והתשתיות שאנחנו מפתחים יהיו חזקים, יציבים וניתנים לתחזוקה ולשינויים, עלינו לדעת כיצד לעצב אותם בצורה הטובה ביותר. העקרונות הבסיסיים של תכנות מונחה עצמים לרוב אינם יספיקו למפתח בכדי לכתוב מערכת ברמה גבוהה. היום אני הולך להציג את עקרונות העיצוב SOLID. אלו הם 5 העקרונות הראשונים והחשובים ביותר בעיני של עיצוב תוכנה וקוד באמצעות תכנות מונחה עצמים. המדריכים וההסברים נכתבו בC#, אך הם מתאימים למתכנתים בכל שפה משום שהכוונה כאן היא להציג עקרונות. לאחר שהבנו את העקרונות ניתן לממשם בכל שפת OOP. תנאי קדם למדריך: היכרות עם תכנות מונחה עצמים . מה זה SOLID? S - Single responsibility principle - SRP O - Open closed principle - OCP L - Liskov substitution principle - LSP I - Interface segregation principle - ISP D - Dependency inversion principle - DIP לא, אל תצפה להבין מראשי התיבות מה כל עיקרון אומר, ראשי התיבות ושמות כאן אך ורק כדאי להזכיר לנו אילו עקרונות קיימים. בפוסטים הקרובים אסקור כל אחד מחמשת העקרונות הללו, אצל
תשתית הפיתוח Net. מכילה מאות ספריות מובנות בהן אפשר להשתמש על מנת להקל על עצמנו בפיתוח הקוד. היום נלמד כיצד ניתן להוסיף אותן לפרויקט שלנו ואיך להשתמש בהן. במדריך איך ליצור מחשבון בC# אפשר לראות בתחילת הקוד שאנחנו כותבים את השורה using System.Linq; השורה הזו בעצם מייבאת לנו את הקוד הקיים ב System.Linq - namespace ומאפשרת לנו להשתמש בכל הטיפוסים והפונקציונאליות הקיימות בו. ניתן יהיה לראות שאם נמחק את שורת ה using נקבל שגיאת קומפילציה משום שהפעולה Contains לא תימצא. private static bool IsValidOperation(string input) { return operations. Contains(input) ; // פעולה אשר בודקת האם ערך מסוים קיים במערך } אבל רגע.. מאיפה התכנית שלנו מכירה את ה System.Linq - namespace? כאן קבצי ה DLL נכנסים לתמונה. אם נכנס ל Solution Explorer שלנו (ctrl+alt+L) ניתן יהיה לראות תחת הפרויקט Calculator שורה הנקראת References. בלחיצה על השורה יהיה אפשר לראות כל מיני שמות בהם הפרויקט שלנו משתמש, כל אחד מהקבצים הללו הוא קובץ DLL. מהו קובץ DLL?
מבוא בתעשייה יש כיום שיח סוער מאוד על ההבדל בין אוטומציה לבין פיתוח. בעוד שיש אנשים שאומרים שאוטומציה זה פיתוח לכל דבר ומי שכותב אוטומציה צריך להסתכל על עצמו כעל מפתח, יש אנשים שרואים בפיתוח אוטומציה כתחום ששווה פחות, מתגמל פחות ודורש פחות הכשרה. הפוסט הזה אינו עוד שיחת מוטיבציה עם מסר של ״גם מפתחי אוטומציה הם מפתחים וצריך להתייחס אליהם ככה״. מטרת הפוסט היא להציג את נקודת מבטי האישית על תחום האוטומציה, על ההבדל בינו לבין תחום פיתוח התוכנה ה״רגיל״ לנסות לתת מענה לשאלה - מדוע אנשים רואים פער בין התחומים? קודם כל, מה זה פיתוח אוטומציה? יש הרבה הגדרות ל״מה זה אוטומציה״ ואני חושב שזו אחת הסיבות המרכזיות לדיון הבלתי נגמר על ההבדלים. כשאני מדבר על אוטומציה אני מדבר על כל קוד שנכתב כדי לעזור לנו לקדם את התהליכים שאחרת היו נעשים באופן ידני. כללי, נכון? זו בדיוק המטרה (בהמשך הפוסט נראה בדיוק למה ההגדרה כללית כל כך וכלל לא משנה). לפי ההגדרה הזו, כתיבת הספרייה selenium היא כתיבת אוטומציה, אם ניקח את זה קצת יותר רחוק, גם כתיבת המערכת jenkins היא אוטומציה. האם Jason Huggins ו Simon Stewart, שניים
תגובות
הוסף רשומת תגובה