Produits Entr'ouvert » Gadjo

On a un souci c'est que setuptools/distutils n'arrive pas à générer un tarball contenant cette version, sauf dans un venv à jour. Sur jenkins je dois faire tourner le job debs dans un venv pour que ça passe.

Quand on fait un setup.py dist sous Jessie et même avec le backport de setuptools de jessie backports (backports qui par contre rejette les -g) le +g est remplacé par -g dans le nom du tarball.

Je ne vois aucune solution sans bidouille, et donc la bidouille que je préconise c'est d'apprendre à eobuilder que les tarball (et les répertoires une fois décompressés) peuvent avoir l'un ou l'autre nom et qu'il faut déplacer/renommer tout ça :/

Pour détailler; ma préoccupation ici c'était un problème rencontreé par JB à son déploiement de Publik, avec authentic qui ne démarrait pas parce qu'avec un gadjo 0.26.5.g1234567 pkg_resources sortait un VersionConflict, comme quoi la condition "gadjo>0.6" n'était pas remplie (parce qu'il considère tout numéro incompatible avec la pep 440 comme inférieur).

On a un souci c'est que setuptools/distutils n'arrive pas à générer un tarball contenant cette version, sauf dans un venv à jour. Sur jenkins je dois faire tourner le job debs dans un venv pour que ça passe.

C'est eobuilder qui lance les sdist, on pourrait juste le modifier pour qu'il fasse cette partie dans un venv, non ?

Ack, faut pousser ça, on surveille dans la semaine, mais sur du setuptools non pep-440 j'ai peur qu'on ai le même souci, on verra bien.

jenkins@jenkins:/var/lib/eobuilder/git/gadjo$ cat gadjo.egg-info/PKG-INFO 
Metadata-Version: 1.1
Name: gadjo
Version: 0.53.dev2+g690db4b

Je ne sais pas d'où vient le souci mais pas de là, tu as testé sur quelle machine la compatibilité avec a2 ?

Le message vient de authentic.dev.

Ok vu,

authentic.dev:~# head /usr/lib/python2.7/dist-packages/gadjo-0.53.dev2_g690db4b.egg-info/PKG-INFO
Metadata-Version: 1.1
Name: gadjo
Version: 0.53.dev2-g690db4b

Le build en jessie foire parce que dh_python utilise le setuptools de jessie au lieu de celui de jessie-backports qui si je me souviens bien gère PEP440. On a beau calculé correctement le egg-info lors de la génération du tarball d'origine, c'est recalculé au build du paquet python je pense.

Le tarball origin contient la bonne version:

jenkins@jenkins:/tmp/coin/gadjo-0.53.dev2+g690db4b$ head PKG-INFO 
Metadata-Version: 1.1
Name: gadjo
Version: 0.53.dev2+g690db4b
Summary: Django base template tailored for management interfaces
Home-page: https://dev.entrouvert.org/projects/gadjo/
Author: Frederic Peters
Author-email: fpeters@entrouvert.com
License: AGPLv3 or later
Description: =====
        Gadjo
jenkins@jenkins:/tmp/coin/gadjo-0.53.dev2+g690db4b$ head VERSION ; echo
0.53.dev2+g690db4b

Ack.

Envoyé, et derrière une correction parce qu'un s de trop à ressourcess...

authentic2.plugins.PluginError: ('unable to load entrypoint authentic2-idp-saml2 = authentic2.idp.saml:Plugin', VersionConflict(gadjo 0.53.dev4+g9c486af (/usr/lib/python2.7/dist-packages), Requirement.parse('gadjo>=0.53')))

Toujours pas, on a pourtant bien le + qui a été conservé.

J'ai enlevé le .dev4 à la main sur la machine et ça passe, peut-être qu'on ne peut pas les utiliser ensemble.

Rien à voir, c'est juste que 0.52.x < 0.53.dev4 < 0.53. Ce sont des numéros de pre-release.

Benjamin Dauvergne a écrit :

Rien à voir, c'est juste que 0.52.x < 0.53.dev4 < 0.53. Ce sont des numéros de pre-release.

Mais il y a .prexxx aussi je crois qui doit être > .devyyy

>>> version.parse('0.53.dev2+g690db4b') < version.parse('0.53')
True
>>> version.parse('0.53.pre2+g690db4b') < version.parse('0.53')
True

Mais,

>>> version.parse('0.53.post2+g690db4b') < version.parse('0.53')
False
>>> version.parse('0.53.2+g690db4b') < version.parse('0.53')
False

Préférence ?

Allez va pour post, ça préviendra le souci que j'ai déjà eu ou je me met à utiliser un troisième élément de version et je me fais avoir.

Benjamin Dauvergne a écrit :

Allez va pour post, ça préviendra le souci que j'ai déjà eu ou je me met à utiliser un troisième élément de version et je me fais avoir.

Après ça ne résoudra pas forcément grand chose dans la mesure où Debian a sa propre compréhension de tout ça, sur un ".post2" je ne sais foutre pas ce qu'il va faire.

Bon avec debian tout fonctionne (sauf certainement les .devxxx ou .prexxx):

(authentic) bdauvergne@revestel:~/wd/django/django$ dpkg --compare-versions 0.53.post2+g4534543 lt 0.53.post21+gjkjhkjh && echo ok
ok
(authentic) bdauvergne@revestel:~/wd/django/django$ dpkg --compare-versions 0.53.post2+g4534543 lt 0.53.post3+gjkjhkjh && echo ok
ok
(authentic) bdauvergne@revestel:~/wd/django/django$ dpkg --compare-versions 0.53.post2+g4534543 lt 0.53.post3+gjkjhkjh && echo ok
ok
(authentic) bdauvergne@revestel:~/wd/django/django$ dpkg --compare-versions 0.53.2+g4534543 lt 0.53.3+gjkjhkjh && echo ok
ok
(authentic) bdauvergne@revestel:~/wd/django/django$ dpkg --compare-versions 0.53 lt 0.53.post21+gjkjhkjh && echo ok
ok

(debian n'a pas d'interprétation particulière de dev ou pre ou n'importe quoi, compare juste d'un point de vue ascii ces éléments).

Je soulignais juste que si on utilisait des paquets Python en x.y.devz (un jour malencontreusement) on serait bien embêté le jour de la sortie du paquet x.y qui ne viendrait pas remplacer le paquet x.y.devz (vu que pour Debian le premier est supérieur au deuxième et l'inverse pour Python).

Donc n'utilisons jamais de versionning où un suffixe rend la version inférieure au préfixe.