Comme décrit ici , il existe une variable d'environnement NETRC
que l'on peut utiliser pour contrôler où se trouve le fichier .netrc
. Les requêtes recherchent toujours dans le répertoire personnel de l'utilisateur.
{
"chardet": {
"version": "3.0.4"
},
"cryptography": {
"version": ""
},
"idna": {
"version": "2.6"
},
"implementation": {
"name": "CPython",
"version": "3.5.2"
},
"platform": {
"release": "14.5.0",
"system": "Darwin"
},
"pyOpenSSL": {
"openssl_version": "",
"version": null
},
"requests": {
"version": "2.18.4"
},
"system_ssl": {
"version": "100020cf"
},
"urllib3": {
"version": "1.22"
},
"using_pyopenssl": false
}
Voulons-nous toujours cette fonctionnalité ? Je veux cette fonctionnalité, mais je ne connais pas le sentiment général des utilisateurs.
Je vois que https://github.com/psf/requests/pull/4339 a été fermé car il n'était pas terminé. Je me porte volontaire pour terminer le travail avec une couverture de test et une documentation appropriées.
Cela a été ouvert très longtemps sans réponse. Comment cette affaire sera-t-elle traitée ? Ce serait une très bonne fonctionnalité à mettre en œuvre.
Ce projet a généralement eu une terrible expérience avec son support netrc. Cela crée de la confusion et n'est pas pratique à désactiver. Si quoi que ce soit, je m'attendrais à ce que les mainteneurs actuels veuillent abandonner la prise en charge de la recherche/l'analyse des fichiers netrc et la ferment comme quelque chose qu'ils ne mettront pas en œuvre. (Et ils auraient raison de le faire)
Impressionnant! Merci!
Commentaire le plus utile
Voulons-nous toujours cette fonctionnalité ? Je veux cette fonctionnalité, mais je ne connais pas le sentiment général des utilisateurs.
Je vois que https://github.com/psf/requests/pull/4339 a été fermé car il n'était pas terminé. Je me porte volontaire pour terminer le travail avec une couverture de test et une documentation appropriées.