In reply to @telegram_63397700:t2bot.io
Non è solo questione di abitudine, è anche questione di tempo e quello è diverso per ognuno

In reply to @telegram_63397700:t2bot.io
Sembra interessante, pero deve veramente diventare lo std, altrimenti è un wrapper I piu che le persone si devono imparare, tipo nix

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,

MIT License

Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND,

Apache 2.0

For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software.

GPL v3

In reply to @aciceri:nixos.dev
Vero che venite sabato 1 Giugno a continuare questi discorsi di persona?

In reply to @annib-ale:matrix.org
(poi per le dependency in termini di pacchetti Lua sono d'accordo con luarocks e c3n21, ci sono sicuramente modi migliori, ma credo che in realta' la maggior parte dei plugin dipenda solamente dall'API di neovim - queste dipendenze fra plugin sono un po' una cosa nuova, almeno su ampia scala)

plenary.nvim mi sembra che sia una dipendenza molto comune che potrebbe verrebbe gestita meglio da un package manager vero a questo punto invece che lasciare l'onere all'utente finale

Poi già il fatto che plenary reimplementa un subset di busted per unit testing per me è già sintomo che forse avere accesso ad un qualcosa di più strutturato gioverebbe più a tutti e faciliterebbe volendo anche lo sviluppo di plugin più completi, anche perché l'alternativa a questo è infilare questi pacchetti extra direttamente nel programma finale come è stato fatto per il serializzatore JSON in Lua se non erro