यदि 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 प्रोक्सी एन्डपोइन्ट प्रयोग गर्न सक्छ। अर्को डाउनलोडरमार्फत सफल स्थापनाले यो क्लाइन्टको कन्फिगरेसन वा यो अनुरोधका लागि प्रोक्सीको उपलब्धता कुनै पनि स्थापित गर्दैन।

सम्बन्धित लेखहरू