C’est précisément pour cela que ce sujet est l’endroit où nous devons être dirigés. Le message original comprend une liste qui semble être mise à jour assez fréquemment. Si vous regardez l’historique des modifications, vous pouvez savoir quels plugins ont été ajoutés et quand.
Nous avons terminé pour l’instant ! le dernier restant est le jour d’anniversaire et il sera terminé dans quelques mois.
Je suis tombé sur cela il y a peu. J’ai commencé à explorer le développement de Discourse, donc je voulais m’entraîner à mon flux de mise à jour :
# git pull
# bundle install
# pnpm install
# ./bin/rails db:migrate
Mais je suppose que le plugin Discourse AI nécessite le plugin Pgvector pour PostgreSQL (dont je ne savais pas qu’il existait auparavant) :
== 20230710171141 EnablePgVectorExtension: migrating ==========================
-- enable_extension(:vector)
bin/rails aborted!
StandardError: Une erreur s'est produite, cette migration et toutes les suivantes ont été annulées : (StandardError)
ERROR: current transaction is aborted, commands ignored until end of transaction block
/home/john/development/discourse/lib/mini_sql_multisite_connection.rb:109:in 'MiniSqlMultisiteConnection#run'
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:8:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Caused by:
PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block (PG::InFailedSqlTransaction)
/home/john/development/discourse/lib/mini_sql_multisite_connection.rb:109:in 'MiniSqlMultisiteConnection#run'
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:8:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Caused by:
ActiveRecord::StatementInvalid: PG::FeatureNotSupported: ERROR: extension \"vector\" is not available (ActiveRecord::StatementInvalid)
DETAIL: Could not open extension control file \"/usr/share/postgresql/extension/vector.control\": No such file or directory.
HINT: The extension must first be installed on the system where PostgreSQL is running.
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:6:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Caused by:
PG::FeatureNotSupported: ERROR: extension \"vector\" is not available (PG::FeatureNotSupported)
DETAIL: Could not open extension control file \"/usr/share/postgresql/extension/vector.control\": No such file or directory.
HINT: The extension must first be installed on the system where PostgreSQL is running.
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:6:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Tasks: TOP => db:migrate
Je peux l’installer, mais je me demande s’il existe un moyen de désactiver des plugins à ce niveau afin que leurs migrations soient simplement ignorées. (Je préférerais ne pas installer de logiciels supplémentaires, en particulier pour un « plugin » que je n’ai pas l’intention d’explorer pour le développement.)
J’ai également rencontré ceci plus tôt aujourd’hui. J’ai installé le package via sudo, après quelques conseils de ChatGPT. Je me demande aussi ceci ; je me demande - peut-être que supprimer le dossier du plugin du répertoire /plugins aidera
… mais git pull plus tard pourrait le réinstaller.
Je suis opposé à ce changement. Normalement, dans le développement logiciel, avoir un cœur allégé signifie que la distribution principale peut être plus petite, plus rapide et avoir une surface d’attaque réduite. Ma dernière incursion dans les plugins m’a montré qu’il est techniquement possible pour le code des plugins de s’exécuter même lorsqu’il est « désactivé », car cela semblait dépendre de l’auteur du plugin de vérifier, donc cela semble augmenter considérablement le risque et le volume.
Le problème le plus immédiat est qu’aucune instruction ne semble avoir été mise à jour dans le guide d’installation (peut-être les ai-je simplement manquées ?). Il n’est pas clair ce que nous devons installer pour que les choses fonctionnent à nouveau. J’ai résolu certaines erreurs en installant le paquet Ubuntu postgresql-16-pgvector, mais j’ai toujours eu des erreurs vectorielles lors de l’exécution de db:migrate. J’ai pu les contourner en supprimant localement le plugin d’IA.
Quoi qu’il en soit, c’est beaucoup de code supplémentaire, bon nombre de ces plugins sont complètement sans rapport avec les cas d’utilisation de la plupart des communautés Discourse. (Cela ne veut pas dire que ce sont de mauvais plugins ! Je suis sûr qu’ils sont très utiles aux communautés qui en ont besoin. C’est juste que j’ai du mal à voir que chaque forum communautaire a besoin d’être livré avec une intégration Zendesk, etc.). Le plugin d’IA en particulier, compte tenu de ses exigences supplémentaires qui causent des problèmes, devrait certainement être écarté selon moi.
Sur le plan personnel, lorsque je me connecte à mon panneau d’administration et que je vois soudainement une série de plugins publicitaires, même si le code devrait être inerte, cela me préoccupe énormément. Je tiens à exprimer, dans les termes les plus forts possibles, que je NE VEUX AUCUN plugin publicitaire de grandes entreprises technologiques sur mes installations par défaut, même désactivé. C’est une industrie qui a historiquement été incroyablement abusive envers la vie privée des utilisateurs, et Discourse ne s’aide pas en livrant de telles intégrations par défaut. Les personnes qui veulent des publicités n’auraient aucune difficulté à trouver le plugin requis, il n’est pas nécessaire de l’inclure dans toutes les installations.
TLDR : Veuillez reconsidérer ce changement. ![]()
Discourse intègre des plugins au cœur du système, qui sont toujours proposés dans ses hébergements officiels.
Je suis d’accord que cela ajoute du volume supplémentaire à l’interface d’administration, avec de nombreuses marques qui comptent comme de la publicité pour mon cerveau. Ce n’est pas cool. En tant que défenseur du logiciel libre essayant de faire de mon mieux pour éviter les grandes marques, je considère que cela fait un pas que Ubuntu a fait il y a quelques années avant d’être entièrement colonisé par Armazon, Gaggle et consorts. Si vous les laissez venir à vos yeux, ils finiront par les avaler.
Regrouper les plugins dans le cœur offre également aux développeurs l’opportunité de transformer par erreur une fonctionnalité de plugin en une exigence au fil du temps, tandis que les maintenir en tant que plugins garantit que ce type d’erreur ne peut pas être commis.
L’équipe peut-elle clarifier la raison de ce changement ?
S’il s’agit d’accélérer les installations sur l’infrastructure Discourse, peut-être qu’un paquet discourse-hosting-bundle créé automatiquement sur CI pourrait obtenir le même résultat ?
@david, pouvez-vous s’il vous plaît maintenir l’ordre alphabétique dans la liste des plugins affectés ?
La motivation ici est de fournir une expérience plus fluide aux nouveaux utilisateurs de Discourse, afin qu’ils bénéficient d’une expérience Discourse plus « complète » dès le départ.
Une autre motivation est l’expérience des développeurs pour notre équipe et pour les contributeurs de la communauté. En regroupant tous ces plugins avec le cœur, il n’est plus nécessaire de tenir compte de la compatibilité avec différentes versions du cœur. C’est particulièrement utile pour des plugins comme discourse-ai qui sont en cours de développement très intense, en parallèle avec les changements connexes du cœur.
Les plugins d’authentification de marque sont ceux qui sont les plus susceptibles d’être intégrés au cœur, tout comme nos méthodes d’authentification existantes comme Google/Facebook/etc. Il y a donc de fortes chances qu’ils soient supprimés de la liste dans un avenir pas trop lointain.
Ce changement n’est pas lié aux performances de notre hébergement. Nous avions déjà une distribution pré-construite avec tous ces plugins, et plus encore, comme vous le décrivez. ![]()
J’ai corrigé l’ordre ![]()
Cela a déjà été répondu dans le message initial :
Quelques exemples :
- nous n’avons pas à nous soucier de la gestion des versions si nous ajoutons quelque chose au cœur pour un plugin, nous savons que les deux sont à la même version
- il est plus facile de tester un plugin dépendant d’un autre plugin si le code est présent pour les deux
- lorsque nous modifions quelque chose dans le cœur, nous devons souvent faire plusieurs PR juste pour corriger les spécifications dans les plugins, maintenant cela signifie une seule PR autonome
Le résultat final est que l’équipe Discourse dispose de plus de temps pour améliorer et maintenir le produit au lieu de traiter ce genre de problèmes, donc, finalement, vous gagnez aussi.
J’aimerais beaucoup que ces éléments disparaissent de mon interface utilisateur, mais ils n’occupent que de l’espace, car ils ne sont ni facultatifs ni cachés : ils font partie du cœur. C’est précisément ce qui nous inquiète.
En ce qui concerne l’expérience utilisateur lors de la première utilisation, peut-être que changer le modèle de conteneur pour inclure et documenter le bundle officiel fonctionnerait :
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
# Le plugin docker_manager est obligatoire pour les mises à jour automatisées basées sur le web
- git clone https://github.com/discourse/docker_manager.git
# Les plugins suivants sont installés sur toutes les instances hébergées par Discourse.
# Décommentez la ligne en supprimant `#` avant la ligne `- git clone` pour les activer.
# Voir https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/
# Plugin de publicité Discourse (Ads) : https://meta.discourse.org/t/discourse-advertising-plugin-ads/33734
#- git clone https://github.com/discourse/discourse-adplugin
# Affiliate Discourse
#- git clone https://github.com/discourse/discourse-affiliate
# ...
# ...
# Veuillez ajouter d'autres plugins ci-dessous. Pour une liste des plugins officiels, voir :
# https://meta.discourse.org/tag/official
# Pour tous les plugins disponibles, voir :
# https://meta.discourse.org/c/plugin/22
En ce qui concerne l’expérience développeur, vous pouvez certainement automatiser la transmission des versions des plugins d’une autre manière moins intrusive. Par exemple, en utilisant une règle pups pour décommenter les plugins en utilisant la stratégie de documentation ci-dessus.
Vous pourriez même avoir un modèle de conteneur qui le fait pour vous :
templates:
- "templates/discourse.hosting.yml"
- "templates/discourse.core-bundle.yml"
Notez que ma première impression était bonne : j’ai pu découvrir quelques plugins intéressants qui n’étaient pas encore sur mon radar. Mais oui, comme je vous ai vu optimiser et chercher le dénominateur commun le plus petit au cours de la dernière décennie, je suis surpris que ce soit ainsi que vous gériez une telle proposition.
Je pense que vous pouvez ajouter un rm - rf discourse-ai là où se trouvent habituellement les commandes git clone. Je ne l’ai pas fait moi-même.
Oui, techniquement, vous pouvez supprimer tous les dossiers du répertoire des plugins et le cœur de Discourse fonctionnera toujours.
Il est fort probable que ces plugins développés par l’équipe de Discourse respectent les règles et ajoutent une surcharge minimale. Les avoir tous activés permet de constater plus facilement qu’ils fonctionnent tous ensemble et partagent les mêmes exigences.
Utilisez-vous une instance externe de postgres plutôt que celle incluse ? Utilisez-vous une configuration à deux conteneurs qui n’a pas été mise à jour depuis longtemps ?
Vous pouvez vous débrouiller pour les supprimer, mais ils ne peuvent rien faire à moins que vous ne créiez un compte auprès des entreprises maléfiques et que vous obteniez des clés pour permettre le suivi.
Merci pour votre réponse,
Espérons-le, mais c’est une surface d’attaque et de bugs supplémentaire, en échange d’aucun bénéfice pour les communautés qui n’utilisent pas ces plugins (ce qui sera le cas de la plupart des communautés).
Je pense que Discourse a identifié un vrai problème ici, mais a trouvé la mauvaise solution.
Je suis tout à fait d’accord sur le fait qu’il existe un réel problème fondamental de fragilité de l’écosystème de développement/plugins pour Discourse. Il est certainement difficile de développer contre une cible mouvante, et les changements d’API dans le cœur du système rendent cela difficile. Dans une certaine mesure, cela fait partie du développement contre une technologie de pointe, mais c’est précisément pour cela que ce ne devrait pas être le comportement par défaut. Avoir seulement quelques plugins simples me permet de comprendre et d’empathiser avec votre problème (qui est beaucoup plus vaste que le mien).
Cependant, ce que Discourse fait ici, c’est simplement repousser le problème. Cela résout peut-être le problème pour Discourse, mais cela ne le résout pas pour les autres développeurs de plugins. Tous les autres rencontrent la même difficulté, mais à plus petite échelle.
Une meilleure solution serait d’avoir une série LTS (support à long terme) plus robuste contre laquelle on pourrait développer. Je sais que cela a été discuté ailleurs, donc je ne vais pas le répéter, mais l’un des plus grands défis pour les communautés, les développeurs de plugins et même les employés de Discourse semble être l’absence de LTS. La branche stable est activement déconseillée. Si un pipeline de développement plus traditionnel était utilisé, il serait beaucoup plus facile pour le développement de plugins. Nous aurions des moments connus où les choses casseraient (mises à niveau majeures), et nous pourrions nous y préparer. Sinon, nous pourrions être sûrs que les petites mises à niveau ne casseront pas aléatoirement nos forums. (C’est probablement l’un des plus grands soucis de Discourse selon moi, et l’un que j’ai vu surgir ailleurs lorsque les gens discutent d’options de forum. La volatilité est un réel inconvénient.)
Oui – Selon le lien, j’ai rencontré ce problème dans un environnement de développement qui ne serait pas basé sur des conteneurs. (Je n’ai pas encore essayé cela dans des conteneurs de production)
Je pense que c’est l’une des choses qui m’inquiète, c’est si le chemin “standard” suppose que ces plugins existent, alors je pourrais rencontrer des bugs parce que tout le monde accepte les plugins publicitaires. Je dois soit risquer des bugs inattendus, soit gérer une charge de plugins supplémentaire. Mon objectif est d’avoir autant de stabilité que possible pour mes déploiements.
Il convient également de souligner que même le cœur de Discourse est assez lourd en termes d’utilisation des ressources par rapport à d’autres forums. Je pense qu’il est utile d’essayer de maintenir le cœur léger afin de ne pas exacerber davantage les problèmes de performance.
Je ne les ai pas encore audités pour m’assurer qu’ils n’intègrent pas de JavaScript de suivi/téléphonie lorsqu’ils sont désactivés, mais jusqu’alors, je suppose que vous avez raison. J’espère que quelqu’un vérifiera cela, car ce sera une énorme débâcle si cela s’avère faux.
Je pense que le point de Hellekin sur le désordre est valable, et je pense aussi que ce qu’ils veulent dire avec le plugin de publicité des grandes entreprises ne sera pas bien reçu par certains dans la communauté open source – le type qui est plus susceptible d’utiliser des forums open source en premier lieu.
Quoi qu’il en soit, j’aimerais aussi dire que j’apprécie que vous preniez en compte mes commentaires, même si ce n’est pas facile ![]()
Je pense qu’il est difficile de savoir lesquelles ont été relues auparavant et lesquelles ne l’ont pas été.
Je me suis brièvement demandé si vous aviez vérifié au préalable s’il y avait des commentaires ouverts qui sont maintenant manquants, puisque seuls les textes ont été ajoutés et non toutes les données de Crowdin. Mais je suppose que je ne veux même pas connaître la réponse à cette question. En fin de compte, cela ne fait aucune différence que personne ne réponde pendant des mois ou que les questions et les commentaires des traducteurs aient simplement disparu.
Existe-t-il des tests pour l’absence d’effets secondaires lors de la suppression des répertoires de plugins avec le nouveau bundle, afin de garantir qu’un plugin ne devienne pas une exigence par inadvertance ?
Notre suite de tests principale s’exécute sans aucun plugin chargé, donc oui, toute dépendance du cœur vers les plugins devrait être détectée par CI.
J’ai commenté les lignes pour cloner les plugins mais lorsque je relance « launcher rebuild app », j’obtiens les mêmes messages :
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' a échoué avec le retour #<Process::Status: pid 546 exit 1>
Emplacement de l'échec : /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'
exec a échoué avec les paramètres {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap a échoué avec le code de sortie 1
---
INDICE : Le plugin 'discourse-reactions' est maintenant inclus dans Discourse et ne doit pas être inclus dans la configuration de votre conteneur.
Supprimez la ligne 'git clone https://github.com/discourse/discourse-reactions' de votre fichier containers/app.yml, puis réessayez.
Pour plus d'informations, voir https://meta.discourse.org/t/373574
---
---
INDICE : Le plugin 'discourse-data-explorer' est maintenant inclus dans Discourse et ne doit pas être inclus dans la configuration de votre conteneur.
Supprimez la ligne 'git clone https://github.com/discourse/discourse-data-explorer' de votre fichier containers/app.yml, puis réessayez.
Pour plus d'informations, voir https://meta.discourse.org/t/373574
---
---
INDICE : Le plugin 'discourse-solved' est maintenant inclus dans Discourse et ne doit pas être inclus dans la configuration de votre conteneur.
Supprimez la ligne 'git clone https://github.com/discourse/discourse-solved' de votre fichier containers/app.yml, puis réessayez.
Pour plus d'informations, voir https://meta.discourse.org/t/373574
---
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
La raison de l’échec se trouve au-dessus de la ligne FAILED.