R प्रॉक्सी सेटिंग्स: पैकेज डाउनलोड बनाम API अनुरोध

अगर R किसी पैकेज को इंस्टॉल कर सकता है पर वह पैकेज अपनी API तक नहीं पहुँच पाता, तो दोनों अनुरोध क्लाइंट की तुलना करें। download.file(), RCurl और पैकेज की अपनी HTTP परत को एक ही विकल्प पढ़ना ज़रूरी नहीं है।

चालू सत्र के इनपुट जाँचें

टर्मिनल से शुरू किया गया प्रोग्राम उस टर्मिनल का पर्यावरण विरासत में लेता है। डेस्कटॉप शॉर्टकट या पहले से चल रहे IDE में अलग मान हो सकते हैं। उपयुक्त R स्टार्टअप पर्यावरण फ़ाइल में यह हो सकता है:

http_proxy=http://proxy.example:8080
https_proxy=http://proxy.example:8080

ये उदाहरण एंडपॉइंट वाली पर्यावरण-फ़ाइल प्रविष्टियाँ हैं। सार्वजनिक मध्यस्थों से अनुमत सार्वजनिक पैकेज या API अनुरोधों के लिए HTTP प्रॉक्सी सूची उन मानों के लिए उम्मीदवार देती है। options(download.file.method = "libcurl") जैसे R व्यंजक R कोड में आते हैं, .Renviron में नहीं। सही दिखने वाली सेटिंग को गलत प्रारूप में रखने से वह अप्रयुक्त रह जाती है।

R के साइट/उपयोगकर्ता, पर्यावरण और कार्य-निर्देशिका नियमों से चुनी गई स्टार्टअप फ़ाइल पहचानें। परियोजना-स्थानीय फ़ाइल एक ही IDE में दो परियोजनाओं के बीच अंतर समझा सकती है। इच्छित फ़ाइल बदलें और संबंधित सत्र पुनः आरंभ करें; उसे संपादित करने से पहले से चल रही प्रक्रिया अपडेट नहीं होती।

विफल पैकेज के अनुरोध का पालन करें

वास्तविक डाउनलोड विधि या HTTP कार्यान्वयन पहचानें। बाहरी curl निष्पादन योग्य, R की libcurl विधि और RCurl अपने-अपने समर्थित इनपुट वाले अलग उपभोक्ता हैं। रहस्य छिपाकर विफल पैकेज के माध्यम से उसी गंतव्य की तुलना करें।

नुस्खों को उस कार्यान्वयन और R संस्करण के अनुरूप रखें। पुरानी Windows --internet2 सलाह ऐतिहासिक व्यवहार बताती है। वास्तविक प्रॉक्सी श्रोता की परिवहन योजना भी बनाए रखें: HTTPS गंतव्य अब भी HTTP प्रॉक्सी एंडपॉइंट का उपयोग कर सकता है। किसी अन्य डाउनलोडर से सफल इंस्टॉलेशन न इस क्लाइंट का कॉन्फ़िगरेशन सिद्ध करता है और न इस अनुरोध के लिए प्रॉक्सी की उपलब्धता।