Passage au flocon

[CORAAL]

Bonjour,

Ce pull request apporte d'importantes modifications pour intégrer un flocon côté utilisateur.

• Intégration du flocon côté utilisateur :
  • Flocon ajouté à la configuration utilisateur (/etc/nixos/flake.nix) durant l'installation
• Réorganisation des configurations :
  • Les paramètres "Unfree" sont déplacés dans le flocon et plus dans le module glf (nix-cfg/glf/system.nix auparavant).
  • Le fond d'écran est fourni par le module GLF
  • Le dossier nix-cfg, dorénavant iso-cfg pour plus de clarté.
  • Le module glf a été déplacé dans un répertoire dédié et n'est plus copié dans les configurations utilisateur. C'est le flocon utilisateur qui se charge de le récupérer.

---

Points à finaliser avant fusion

Aliases et compatibilité

• Ajouter des alias pour :
  • Mettre à jour le flocon (uniquement)
  • Rebuild la configuration
  • Mettre à jour le flocon puis rebuild la configuration.
• Activer le support expérimental des flocons dans le shell (permet entre autres d'écrire des commandes moins verbeuses lors de l'utilisation des flocons).

Améliorations

- [ ] Mécanisme pour utiliser la branche stable/unstable en même temps Repoussé dans un futur pull request

• Fournir un espace prêt à l'emploi pour que l'utilisateur puisse ajouter ses personnalisations.
• Implémenter un mécanisme de mise à jour automatique du flocon + rebuild.
• Fournir un flake.lock durant l'installation au lieu d'en générer un pour assurer la reproductibilité de l'iso dans le temps.

Migration

- [ ] Fournir une solution pour migrer d'une installation non-flake à flake. Nous avons décidé en interne de passer par une réinstallation puisque nous sommes au stade de proto. Des notes seront laissés dans la documentation pour expliquer comment procéder à la mise à niveau.

Documentations

Note

Ces éléments sont liés à la pull request #104

• Dépannage utilisateur
• Guide pour écrire un module.
• Détails des options activées par le module.
• Détails à propos de la nouvelle arborescence
• Guide pour mettre à jour manuellement le flocon.
  - [ ] Passer un paquet stable à unstable Repoussé dans un futur pull request
• Documentation sur le calcul du "hash" des fonds d'écran (dev).

Tâches précédent la fusion

• Inclure les modifications des récents commits dans les modules (git ne reconnaît pas le déplacement des anciennes config dans les nouveaux modules, il faut les inclures manuellement)
• Pointer le flocon de mon fork vers ce dépôt.
• Nettoyer l'historique de la branche coraal_flakeInit.
• Relecture.

Note

• La fonctionnalité lié à l'utilisation de stable et unstable est repoussé pour un futur pull request.
  Je n'ai pas trouvé de moyen satisfaisant pour que le module GLF endosse toute la complexité et garantir que l'utilisateur final conserve un flocon simple.
  Je ne souhaite pas retarder l'avancement de ce pull request pour cette fonctionnalité non-essentiel actuellement.

[darkone-linux]

Beau boulot bravo !

Le flake semble faire référence à ton fork, je sais pas si c'est voulu.

Question : pourquoi ne pas organiser en véritables composants de type modules ? J'ai l'impression que ton remaniement s'en approche, mais ma remarque n'est peut-être pas pertinente.

[CORAAL]

Beau boulot bravo !

Le flake semble faire référence à ton fork, je sais pas si c'est voulu.

Question : pourquoi ne pas organiser en véritables composants de type modules ? J'ai l'impression que ton remaniement s'en approche, mais ma remarque n'est peut-être pas pertinente.

Merci beaucoup !

En effet, c'est volontaire (pour le lien vers mon fork), avant la fusion, il devra être modifié pour pointer sur le dépôt GLF-OS.
(En bref, c'est nécessaire de pointer sur mon fork pour que ça fonctionne tant que la fusion n'est pas au point).

Qu'est-ce que tu as en tête exactement pour les modules ?
J'ai réutilisé les options options et config, donc je ne comprends pas de quoi tu parles précisément. :p
(Probablement un problème de compétences de ma part :p )
J'ai repris ce que j'ai vu sur github pour d'autres projets.

Merci pour ton commentaire :p

[darkone-linux]

En effet, c'est volontaire (pour le lien vers mon fork), avant la fusion, il devra être modifié pour pointer sur le dépôt GLF-OS. (En bref, c'est nécessaire de pointer sur mon fork pour que ça fonctionne tant que la fusion n'est pas au point).

En effet, je comprends la démarche :)

Qu'est-ce que tu as en tête exactement pour les modules ? J'ai réutilisé les options options et config, donc je ne comprends pas de quoi tu parles précisément. :p (Probablement un problème de compétences de ma part :p ) J'ai repris ce que j'ai vu sur github pour d'autres projets.

Mea culpa, je retire ce que j'ai dit. Du coup ça sera nickel pour paramétrer la conf GLF en amont 👍

[darkone-linux]

Pour simplifier :

  options.glf.autoUpgrade.enable = lib.mkOption {
    description = "Enable GLF systems configurations auto-upgrade.";
    type = lib.types.bool;
    default = false;
  };

Pourrais-t-on faire ça ?

  options.glf.autoUpgrade.enable = lib.mkEnableOption "Enable GLF systems configurations auto-upgrade.";

Dans ce cas c'est certainement false par défaut, sauf si on y adjoint un lib.mkDefault true;. A tester ;)

Autre question que je me pose... on voit souvent ce dossier default (ou nixos) solo dans modules, à quoi ça peut servir ? Switcher sur un autre jeu de modules ou permettre un héritage ?

[CORAAL]

Pour simplifier :

  options.glf.autoUpgrade.enable = lib.mkOption {
    description = "Enable GLF systems configurations auto-upgrade.";
    type = lib.types.bool;
    default = false;
  };

Pourrais-t-on faire ça ?

  options.glf.autoUpgrade.enable = lib.mkEnableOption "Enable GLF systems configurations auto-upgrade.";

Dans ce cas c'est certainement false par défaut, sauf si on y adjoint un lib.mkDefault true;. A tester ;)

Autre question que je me pose... on voit souvent ce dossier default (ou nixos) solo dans modules, à quoi ça peut servir ? Switcher sur un autre jeu de modules ou permettre un héritage ?

Pour le coup (si je comprends bien le principe derrière ta suggestion), je ne suis pas d'accord avec cette modification.

Que ce soit pour le développeur/mainteneur qui rejoint le projet ou l'utilisateur curieux, je pense qu'il est plus sage d'avoir des modules un peu plus verbeux qui indiquent clairement ce qu'ils font (valeur par défaut, type de variable attendu) plutôt que de faire l'hypothèse d'un "false" par défaut.
Comme nous nous adressons à des utilisateurs débutant / bidouilleur curieux, avoir une structure de module commune et "standard" et un peu verbeuse me semble être la bonne approche :p

Concernant ta deuxième question, si tu fais référence à l'option dans le flocon nixosModules.default il me semble (je ne suis pas sûr de moi) que c'est une simple chaine de caractères permettant de nommer le module.

Nous aurions pu le nommer différemment de "default", "laptop" par exemple et proposer des options propre aux laptop.

Autre exemple, peut-être qu'à l'avenir, nous aurons :

...

{

  nixosModules = {
    default = import ./modules/default
    laptop  = import ./modules/laptop
    gaming = import ./modules/gaming
    kde       = import ./modules/kde
  };

}

...

Par défaut, nous activons par défaut default et si l'utilisateur souhaite modifier autre chose, il active laptop ou un autre module.

C'est la représentation que j'en ai actuellement, peut-être que je me trompe :)

[darkone-linux]

Pour le coup (si je comprends bien le principe derrière ta suggestion), je ne suis pas d'accord avec cette modification.

Que ce soit pour le développeur/mainteneur qui rejoint le projet ou l'utilisateur curieux, je pense qu'il est plus sage d'avoir des modules un peu plus verbeux qui indiquent clairement ce qu'ils font (valeur par défaut, type de variable attendu) plutôt que de faire l'hypothèse d'un "false" par défaut. Comme nous nous adressons à des utilisateurs débutant / bidouilleur curieux, avoir une structure de module commune et "standard" et un peu verbeuse me semble être la bonne approche :p

Je comprends ;).

Avoir des modules par défaut à false permettrait cependant, sauf erreur, de pouvoir utiliser la conf glf-os dans ma conf NixOS en activant moi-même ce que je veux, même si je conviens que ce n'est pas l'objectif premier.

Concernant ta deuxième question, si tu fais référence à l'option dans le flocon nixosModules.default il me semble (je ne suis pas sûr de moi) que c'est une simple chaine de caractères permettant de nommer le module.
(...)
Par défaut, nous activons par défaut default et si l'utilisateur souhaite modifier autre chose, il active laptop ou un autre module.

C'est la représentation que j'en ai actuellement, peut-être que je me trompe :)

J'ai l'impression en étudiant les confs des uns et des autres que chacun fait un peu comme il le souhaite. J'avoue que je ne maîtrise pas encore la subtilité. Merci pour ton explication ;)

[CORAAL]

Pour le coup (si je comprends bien le principe derrière ta suggestion), je ne suis pas d'accord avec cette modification.
Que ce soit pour le développeur/mainteneur qui rejoint le projet ou l'utilisateur curieux, je pense qu'il est plus sage d'avoir des modules un peu plus verbeux qui indiquent clairement ce qu'ils font (valeur par défaut, type de variable attendu) plutôt que de faire l'hypothèse d'un "false" par défaut. Comme nous nous adressons à des utilisateurs débutant / bidouilleur curieux, avoir une structure de module commune et "standard" et un peu verbeuse me semble être la bonne approche :p

Je comprends ;).

Avoir des modules par défaut à false permettrait cependant, sauf erreur, de pouvoir utiliser la conf glf-os dans ma conf NixOS en activant moi-même ce que je veux, même si je conviens que ce n'est pas l'objectif premier.

Concernant ta deuxième question, si tu fais référence à l'option dans le flocon nixosModules.default il me semble (je ne suis pas sûr de moi) que c'est une simple chaine de caractères permettant de nommer le module.
(...)
Par défaut, nous activons par défaut default et si l'utilisateur souhaite modifier autre chose, il active laptop ou un autre module.
C'est la représentation que j'en ai actuellement, peut-être que je me trompe :)

J'ai l'impression en étudiant les confs des uns et des autres que chacun fait un peu comme il le souhaite. J'avoue que je ne maîtrise pas encore la subtilité. Merci pour ton explication ;)

Ok, je comprends un peu mieux ton idée, (je ne suis pas bien réveillé) au lieu de proposer des options actives par défaut, tu veux proposer des options à false par défaut et laisser l'utilisateur les activer à la demande ?

Si oui, c'est parfaitement possible, je pense que ça pourrait être le sujet d'un pull request futur.

[gponcon]

Pourquoi ne fais-tu pas des amends pour éviter de multiplier les commits ?

[CORAAL]

Pourquoi ne fais-tu pas des amends pour éviter de multiplier les commits ?

Pas de raison spécifique, de toute manière, la branche sera nettoyée plus tard

[gponcon]

Pourquoi ne fais-tu pas des amends pour éviter de multiplier les commits ?

Pas de raison spécifique, de toute manière, la branche sera nettoyée plus tard

Dac. C juste que ça me fait une notif a chaque fois ;)

[CORAAL]

Pourquoi ne fais-tu pas des amends pour éviter de multiplier les commits ?

Pas de raison spécifique, de toute manière, la branche sera nettoyée plus tard

Dac. C juste que ça me fait une notif a chaque fois ;)

My bad :p

[CORAAL]

La structure du flocon principal a été revu (déplacer des éléments), la montée de version de Nix (2.24.11) a introduit des changements qui cassaient nos modifications pour calamares.