• [^] # Re: Developers: Let distros do their job

    Posté par (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 2.

    Cependant, pour des paquets qui embarquent du code natif

    Oof, tu piques la où ça fait mal ! C'est pas très fair play :p

    J'essayais juste de trouver pour quelle raison on pouvait préférer le gestionnaire de paquets de l'OS plutôt que le dédié :-).

    Je viens juste de comprendre le fonctionnement des wheels. En fait, ça fonctionne de manière similaire avec NPM, sauf qu'il faut les traiter manuellement.
    Concrètement, on a une section, dans le package.json, qui ressemble à ça :

    "binary": {
 "module_name": "xppqnjs",
 "module_path": "./",
 "remote_path": "./epeios-q37/xppq-node/releases/download/v20171225/",
 "package_name": "{module_name}-v20171225-{platform}-{arch}.tar.gz",
 "host": "https://github.com"
},

    Ça permet à NPM de construire l'URL où récupérer le code natif pour la plateforme ciblée (noter le {platform}-{arch} pour l'entrée package_name, dont on trouve l'équivalent dans le nommage des wheels de PyPI), à charge pour l'empaqueteur d'y placer le fichier adéquat.
    En fait, c'est node-[pre-]gyp qui s'occupe de la récupération, et on peut lui indiquer de lancer la compilation s'il ne trouve pas le fichier attendu. Ce qui, le cas échéant, ne peut évidemment fonctionner que si le compilateur adéquat et présent...

    Ceci (削除) dit (削除ここまで) écrit, même si les binaires sont disponibles sur PyPI à travers les wheels, c'est quand même à l'empaqueteur de les générer, ou bien ?

    Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans (削除) C:\Program Files (削除ここまで)/opt. C'est juste plus simple.

    Mais ça c'est pour des logiciels complets, où est-ce que c'est aussi utilisable pour des bibliothèques ?

    Zelbinium: pour la génération qui crée, pas celle qui scrolle...