<julm>
eeva: ah, j'ai trouvé lib.mkBefore en plus de lib.mkForce (suffisait de lire le manuel ^^) ; utile pour créer des dossiers (ex. de logs) dans systemd.services.nginx.preStart nécessaire pour nginx.conf. Comme le preStart n’expose pas configFile (nginx.conf) mais lance un check nginx dessus y avait pas moyen de s'en sortir simplement avec lib.mkForce sans recopier tout configFile.
<julm>
j'ai aussi réussi à intégrer les plugins de Redmine dans nixpkgs/pkgs/applications/version-management/redmine/, pas de manière reproductible par contre, pour cela il faudrait figer tous les résultats de bundle lock+bundix pour toutes les combinaisons de plugins ; ce qui doit faire qqchose comme 2^|plugins| gemset.nix à faire… du coup je lance le bundle lock+bundix dynamiquement et les dépendances
<julm>
obtenues dépendent de comment bundle lock résout les dépendances à ce lancement spécifique :\
<julm>
bon et puis je génère aussi un wrapper de bundle qui met le bon environnement dans /var/lib/redmine/bundle afin de pouvoir facilement gérer manuellement les opérations de maintenance ou de désinstallation des plugins
<julm>
hmm, j’utilise closePropagation pour résoudre les dépendances entre plugins, par contre c’est dans lib/deprecated.nix… mais ça dit pas quoi utiliser d’autre, une idée ?
<symphorien>
Un point fixe ? Ou juste rec { } ?
<julm>
en gros ça permet d’accumuler les propagatedBuildInputs et propagatedNativeBuildInputs d’une liste de dérivations
<julm>
autre problème de cette approche, je permets de configurer redmine_git_hosting avec un settingsYml, mais du coup changer settingsYml reconstruit la derivation du plugin, qui reconstruit la derivation de redmine qui utilise le système bundle lock+bundix pour générer le gemset.nix final, potentiellement non-reproductible
<julm>
j'ai copié l’approche par closePropagation depuis pkgs/applications/editors/eclipse/default.nix
<symphorien>
Hum en lisant le code de closePropagation ça n'a pas l'air problématique
<julm>
ça marche oui, mais je préfèrerais utiliser qqchose qui n'est pas déprécié
<julm>
pkgs/development/haskell-modules/hoogle.nix: # TODO: closePropagation is deprecated; replace
<symphorien>
Mais sinon dans mkPlugin un truc du genre: pluginsClosure = concatMap (x: x.pluginsClosure) deps
<symphorien>
+ deps
<julm>
humpf « closePropagation is like a manual way to collect all propagated build inputs, it's used a couple times through nixpkgs (shouldn't be in deprecated.nix) »
<symphorien>
Disons que dans ce cas particulier filtrer les plugins au fur et à mesure de la collecte réduit la taille de la liste
<symphorien>
Ce qui donne un avantage marginal à l'implémenter soi même peut-être
<julm>
en effet, après c'est pas une liste énorme
<julm>
le plus gros souci restant surtout cette histoire de bundle lock
<julm>
que je ne peux pas faire statiquement/manuellement
<julm>
comme pour tous les autres dérivations ruby que j'ai vues dans nixpkgs
<julm>
toutes*
<symphorien>
J'y connais rien, mais naïvement: faire un bundle lock avec tous les plugins du monde et filtrer après ?
<symphorien>
Je crois que node c'est comme ça
<eeva>
julm: trop bien! Merci pour l'info
<julm>
même si c'était possible techniquement, trop rien ne garantie que ça marche, que les plugins n'ont pas de dépendances contradictoires entre-elles
<julm>
eeva: :)
<symphorien>
Ah c'est vrai que nom peut avoir plusieurs versions d'une même bibliothèque simultanément
<symphorien>
s/nom/npm
<julm>
je ne connais pas bien ruby, j'ai trop rien croisé qui permettent d'élaguer un Gemfile.lock, ce serait donc plutôt au niveau du gemset.nix dérivé que faudrait agir, mais du coup je vois pas comment sans reparser le Gemfile générant initialement le Gemfile.lock ; bref too hard for me
<symphorien>
Comme nix est paresseux y'a probablement rien à faire
<symphorien>
Juste à ne pas évaluer les plugins inutiles dans gemset.nix
<julm>
je sais pas si ya d'autres situations dans nixpkgs comme ça ou la flexibilité demande de réduire les exigences de reproductibilité ?
<symphorien>
(Enfin je m'avance un peu)
<julm>
on verra bien les retours quand je ferai une pull-request
<symphorien>
Ahah j'ai essayé de faire une PR pour signer les modules noyau (avec une clef éphémère donc non reproductible) ça a été refusé d'emblée.
<julm>
pour le moment je veux finir de me battre avec la config du plugin redmine_git_hosting qui est un peu alambiqué avec ses usages de ssh et sudo
<julm>
bon, l'un des problèmes subtils était que fallait dire à redmine_git_hosting d’utiliser le sudo de /run/wrappers/bin/ qui a le SETUID et pas celui de pkgs.sudo
<julm>
security.wrapperDir
<julm>
et ne pas ajouter simplement security.wrapperDir dans systemd.services.redmine.path, parce que ça mettrait /run/wrappers/bin/{bin,sbin} /o\
<symphorien>
"${security.wrapperDir}/../" alors ?
<julm>
ouais
<julm>
par flemme pour l'instant du moins
<julm>
bon, me reste à patcher le "#!/usr/bin/env ruby" du ~git/local/hooks/common/post-receive installé par redmine_git_hosting, et espérer que ce soit pas un cauchemar en dépendances gemfile
<julm>
bonne soirée (ou journée selon votre geo:) ++