אתם בטח שואלים את עצמכם - למה שאכתוב פוסט על גרסה כל כך ספציפית של 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 טוענים שזה שינוי גדול - לאחר שדרוג לגרסה החדשה, הרבה מפתחים לא יוכלו להתקין את תלויות הפרוייקט שלהם וזה ידרוש מהם לבצע שינויים בתלויות.
על אף שהשינוי הופך את התקנת התלויות למגבילה יותר, זהו שינוי מאוד חיובי.
אחרי 10 שנים בתחום, ו3 שנים במיקרוסופט, סוף סוף הגעתי לדרגה המיוחלת - סיניור. את הקריירה שלי התחלתי בצבא, 3 שנים סדיר, שנה וחצי קבע, (בתוך כל זה גם ניהלתי צוות כשנתיים), יצאתי לאזרחות להיות ״סיניור״ בסטארטאפ, הייתי שם שנתיים וקצת ואז התחלתי להתראיין למיקרוסופט. המגייסת פנתה אליי, היו לי ארבעה ראיונות לא רעים בכלל, ואז בשיחת השכר היא אמרה לי ״אתה מיועד לדרגת Software Engineer II״. ישר שאלתי בביטחון מופרז - ״למה לא סיניור? היום אני מתפקד כסיניור ויש לי 7 שנות ניסיון״ ואז היא ענתה משפט שלקח לי קצת זמן להבין כמה הוא נכון - ״כולם פה היו סיניור לפני שהגיעו למיקרוסופט״. אז קיבלתי את ההצעה והזכות להגשים את החלום ולהצטרף למיקרוסופט, והיום, 3 שנים אחרי קודמתי שתי דרגות (מ61 ל 63) וקיבלתי את הטייטל - סיניור. בפוסט הזה אני רוצה לשתף קצת ממה שלמדתי בדרך. למרות שבכל חברה יש מערכת קידומים שונה, אני מאמין שהנקודות הבאות יהיו רלוונטיות לכל עובד בכל חברה. חשוב לי להגיד, זה לא פוסט best practices לקידום, אלא החוויה האישית שהתאימה לפרופיל, לאישיות ולחוזקות שלי ולא בהכרח תהיה דומה בין עובד לעובד. שלושת מעג...
תשתית הפיתוח 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. בלחיצה על השורה יהיה אפשר לראות כל מיני ש...
אחד הדברים שלקח לי זמן להתרגל אליהם בראסט היה העובדה שאין method overloading וגם אין תמיכה בערכים דיפולטיים לפרמטרים של בפונקציות. כלומר, באותו ה namespace תוכל להיות לנו רק פונקציה אחת עם אותו השם וכשאנחנו מגדירים פונקציה אנחנו לא נוכל לקבוע לפרמטרים שלה ערכים דיפולטיים כדי להקל על המשתמש ב API. זאת להבדיל משפות כמו C#, C++, Java שתומכות ביכולות. בפוסט הזה נדבר על איך Builder Pattern יכול לעזור לנו להתגבר על המגבלות הללו. מה זה Builder Pattern ה"בילדר" היא תבנית עיצוב ממשפחת ה " creational " שמאפשרת לנו לייצר אובייקטים בצורה של הדרגתית וגמישה יותר משימוש ב constructor רגיל. באמצעות הבילדר נוכל להפריד את הרכבת שדות האובייקט מיצירתו בפועל. התבנית שמישה ב Rust במיוחד משום שבאמצעותה אנחנו יכולים לייצר מבנים (structs) מורכבים, לבחור אילו שדות נרצה לאתחל, וגם לתת ערך דיפולטי לאיזה שדה שנרצה. מימוש ה Builder נתחיל בלייצר struct פשוט של Person שיכיל שדות שנהפוך לאופציונאליים בעוד רגע באמצעות הבילדר. השלבים הבאים יהיו: 1. נייצר מבנה של PersonBuilder שיהיה אחראי על בניית הא...
תגובות
הוסף רשומת תגובה