אתם בטח שואלים את עצמכם - למה שאכתוב פוסט על גרסה כל כך ספציפית של 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 טוענים שזה שינוי גדול - לאחר שדרוג לגרסה החדשה, הרבה מפתחים לא יוכלו להתקין את תלויות הפרוייקט שלהם וזה ידרוש מהם לבצע שינויים בתלויות.
על אף שהשינוי הופך את התקנת התלויות למגבילה יותר, זהו שינוי מאוד חיובי.
מבוא בתעשייה יש כיום שיח סוער מאוד על ההבדל בין אוטומציה לבין פיתוח. בעוד שיש אנשים שאומרים שאוטומציה זה פיתוח לכל דבר ומי שכותב אוטומציה צריך להסתכל על עצמו כעל מפתח, יש אנשים שרואים בפיתוח אוטומציה כתחום ששווה פחות, מתגמל פחות ודורש פחות הכשרה. הפוסט הזה אינו עוד שיחת מוטיבציה עם מסר של ״גם מפתחי אוטומציה הם מפתחים וצריך להתייחס אליהם ככה״. מטרת הפוסט היא להציג את נקודת מבטי האישית על תחום האוטומציה, על ההבדל בינו לבין תחום פיתוח התוכנה ה״רגיל״ לנסות לתת מענה לשאלה - מדוע אנשים רואים פער בין התחומים? קודם כל, מה זה פיתוח אוטומציה? יש הרבה הגדרות ל״מה זה אוטומציה״ ואני חושב שזו אחת הסיבות המרכזיות לדיון הבלתי נגמר על ההבדלים. כשאני מדבר על אוטומציה אני מדבר על כל קוד שנכתב כדי לעזור לנו לקדם את התהליכים שאחרת היו נעשים באופן ידני. כללי, נכון? זו בדיוק המטרה (בהמשך הפוסט נראה בדיוק למה ההגדרה כללית כל כך וכלל לא משנה). לפי ההגדרה הזו, כתיבת הספרייה selenium היא כתיבת אוטומציה, אם ניקח את זה קצת יותר רחוק, גם כתיבת המערכת jenkins היא אוטומציה. האם Jason Huggins ו Simon Stewart, שניים
זהו פוסט קצר שמטרתו להציג את תבנית העיצוב singleton ומדוע אינני ממליץ להשתמש בה. הפוסט הינו חלק מסדרה שמטרתה לדבר על כתיבת קוד רע ו-anti-patterns בתחום עיצוב התוכנה. מה זה סינגלטון סינגלטון היא תבנית עיצוב ממשפחת ה creational, שמטרתה להגביל את יצירת המופעים של מחלקה מסוימת למופע יחיד, משתמשים בתבנית הזו על מנת שלא ליצור התנגשות בין אובייקטים בפעולות כמו כתיבה לזכרון, קובץ דאטאבייס וכו׳. אופן המימוש של סינגלטון הוא די פשוט. כל מה שצריך זה מחלקה עם field פרטי שמטרתו לשמור על האובייקט המאותחל. ופונקציית אתחול שמאתחלת את האובייקט במידה ולא אותחל כבר. באופן הזה נקרא כל פעם למופע המחלקה באמצעות הפונקציה get_instance ונקבל את אותו המופע. למה לא להשתמש בו סינגלטון היא תבנית פשוטה מאוד, אבל האמת היא שאין מתנות חינם. הנה 4 סיבות (מהקלה לחמורה) לכך שאני חושב שלא כדאי להשתמש בסינגלטון: בזבזנות בזיכרון שימוש בסינגלטון הוא אינו יעיל בהיבטי זיכרון כשמדובר על סביבות בהן יש garbage collector . במקרים בהם משתמשים בסינגלטון בשפות כאלו (כמו java ופייתון), השפה מגדירה את האובייקט כחשוב (מכיוון שיש אליו רפ
לאחר שהבנו את יתרונות פיתוח האוטומציה ופיתחנו בדיקת אוטומציה ראשונה באמצעות NUnit הגיע הזמן שנגיע לתכלס.. כיום קיימים בשוק מגוון כלים בשוק, בסגנון קוד פתוח, שמגיעים על מנת להקל, ולתת גמישות ויכולות נוספות בנושא האוטומציה. מה זה Selenium? סלניום היא תשתית האוטומציה לדפדפנים הגדולה בעולם כיום. עולם הWeb מצעיד את עולם פיתוח התוכנה (יחד עם עולם המובייל), וכך גם עולם בדיקות ה Web. כאשר אנחנו מבצעים בדיקות אוטומטיות חשוב שתהיה לנו שליטה כמה שיותר גדולה על סביבת העבודה שלנו. תשתית Selenium, מגיעה על מנת לתת פתרון פשוט, נוח, וקל לתפעול לשליטה על דפדפנים (סביבת העבודה של עולם הWeb). באמצעות השליטה הנ"ל, ניתן יהיו לבצע תרחישי בדיקה אוטומטיים אשר יבטיחו את איכות המוצר אותו אנו בודקים. איך כותבים אוטומציה באמצעות Selenium? במדריך אציג בדיקה אוטומטית פשוטה בשפת C#, כמובן על בסיס תשתית הבדיקה NUnit. *המלצה - קריאת הפוסט הזה , תקל עליך מאוד. הקמת סט-אפ הבדיקה תחילה נפתח Visual Studio וניצור פרויקט חדש מסוג Class Library (לחיצה על ctrl+shift+N
תגובות
הוסף רשומת תגובה