Conda עובד דרך הפרוקסי, אבל pip לא

הפעלת סביבת Conda בוחרת סביבה; היא אינה גורמת לכל תוכנית בתוכה להשתמש בהגדרות Conda. ‏Conda ו-pip הם לקוחות הורדה נפרדים.

ל-Conda יכולים להיות נתיבי פרוקסי ב-.condarc:

proxy_servers:
  http: http://203.0.113.10:8080
  https: http://203.0.113.10:8080

ערכי הדוגמה האלה אומרים ל-Conda איך להגיע ליעדים של כל סכמה. pip אינו מאמץ אוטומטית את המיפוי proxy_servers רק מפני שהוא מותקן באותה סביבה.

בדקו את שתי התצורות

בדקו את מקורות ההגדרות של Conda ואת pip שמשויך ל-Python הפעיל:

conda config --show-sources
python -m pip --version
python -m pip config debug

הפלטים עשויים לחשוף מיקומי הגדרות שונים, מפרש לא צפוי או משתנה סביבה שאחת הבדיקות לא השתמשה בו. בדקו כתובות URL פרטיות ופרטי התחברות לפני השיתוף.

ל-pip, ‏השתמשו באפשרות הפרוקסי המתועדת שלו, בהגדרות ייעודיות ל-pip או בסביבת הרשת המתאימה. אל תעתיקו קטע YAML של .condarc ישירות לקובץ INI של pip.

גם הגדרות האמון נפרדות

הגדרת ssl_verify של Conda יכולה לציין חבילת CA או, בגרסאות ובסביבות ריצה נתמכות של Python, לבחור באמון המערכת עם truststore. זו אינה פקודה להגדרת מקור האמון של pip.

אם הפרוקסי מבצע בדיקת TLS מאושרת, בררו כיצד כל לקוח נותן אמון ברשות הזאת. בקשת Conda מוצלחת מוכיחה שהנתיב והאמון שלו פעלו עבור אותה בקשה; היא אינה מוכיחה ש-pip קיבל אותה תצורה.

השוו את היעדים בפועל

הלקוחות עשויים להשתמש באינדקסי חבילות ובמארחי קבצים שונים. מתווך שמאפשר ערוץ אחד עשוי לחסום אינדקס אחר או URL של ארכיון בשלב מאוחר יותר. בדקו את שם המארח שנכשל ואת התגובה לפני שמייחסים את ההבדל רק לסביבת Python שנבחרה.

דוח שימושי מזהה את המפרש, מקור ההגדרות של כל לקוח, המארח שהתבקש ושגיאת החיבור או התעודה הראשונה. „Conda עובד” היא נקודת התחלה להשוואה, לא בדיקה מלאה של נתיב הרשת של pip.