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-র কনফিগারেশন উৎস এবং সক্রিয় Python-এর সঙ্গে যুক্ত pip পরীক্ষা করুন:

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

আউটপুটে আলাদা কনফিগারেশন অবস্থান, অপ্রত্যাশিত ইন্টারপ্রেটার বা কোনো পরীক্ষায় ব্যবহৃত না হওয়া পরিবেশ ভেরিয়েবল ধরা পড়তে পারে। শেয়ার করার আগে ব্যক্তিগত URL ও শংসাপত্র দেখুন।

pip-এর জন্য তার নথিবদ্ধ প্রক্সি অপশন, pip-নির্দিষ্ট কনফিগারেশন বা উপযুক্ত নেটওয়ার্ক পরিবেশ ব্যবহার করুন। .condarc-এর YAML অংশ সরাসরি pip-এর INI ফাইলে কপি করবেন না।

বিশ্বাসের সেটিংও আলাদা

Conda-র ssl_verify একটি CA বান্ডল নির্দিষ্ট করতে পারে বা সমর্থিত সংস্করণ ও Python রানটাইমে truststore দিয়ে সিস্টেমের বিশ্বাস বেছে নিতে পারে। এটি pip-এর বিশ্বাসের উৎস কনফিগার করার কমান্ড নয়।

প্রক্সি যদি অনুমোদিত TLS পরিদর্শন করে, প্রতিটি ক্লায়েন্ট কীভাবে ওই কর্তৃপক্ষকে বিশ্বাস করে তা নির্ধারণ করুন। সফল Conda অনুরোধ প্রমাণ করে যে সেই অনুরোধে Conda-র নিজস্ব রুট ও বিশ্বাস কাজ করেছে; pip একই সেটিং পেয়েছে তা প্রমাণ করে না।

প্রকৃত গন্তব্য তুলনা করুন

ক্লায়েন্টগুলো আলাদা প্যাকেজ ইনডেক্স ও ফাইল হোস্ট ব্যবহার করতে পারে। একটি চ্যানেল অনুমোদন করা মধ্যস্থতাকারী অন্য ইনডেক্স বা পরের আর্কাইভ URL প্রত্যাখ্যান করতে পারে। পার্থক্য শুধু নির্বাচিত Python পরিবেশের কারণে বলার আগে ব্যর্থ হোস্টনাম ও উত্তর দেখুন।

কার্যকর প্রতিবেদনে ইন্টারপ্রেটার, প্রতিটি ক্লায়েন্টের কনফিগারেশন উৎস, অনুরোধ করা হোস্ট এবং প্রথম সংযোগ বা সার্টিফিকেট ত্রুটি থাকে। “Conda কাজ করে” তুলনার শুরু, pip-এর নেটওয়ার্ক পথের পূর্ণ পরীক্ষা নয়।