Agrupando mais plugins populares com o core do Discourse

É precisamente por isso que este tópico é para onde precisamos ser direcionados. O post original inclui uma lista que parece ser atualizada com bastante frequência. Se você olhar o histórico de edições, poderá dizer quais plugins foram adicionados e quando.

3 curtidas

Por enquanto terminamos! O último restante é o cakeday e será feito em alguns meses.

6 curtidas

Eu tropecei e caí nisso há pouco tempo. Comecei a mexer no desenvolvimento do Discourse, então queria praticar meu fluxo de trabalho de atualização:

# git pull
# bundle install
# pnpm install
# ./bin/rails db:migrate

Mas minha suposição é que o plugin Discourse AI requer o plugin Pgvector para PostgreSQL (que eu não sabia que existia antes):

== 20230710171141 EnablePgVectorExtension: migrating ==========================
-- enable_extension(:vector)
bin/rails aborted!
StandardError: An error has occurred, this and all later migrations canceled: (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 instalar isso, mas estou curioso se há alguma maneira de desabilitar plugins neste nível para que suas migrações sejam simplesmente ignoradas. (Eu preferiria não instalar software adicional, especialmente para um “plugin” que não estou interessado em explorar para desenvolvimento.)

4 curtidas

Também me deparei com isso hoje mais cedo. Instalei o pacote via sudo, após alguma ajuda do ChatGPT. Também estou me perguntando isso; será que deletar a pasta do plugin do diretório /plugins ajudaria :thinking:… mas um git pull mais tarde pode reinstalá-lo.

2 curtidas

Sou contra essa mudança. Normalmente, no desenvolvimento de software, ter um núcleo enxuto significa que a distribuição principal pode ser menor, mais rápida e com menos superfície de ataque. Minha última incursão em plugins me levou a ver que é tecnicamente possível que o código do plugin seja executado mesmo quando “desativado”, pois parecia depender do autor do plugin para verificar isso, então parece que isso aumenta significativamente o risco e o inchaço.

O problema mais imediato é que nenhuma instrução parece ter sido atualizada no guia de instalação (talvez eu apenas as tenha perdido?). Não está claro o que precisamos instalar para fazer as coisas funcionarem novamente. Resolvi alguns erros instalando o pacote do Ubuntu postgresql-16-pgvector, mas ainda tive alguns erros de vetor ao executar o db:migrate. Consegui contorná-los excluindo localmente o plugin de IA.

De qualquer forma, este é um monte de código extra, muitos desses plugins são completamente irrelevantes para os casos de uso da maioria das comunidades do Discourse. (Isso não quer dizer que sejam plugins ruins! Tenho certeza de que são muito úteis para as comunidades que precisam deles. Apenas tenho dificuldade em ver que toda comunidade de fórum precisa vir com integração Zendesk, etc.). O plugin de IA em particular, dadas suas exigências adicionais que estão quebrando as coisas, definitivamente deveria ser dispensado, na minha opinião.

Em um nível pessoal, quando faço login no meu painel de administração e de repente vejo um monte de plugins de anúncios, mesmo que o código deva ser inerte, isso me deixa extremamente preocupado. Eu, nos termos mais fortes possíveis, desejo expressar que NÃO quero nenhum plugin de anúncios de grandes empresas de tecnologia nas minhas instalações por padrão, mesmo desativados. Essa é uma indústria que historicamente tem sido incrivelmente abusiva em relação à privacidade do usuário e o Discourse não se ajuda ao distribuir tais integrações por padrão. As pessoas que querem anúncios não teriam dificuldade em encontrar o plugin necessário, não é necessário incluí-lo em todas as instalações.

TLDR: Por favor, reconsiderem esta mudança. :folded_hands:

5 curtidas

O Discourse está integrando plugins ao núcleo que são sempre oferecidos em suas hospedagens oficiais

2 curtidas

Concordo que isso traz um volume extra na interface de administração, com muitos nomes de marcas que contam como publicidade para meu cérebro. Isso não é legal. Como um defensor de software livre que se esforça para evitar grandes marcas, considero que isso dá um passo que o Ubuntu deu anos atrás, antes de ser totalmente colonizado pela Armazon, Gaggle e consortes. Se você deixar que eles cheguem aos seus olhos, eles acabarão os engolindo.

Agrupar os plugins no núcleo também oferece uma oportunidade para os desenvolvedores transformarem equivocadamente a funcionalidade de um plugin em um requisito ao longo do tempo, enquanto mantê-los como plugins garante que esse tipo de erro não possa ser cometido.

O @team pode esclarecer a justificativa por trás dessa mudança?

Se for uma questão de acelerar as instalações na infraestrutura do Discourse, talvez a criação de um pacote discourse-hosting-bundle criado automaticamente no CI possa alcançar o mesmo resultado?

4 curtidas

@david, você pode, por favor, manter a ordem alfabética na lista de Plugins Afetados?

A motivação aqui é proporcionar uma experiência mais fluida para usuários iniciantes do Discourse, para que eles tenham uma experiência mais “completa” do Discourse logo de cara.

Outra motivação é a experiência do desenvolvedor para nossa equipe e para contribuidores da comunidade. Ao agrupar todos esses plugins com o core, não há mais necessidade de considerar a compatibilidade com diferentes versões do core. Isso é particularmente útil para plugins como o discourse-ai, que estão sendo muito desenvolvidos no momento, em conjunto com mudanças relacionadas no core.

Os plugins de autenticação de marca são os que têm maior probabilidade de serem incorporados ao core, assim como nossos métodos de autenticação existentes, como Google/Facebook/etc. Portanto, há uma boa chance de serem removidos da lista em um futuro não muito distante.

Essa mudança não se relaciona ao desempenho em nossa hospedagem. Já tínhamos uma distribuição pré-compilada com todos esses plugins, e mais, como você descreve. :ok_hand:

Corrigi a ordenação :+1:

7 curtidas

Já foi respondido no op:

Alguns exemplos disso:

  • não precisamos nos preocupar com versionamento se adicionarmos algo no core para um plugin, sabemos que ambos estão na mesma versão
  • mais fácil testar um plugin dependendo de outro plugin se o código estiver presente para ambos
  • quando mudamos algo no core, muitas vezes temos que fazer vários PRs apenas para corrigir especificações em plugins, agora isso significa apenas um PR autônomo

O resultado final é mais tempo disponível para a equipe do Discourse melhorar e manter o produto em vez de lidar com esse tipo de problema, então, eventualmente, você também ganha.

12 curtidas

Eu gostaria muito que esses desaparecessem da minha interface, mas eles estão apenas ocupando espaço, porque não são opcionais nem ocultos: eles fazem parte do núcleo. É exatamente por isso que estamos preocupados.

Com relação à experiência do primeiro usuário, talvez mudar o template do contêiner para incluir e documentar o pacote oficial funcione:

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          # O plugin docker_manager é obrigatório para atualizações automatizadas baseadas na web
          - git clone https://github.com/discourse/docker_manager.git
          # Os seguintes plugins são instalados em todas as instâncias hospedadas do Discourse.
          # Descomente a linha removendo `#` antes da linha `- git clone` para ativá-los.
          # Veja https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/
          # Plugin de Publicidade do Discourse (Ads): https://meta.discourse.org/t/discourse-advertising-plugin-ads/33734
          #- git clone https://github.com/discourse/discourse-adplugin
          # Afiliado do Discourse
          #- git clone https://github.com/discourse/discourse-affiliate
          # ...
          # ...
          # Por favor, adicione outros plugins abaixo. Para uma lista de plugins oficiais, veja:
          # https://meta.discourse.org/tag/official
          # Para todos os plugins disponíveis, veja:
          # https://meta.discourse.org/c/plugin/22

Com relação à experiência do desenvolvedor, certamente você pode automatizar a passagem de versões de plugins de outra forma menos intrusiva. Por exemplo, usando uma regra pups para descomentar os plugins usando a estratégia de documentação acima.

Você poderia até ter um template de contêiner que faça isso por você:

templates:
  - "templates/discourse.hosting.yml"
  - "templates/discourse.core-bundle.yml"

Note que minha primeira impressão foi boa: eu pude descobrir alguns plugins interessantes que ainda não estavam no meu radar. Mas sim, como tenho visto você otimizando e procurando o denominador comum mínimo na última década, fico surpreso que essa seja a maneira como você lida com tal proposta.

4 curtidas

Acredito que você possa adicionar um rm - rf discourse-ai onde os comandos git clone normalmente ficam. Eu mesmo não fiz isso.

4 curtidas

Sim, tecnicamente você pode remover todas as pastas no diretório de plugins e o Discourse principal ainda funcionará

5 curtidas

É uma boa aposta que esses plugins desenvolvidos pela equipe do discourse sigam as regras e adicionem sobrecarga mínima. Tê-los todos ativados facilita ver que todos funcionam juntos e compartilham os mesmos requisitos.

Você está executando um postgres externo em vez do incluído? Você está executando uma configuração de dois contêineres que não é atualizada há muito tempo?

Você pode se esforçar para removê-los, mas eles não podem fazer nada a menos que você crie uma conta com as empresas malvadas e obtenha chaves para permitir o rastreamento.

5 curtidas

Obrigado pela sua resposta,

Esperançosamente sim, mas é uma área de superfície adicional para bugs e ataques, em troca de nenhum benefício para comunidades que não usam esses plugins (que serão a maioria das comunidades).

Sinto que o Discourse identificou um problema real aqui, mas apresentou a solução errada.

Concordo plenamente que há um problema raiz real com a fragilidade do ecossistema de desenvolvimento/plugins para o Discourse. É definitivamente difícil desenvolver contra um alvo em movimento, e as mudanças de API no núcleo certamente tornam isso difícil. Em certa medida, isso faz parte do desenvolvimento contra o “bleeding edge” (vanguarda), mas é exatamente por isso que esse não deveria ser o comportamento padrão. Ter apenas alguns plugins simples me permite entender e empatizar com o seu problema (que é muito maior em escopo do que o meu).

No entanto, o que o Discourse está fazendo aqui é apenas adiar o problema. Talvez resolva o problema para o Discourse, mas não resolve para os outros desenvolvedores de plugins. Todos os outros estão passando pela mesma dor, apenas em menor escala.

Uma solução melhor seria ter uma série LTS (Long-Term Support - Suporte de Longo Prazo) mais robusta contra a qual se possa desenvolver. Sei que isso foi discutido em outros lugares, então não vou repetir, mas um dos maiores desafios para as comunidades, desenvolvedores de plugins e até mesmo funcionários do Discourse parece ser a falta de um LTS. A branch estável é ativamente desaconselhada. Se um pipeline de desenvolvimento mais tradicional fosse usado, seria muito mais fácil para o desenvolvimento de plugins. Teríamos momentos conhecidos em que as coisas quebrariam (grandes atualizações de versão) e poderíamos nos planejar. Caso contrário, podemos ter certeza de que as atualizações menores não quebrarão aleatoriamente nossos fóruns. (Esta é provavelmente uma das maiores dores do Discourse, na minha opinião, e uma que vi ser levantada em outros lugares quando as pessoas discutem opções de fórum. A volatilidade é um inconveniente real.)

Sim – Conforme o link, encontrei isso em um ambiente de desenvolvimento que não seria baseado em contêineres. (Ainda não tentei isso em contêineres de produção)

Acho que isso é uma das coisas que me preocupam: se o caminho “padrão” assume que esses plugins existem, então posso encontrar bugs porque todo mundo está aceitando plugins de publicidade. Tenho que arriscar bugs inesperados surgindo ou lidar com carga adicional de plugins. Meu objetivo é ter o máximo de estabilidade possível para minhas implantações.

Vale também ressaltar que até mesmo o core do Discourse é bastante pesado em termos de uso de recursos em comparação com outros fóruns. Acho que vale a pena tentar manter o core leve para não exacerbar ainda mais os problemas de desempenho.

Ainda não auditei estes para ter certeza de que eles não estão puxando JavaScript de rastreamento/phone-home enquanto desativados, mas até lá assumirei que você está correto. Espero que alguém verifique isso, porque será um grande desastre se isso se provar falso.

Acho que o ponto de Hellekin sobre a desordem é válido, e também acho que o que eles estão querendo dizer com o plugin de anúncios de grandes empresas não será bem recebido por alguns na comunidade de código aberto – o tipo que tem mais probabilidade de usar fóruns de código aberto em primeiro lugar.

De qualquer forma, também gostaria de dizer que aprecio você ouvir meu feedback, mesmo que não seja fácil :slight_smile:

4 curtidas

Acho difícil saber quais foram revisados ​​antes e quais não foram.

Eu me perguntei brevemente se você havia verificado antecipadamente se havia algum comentário aberto que agora está faltando, já que apenas os textos foram adicionados e não todos os dados do Crowdin. Mas presumo que eu nem quero saber a resposta para essa pergunta. Em última análise, não faz diferença se ninguém responde por meses ou se perguntas e comentários de tradutores simplesmente desaparecem.

1 curtida

Existem testes para ausência de efeitos colaterais ao remover diretórios de plugins com o novo pacote, para garantir que um plugin não se torne inadvertidamente um requisito?

2 curtidas

Nossa suíte de testes principal é executada sem nenhum plugin carregado, então sim, qualquer dependência do core → plugins deve ser detectada pelo CI.

4 curtidas

Comentei as linhas para clonar os plugins, mas quando executo novamente o “launcher rebuild app”, recebo as mesmas mensagens:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse &amp;&amp; su discourse -c 'bundle exec rake db:migrate' failed with return #&lt;Process::Status: pid 546 exit 1&gt;
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: O plugin 'discourse-reactions' agora está incluído no Discourse e não deve ser incluído na configuração do seu contêiner.
Remova a linha 'git clone https://github.com/discourse/discourse-reactions' do seu arquivo containers/app.yml, e tente novamente.
Para mais informações, veja https://meta.discourse.org/t/373574
---
---
HINT: O plugin 'discourse-data-explorer' agora está incluído no Discourse e não deve ser incluído na configuração do seu contêiner.
Remova a linha 'git clone https://github.com/discourse/discourse-data-explorer' do seu arquivo containers/app.yml, e tente novamente.
Para mais informações, veja https://meta.discourse.org/t/373574
---
---
HINT: O plugin 'discourse-solved' agora está incluído no Discourse e não deve ser incluído na configuração do seu contêiner.
Remova a linha 'git clone https://github.com/discourse/discourse-solved' do seu arquivo containers/app.yml, e tente novamente.
Para mais informações, veja https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.

O motivo da falha está localizado acima da linha FAILED.