È proprio per questo che questo argomento è dove dobbiamo essere indirizzati. Il post originale include un elenco che sembra essere aggiornato abbastanza frequentemente. Se guardi la cronologia delle modifiche, puoi dire quali plugin sono stati aggiunti e quando.
3 Mi Piace
Abbiamo finito per ora! l’ultimo rimasto è il compleanno e sarà fatto tra qualche mese.
6 Mi Piace
Mi sono inciampato e sono caduto poco fa. Ho iniziato a provare a fare un po’ di sviluppo di Discourse, quindi volevo esercitare il mio flusso di lavoro di aggiornamento:
# git pull
# bundle install
# pnpm install
# ./bin/rails db:migrate
Ma la mia ipotesi è che il plugin Discourse AI richieda il plugin Pgvector per PostgreSQL (cosa che non sapevo esistesse in precedenza):
== 20230710171141 EnablePgVectorExtension: migrating ==========================
-- enable_extension(:vector)
bin/rails aborted!
StandardError: Si è verificato un errore, questa e tutte le migrazioni successive sono state annullate: (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
Posso installarlo, ma sono curioso se c’è un modo per disabilitare i plugin a questo livello in modo che le loro migrazioni vengano semplicemente saltate. (Preferirei non installare software aggiuntivo, in particolare per un “plugin” che non sono interessato a esplorare per lo sviluppo.)
4 Mi Piace
L’ho riscontrato anche io in precedenza. Ho installato il pacchetto tramite sudo, dopo l’aiuto di ChatGPT. Mi stavo anche chiedendo questo; mi chiedo - forse eliminare la cartella del plugin dalla directory /plugins potrebbe aiutare 
… ma un git pull successivo potrebbe reinstallarlo.
2 Mi Piace
Mi oppongo a questo cambiamento. Normalmente nello sviluppo software, avere un nucleo snello significa che la distribuzione principale può essere più piccola, più veloce e con una minore superficie di attacco. La mia ultima incursione nei plugin mi ha portato a vedere che è tecnicamente possibile che il codice dei plugin venga eseguito anche quando è “disabilitato”, poiché sembrava dipendere dall’autore del plugin verificarlo, quindi sembra che questo aumenti significativamente il rischio e il bloat.
Il problema più immediato è che nessuna istruzione sembra essere aggiornata sulla guida all’installazione (forse le ho solo perse?). Non è chiaro cosa dobbiamo installare per far funzionare di nuovo le cose. Ho risolto alcuni errori installando il pacchetto Ubuntu postgresql-16-pgvector, ma ho ancora avuto alcuni errori relativi ai vettori durante l’esecuzione di db:migrate. Sono stato in grado di aggirarli eliminando localmente il plugin AI.
Comunque, questo è un sacco di codice aggiuntivo, molti di questi plugin sono completamente irrilevanti per i casi d’uso della maggior parte delle community di Discourse. (Ciò non significa che questi siano plugin cattivi! Sono sicuro che sono molto utili per le community che ne hanno bisogno. Semplicemente fatico a vedere che ogni forum della community debba essere distribuito con l’integrazione Zendesk, ecc.). Il plugin AI in particolare, dati i suoi requisiti aggiuntivi che stanno rompendo le cose, dovrebbe decisamente essere eliminato secondo me.
A livello personale, quando accedo al mio pannello di amministrazione e vedo improvvisamente una serie di plugin pubblicitari, anche se il codice dovrebbe essere inerte, mi preoccupa enormemente. Desidero esprimere nei termini più forti possibili che NON voglio alcun plugin pubblicitario di grandi aziende tecnologiche nelle mie installazioni per impostazione predefinita, nemmeno disabilitati. Quello è un settore che storicamente è stato incredibilmente abusivo nei confronti della privacy degli utenti e Discourse non si aiuta spedendo tali integrazioni per impostazione predefinita. Le persone che desiderano pubblicità non avrebbero difficoltà a trovare il plugin necessario, non è necessario includerlo in tutte le installazioni.
TLDR: Si prega di riconsiderare questo cambiamento. 
5 Mi Piace
Discourse sta integrando plugin nel core che sono sempre offerti nei loro hosting ufficiali
2 Mi Piace
Concordo sul fatto che ciò comporti un ulteriore bloat nell’interfaccia di amministrazione, con molti nomi di marchi che contano come pubblicità per il mio cervello. Questo non è bello. Come sostenitore del software libero che cerca di evitare i grandi marchi, considero che faccia un passo che Ubuntu ha fatto alcuni anni fa prima di essere interamente colonizzato da Armazon, Gaggle e consimili. Se lasci che questi entrino nei tuoi occhi, finiranno per inghiottirli.
Includere i plugin nel core offre anche agli sviluppatori l’opportunità di trasformare erroneamente la funzionalità di un plugin in un requisito nel tempo, mentre mantenerli come plugin garantisce che tale errore non possa essere commesso.
Il @team può chiarire la logica alla base di questa modifica?
Se si tratta di velocizzare le installazioni sull’infrastruttura di Discourse, forse la creazione di un pacchetto discourse-hosting-bundle creato automaticamente su CI potrebbe ottenere lo stesso risultato?
4 Mi Piace
@david, puoi per favore mantenere l’ordine alfabetico nell’elenco dei plugin interessati?
La motivazione qui è fornire un’esperienza più fluida ai nuovi utenti di Discourse, in modo che ottengano un’esperienza Discourse più “completa” fin da subito.
Un’altra motivazione è l’esperienza di sviluppo per il nostro team e per i contributori della community. Avendo tutti questi plugin inclusi nel core, non è più necessario considerare la compatibilità con diverse versioni del core. Ciò è particolarmente utile per plugin come discourse-ai che sono in fase di sviluppo molto intenso in questo momento, in parallelo con le modifiche correlate al core.
I plugin di autenticazione di marca sono quelli che hanno maggiori probabilità di essere assorbiti nel core, proprio come i nostri attuali metodi di autenticazione core come Google/Facebook/ecc. Quindi c’è una buona probabilità che vengano rimossi dall’elenco in un futuro non troppo lontano.
Questa modifica non riguarda le prestazioni sul nostro hosting. Avevamo già una distribuzione precompilata con tutti questi plugin, e altri ancora, come descrivi. 
Ho corretto l’ordinamento 
7 Mi Piace
È già stato risposto nell’OP:
Alcuni esempi di questo:
- non dobbiamo preoccuparci del versioning se aggiungiamo qualcosa nel core per un plugin, sappiamo che entrambi sono alla stessa versione
- più facile testare un plugin che dipende da un altro plugin se il codice è presente per entrambi
- quando cambiamo qualcosa nel core, spesso dobbiamo fare più PR solo per correggere le specifiche nei plugin, ora significa solo un PR autonomo
Il risultato finale è più tempo disponibile per il team di Discourse per migliorare e mantenere il prodotto invece di occuparsi di questo tipo di problemi, quindi, alla fine, vinci anche tu.
12 Mi Piace
Mi piacerebbe molto che scomparissero dalla mia interfaccia utente, ma stanno solo occupando spazio, perché non sono opzionali né nascosti: fanno parte del core. È esattamente questo il motivo per cui siamo preoccupati.
Per quanto riguarda l’esperienza utente per la prima volta, forse cambiare il modello del contenitore per includere e documentare il bundle ufficiale potrebbe funzionare:
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
# Il plugin docker_manager è obbligatorio per gli aggiornamenti automatici basati sul web
- git clone https://github.com/discourse/docker_manager.git
# I seguenti plugin sono installati su tutte le istanze ospitate da Discourse.
# Decommenta la riga rimuovendo `#` prima della riga `- git clone` per abilitarla.
# Vedi https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/
# Plugin di pubblicità di Discourse (Ads): https://meta.discourse.org/t/discourse-advertising-plugin-ads/33734
#- git clone https://github.com/discourse/discourse-adplugin
# Affiliate di Discourse
#- git clone https://github.com/discourse/discourse-affiliate
# ...
# ...
# Si prega di aggiungere altri plugin di seguito. Per un elenco di plugin ufficiali, vedere:
# https://meta.discourse.org/tag/official
# Per tutti i plugin disponibili, vedere:
# https://meta.discourse.org/c/plugin/22
Per quanto riguarda l’esperienza dello sviluppatore, sicuramente è possibile automatizzare il passaggio delle versioni dei plugin in un altro modo meno invasivo. Ad esempio, utilizzando una regola pups per decommentare i plugin utilizzando la strategia di documentazione sopra indicata.
Si potrebbe persino avere un modello di contenitore che lo faccia per te:
templates:
- "templates/discourse.hosting.yml"
- "templates/discourse.core-bundle.yml"
Nota che la mia prima impressione è stata buona: ho potuto scoprire un paio di plugin interessanti che non avevo ancora sotto osservazione. Ma sì, dato che ti ho visto ottimizzare e cercare il minimo comune denominatore nell’ultimo decennio, sono sorpreso che questo sia il modo in cui gestisci una tale proposta.
4 Mi Piace
Credo che tu possa aggiungere un rm - rf discourse-ai dove di solito si trovano i comandi git clone. Non l’ho fatto personalmente.
4 Mi Piace
Sì, tecnicamente puoi rimuovere tutte le cartelle nella directory dei plugin e il core di Discourse continuerà a funzionare
5 Mi Piace
È una buona scommessa che questi plugin sviluppati dal team di discourse seguano le regole e aggiungano un overhead minimo. Averli tutti attivi rende più facile vedere che funzionano tutti insieme e condividono gli stessi requisiti.
Stai eseguendo un postgres esterno anziché quello incluso? Stai eseguendo una configurazione a due container che non viene aggiornata da molto tempo?
Puoi sforzarti di rimuoverli, ma non possono fare nulla a meno che tu non crei un account con le aziende malvagie e ottenga le chiavi per consentire l’inizio del tracciamento.
5 Mi Piace
Grazie per la tua risposta,
Speriamo di sì, ma è una superficie aggiuntiva per bug e attacchi, in cambio di alcun beneficio per le community che non utilizzano questi plugin (che saranno la maggior parte delle community).
Ritengo che Discourse abbia identificato un problema reale qui, ma abbia trovato la soluzione sbagliata.
Sono assolutamente d’accordo sul fatto che esista un problema di fondo reale riguardo alla fragilità dell’ecosistema di sviluppo/plugin per Discourse. È decisamente difficile sviluppare contro un bersaglio in movimento, e le modifiche all’API nel core certamente lo rendono difficile. In una certa misura, questo fa parte dello sviluppo contro l’avanguardia upstream, ma è esattamente per questo che non dovrebbe essere il comportamento predefinito. Avendo solo un paio di plugin semplici, posso capire e immedesimarmi nel tuo problema (che è di gran lunga più ampio del mio).
Tuttavia, ciò che Discourse sta facendo qui è solo rimandare il problema. Potrebbe risolvere il problema per Discourse, ma non lo risolve per il resto degli sviluppatori di plugin. Tutti gli altri stanno affrontando lo stesso problema, solo su scala ridotta.
Una soluzione migliore sarebbe avere una serie LTS (Long-Term Support) più robusta su cui sviluppare. So che questo è stato discusso altrove, quindi non mi ripeterò, ma una delle maggiori sfide per le community, gli sviluppatori di plugin e persino i dipendenti di Discourse sembra essere l’assenza di un LTS. La branch stabile è attivamente sconsigliata. Se venisse utilizzato un pipeline di sviluppo più tradizionale, sarebbe molto più facile per lo sviluppo dei plugin. Potremmo avere tempi noti in cui le cose si romperanno (aggiornamenti di versione principali) e pianificare di conseguenza. Altrimenti, possiamo essere certi che i piccoli aggiornamenti non romperanno casualmente i nostri forum. (Questo è probabilmente uno dei maggiori problemi di Discourse secondo me, e uno che ho visto sollevato altrove quando le persone discutono di opzioni per i forum. La volatilità è un vero svantaggio.)
Sì – Come da link, mi sono imbattuto in questo in un ambiente di sviluppo che non sarebbe basato su container. (Non l’ho ancora provato in container di produzione)
Penso che questa sia una delle cose di cui mi preoccupo, è se il percorso ‘standard’ presuppone l’esistenza di questi plugin, allora potrei incorrere in bug perché tutti gli altri accettano plugin pubblicitari. Devo o rischiare che emergano bug imprevisti, o gestire un carico di plugin aggiuntivo. Il mio obiettivo è avere la massima stabilità possibile per le mie distribuzioni.
Vale anche la pena sottolineare che anche il core di Discourse è piuttosto pesante in termini di utilizzo delle risorse rispetto ad altri forum. Penso che valga la pena cercare di mantenere il core leggero in modo da non esacerbare ulteriormente i problemi di prestazioni.
Non li ho ancora verificati per assicurarmi che non stiano caricando JavaScript di tracciamento/phone-home mentre sono disabilitati, ma fino ad allora assumerò che tu abbia ragione. Spero che qualcuno lo verifichi, perché sarà un grosso guaio se si scoprisse che non è vero.
Penso che il punto di Hellekin sul disordine sia valido, e penso anche che ciò che intendono con il plugin per le pubblicità delle grandi aziende tecnologiche non sarà ben accolto da alcuni nella comunità open source – il tipo che è più propenso a utilizzare forum open source in primo luogo.
Comunque, vorrei anche dire che apprezzo che tu ascolti il mio feedback, anche se non è facile 
4 Mi Piace
Penso che sia difficile sapere quali sono state revisionate in precedenza e quali no.
Mi sono chiesto brevemente se avessi controllato in precedenza per vedere se c’erano commenti aperti che ora mancano, dato che sono stati aggiunti solo i testi e non tutti i dati da Crowdin. Ma presumo che non voglia nemmeno conoscere la risposta a questa domanda. In definitiva, non fa differenza se nessuno risponde per mesi o se le domande e i commenti dei traduttori sono semplicemente spariti.
1 Mi Piace
Ci sono test per nessun effetto collaterale quando le directory dei plugin vengono rimosse con il nuovo bundle, per garantire che un plugin non diventi inavvertitamente un requisito?
2 Mi Piace
La nostra suite di test principale viene eseguita senza alcun plugin caricato, quindi sì, qualsiasi dipendenza da core → plugin dovrebbe essere rilevata da CI.
4 Mi Piace
Ho commentato le righe per clonare i plugin ma quando eseguo di nuovo il comando “launcher rebuild app” ricevo gli stessi messaggi:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 546 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'
exec failed with the params {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
---
HINT: Il plugin 'discourse-reactions' è ora incluso in Discourse e non dovrebbe essere incluso nella configurazione del tuo container.
Rimuovi la riga 'git clone https://github.com/discourse/discourse-reactions' dal tuo file containers/app.yml, quindi riprova.
Per maggiori informazioni, vedi https://meta.discourse.org/t/373574
---
---
HINT: Il plugin 'discourse-data-explorer' è ora incluso in Discourse e non dovrebbe essere incluso nella configurazione del tuo container.
Rimuovi la riga 'git clone https://github.com/discourse/discourse-data-explorer' dal tuo file containers/app.yml, quindi riprova.
Per maggiori informazioni, vedi https://meta.discourse.org/t/373574
---
---
HINT: Il plugin 'discourse-solved' è ora incluso in Discourse e non dovrebbe essere incluso nella configurazione del tuo container.
Rimuovi la riga 'git clone https://github.com/discourse/discourse-solved' dal tuo file containers/app.yml, quindi riprova.
Per maggiori informazioni, vedi https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** si prega di scorrere verso l'alto e cercare messaggi di errore precedenti, potrebbero essercene più di uno.
La causa del fallimento si trova sopra la riga FAILED.