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 प्रॉक्सी एंडपॉइंट वापरू शकते. दुसऱ्या डाउनलोडरद्वारे यशस्वी स्थापना या क्लायंटची संरचना किंवा या विनंतीसाठी प्रॉक्सीची उपलब्धता यांपैकी काहीही सिद्ध करत नाही.

संबंधित लेख