Closed jaykayone closed 9 years ago
il y a d'ailleurs le même comportement avec setuptools-git
Ça semble une histoire de SSL/https à nouveau. Est-ce que la commande suivante fonctionne chez vous:
pip install https://pypi.python.org/packages/source/n/nosexcover/nosexcover-1.0.8.tar.gz#md5=b1d42ccd372e048233d4be65555270b0
(Avec https donc)
Oui ca fonctionne sans problème.
Par contre si je télécharge le fichier depuis le site camptocamp à l’aide par exemple d’un wget , le fichier .gz n’est pas un fichier zip valide. Il semble être altéré. Si je fais la même opération depuis le site de python ca passe sans problème.
le fichier .gz n’est pas un fichier zip valide.
On est d'accord qu'un fichier gz et un fichier zip ne sont pas du tout identique!
Oui nous sommes d'accord qu'un .gz n'est pas fichier zip valide.
Ce que je voulais dire c'est que le fichier que j'obtiens depuis le site de python je peux le "gunziper" tandis que celui que j'obtiens depuis chez camptocamp je ne peux pas.
Le 26 novembre 2014 12:38, Stéphane Brunner notifications@github.com a écrit :
le fichier .gz n’est pas un fichier zip valide.
On est d'accord qu'un fichier gz et un fichier zip ne sont pas du tout identique!
— Reply to this email directly or view it on GitHub https://github.com/Geoportail-Luxembourg/geoportailv3/issues/83#issuecomment-64580738 .
Renaud Michaëlis, 53 rue de Roloux 4347 Fexhe-Le-Haut-Clocher Tel : 04/222 43 46 GSM: 0496/294083
@rmichaelis je ne comprends pas pourquoi tu parles du pypi Camptocamp ici (et du problème de zip), parce que dans la description initiale de cet issue le téléchargement de nosexcover posant problème est fait depuis le pypi officiel et non le pypi de Camptocamp. Voici en effet ce que je vois dans l'output de la commande collée dans la description de l'issue :
Download error on https://pypi.python.org/simple/nosexcover/: [Errno 1] _ssl.c:504: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol -- Some packages may not be found!
** Couldn't find index page for 'nosexcover' (maybe misspelled?)
Download error on https://pypi.python.org/simple/: [Errno 1] _ssl.c:504: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol -- Some packages may not be found!
No local packages or download links found for nosexcover==1.0.8 **
Oui effectivement désolé c'était plutôt en relation avec le bug #84 et le MD5 qui ne passe pas.
@rmichaelis merci pour la confirmation.
C'est étrange qu'on n'arrive pas à télécharger nosexcover
quand on installe le projet avec pip install -r requirements
(ce que fait le Makefile) alors qu'un pip install nosexcover
en HTTPS fonctionne.
@sbrunner, c'est peut-être lié au fait que nosexcover
est une dépendance de type setup
?
@jaykayone @rmichaelis vous pouvez essayer de forcer l'installation de nosexcover
avant celle du projet pour voir ce que ça donne. Avec ce contenu pour requirements.txt
:
--index-url http://pypi.camptocamp.net/pypi
--find-links http://pypi.camptocamp.net/internal-pypi/index/c2cgeoportal
nosexcover==1.0.8
-e git+https://github.com/camptocamp/pyramid_closure#egg=pyramid_closure
-e .
Non toujours le même problème
en voyant l'erreur
Download error on https://pypi.python.org/simple/: [Errno 1] _ssl.c:504: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol -- Some packages may not be found!
on dirais que l'on a perdu les informations du proxy ...
et si on ajoute dans le fichier requirements.txt
?:
--proxy=http://username:password@server:port
http://stackoverflow.com/questions/23980593/pypi-cannot-install-behind-proxy
@sbrunner, à noter que
pip install https://pypi.python.org/packages/source/n/nosexcover/nosexcover-1.0.8.tar.gz#md5=b1d42ccd372e048233d4be65555270b0
fonctionne pour eux (derrière le proxy) !
On est bien d'accord mais je n'arrive pas cerner ou est le problème ...
Je suis aussi tomber sur ce poste:
http://stackoverflow.com/questions/21135637/error140770fcssl-routinesssl23-get-server-hellounknown-protocol
on est d'accord que la commande openssl s_client -connect pypi.python.org:443
retourne bien des information de certificat?
"pip install -r requirements.txt --proxy=http://proxy:3128" ne change rien
Malheureusement Il semble que openssl n'est pas prévu pour tourner derrière un proxy.
le fait que ce soit un dépendance d'un autre type me paraît une bonne piste. Peut-être que le proxy n'est pas correctement utilisé pour ce type de dépendances?
On Wed, Nov 26, 2014 at 3:33 PM, rmichaelis notifications@github.com wrote:
Malheureusement Il semble que openssl n'est pas prévu pour tourner derrière un proxy.
— Reply to this email directly or view it on GitHub https://github.com/Geoportail-Luxembourg/geoportailv3/issues/83#issuecomment-64653545 .
Jeff Konnen
le fait que ce soit un dépendance d'un autre type me paraît une bonne piste. Peut-être que le proxy n'est pas correctement utilisé pour ce type de dépendances?
Oui, c'est ce que je me disais aussi. C'est aussi pour ça que j'ai suggérer de forcer l'installation de nosexcover avant celle du projet (en ajoutant nosexcover dans requirements.txt) mais ça ne règle pas le problème.
Non en effet ça ne règle pas le problème. La seule chose qui fonctionne c'est de les installer de manière explicite (nosexcover==1.0.8 et setuptools-git) avant de faire le pip install -r requirements.txt A ce moment, ça passe... Dans le setup.py de c2cgeoportal on voit en effet que nosexcover est défini comme setup_requires setuptools-git doit être une dépendance dans un autre package qui est définie de la même manière
Non en effet ça ne règle pas le problème. La seule chose qui fonctionne c'est de les installer de manière explicite (nosexcover==1.0.8 et setuptools-git) avant de faire le pip install -r requirements.txt A ce moment, ça passe...
Le package nosexcover est utilisé pour l'exécution des tests de c2cgeoportal. Il est inutile dans un projet. Je me demande donc si on ne devrait pas avoir un autre moyen de l'installer dans c2cgeoportal pour éviter ce problème.
C'est une bonne question, mais avec buildout c'est pas facile à le résoudre, je pense que le mieux c'est d'attaque le problème quand on va passé à make.
L'installation de nosexcover par le make ne passe pas. en utilisant un pip install manuel, il n'y a pas de souci par contre