Jaja, como dije, lo estoy usando para otra cosa, no puedo simplemente matarlo. Seguramente no debería ser tan difícil cambiar el puerto (famosas últimas palabras, parece)
1 me gusta
Sugiero que preguntes eso en el tema enlazado, por mi breve vistazo a ese script parece codificado, pero podría estar equivocado, el script podría estar compilado.
También noté las cosas codificadas, pero hay referencias a una configuración de puerto en archivos yml, así como a variables de entorno. Por ahora, me rindo. Ya he invertido demasiado tiempo en lo que quería probar.
Inicié una VM con una Ubuntu 22.04 nueva. La instalación de desarrollo falla: Install Discourse for development using Docker - #213 by nordize
…No es mi día… pero definitivamente tampoco son minutos (sin dobles sentidos). Gracias por tu tiempo y lamento que también tuvieras que desperdiciarlo.
1 me gusta
@merefield pregunta rápida: ¿hay una forma más rápida de obtener actualizaciones del código del plugin en el contenedor que haciendo d/shutdown_dev; d/boot_dev, que tarda una eternidad y descarga una tonelada de datos al descargar imágenes de docker? Hacer eso cada vez que cambio una línea de código para probar en el navegador parece excesivo incluso para un entorno dockerizado.
Reiniciar el servidor de rails con d/rails s no ve los cambios de código de mi plugin.
Esto solo debería ser necesario si quitas o agregas un plugin, no si cambias una línea de código.
Si esa línea es Ruby o CSS, cargará en caliente el nuevo código. Si es Ruby, deberías ver los unicornios reiniciándose en la terminal, si mal no recuerdo.
Si es javascript, solo tienes que refrescar el navegador.
Debería haber mencionado que mi plugin está en un enlace simbólico, y cualquier cambio no se refleja a menos que hagas d/shutdown_dev; d/boot_dev (esto también se menciona en la guía), pero esperaba que hubiera una solución alternativa a través del propio Docker, ya que estos deberían ser solo archivos mapeados. Podría preguntar en el otro hilo o ver si puedo modificarlo como solución alternativa (o no usar enlaces simbólicos).
Esto no me suena bien. El proceso del servidor simplemente se reinicia tal como lo hace en una instalación que no es de Docker. Los enlaces simbólicos no deberían marcar la diferencia y son la forma apropiada de trabajar. No tengo idea de por qué el tuyo no se comporta de esta manera…
Bueno, siéntete libre de intentarlo. No lo habría publicado si reiniciar rails y ember fuera suficiente. Como decía, la guía también señala esto.
Según la guía, ejecutar esos comandos de reinicio solo debería ser necesario si cambia la población de plugins (por ejemplo, al eliminar o agregar un symlink válido). De lo contrario, Rails debería detectar los cambios en el código y reiniciar sus procesos. Podría ser posible desactivar este comportamiento en la configuración, pero ese debería ser el comportamiento predeterminado.
Aquí hay un ejemplo del reinicio automatizado, aunque en una instalación de desarrollo no dockerizada, pero el comportamiento debería ser similar:
[DEV]: Edited files which are not autoloaded. Restarting server...
- plugins/discourse-multilingual/extensions/post.rb
RESTARTING UNICORN
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : reaped #<Process::Status: pid 228047 exit 0> worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : reaped #<Process::Status: pid 228048 exit 0> worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : reaped #<Process::Status: pid 228049 exit 0> worker=2
I, [2022-06-15T13:25:29.082877 #227981] INFO -- : master complete
I, [2022-06-15T13:25:29.947587 #228661] INFO -- : Refreshing Gem list
Got TERM signal
Shutting down
Terminating quiet threads
Scheduler exiting...
Pausing to allow jobs to finish...
Bye!
Starting CSS change watcher
I, [2022-06-15T13:25:38.326511 #228661] INFO -- : listening on addr=0.0.0.0:3000 fd=25
Edité el archivo post.rb y guardé, el resto es automático.
Lamento no tener acceso a mi máquina de desarrollo basada en docker donde me encuentro actualmente para confirmar que este es el caso en la instalación dockerizada también, pero recuerdo que es así, a menos que algo haya cambiado.
No me lo estoy inventando, ¿sabes? 
y no puedo hacer mucho si me dicen que debería funcionar Seguí esa guía al pie de la letra en una nueva instalación de VM con Ubuntu 22.04.
- El enlace simbólico del plugin en la subcarpeta discourse/plugins/ y el cambio de código JS en el plugin no se ven a menos que haga d/shutdown_dev; d/boot_dev, a pesar de reiniciar d/rails s y d/ember-cli
- Copiar el plugin en la subcarpeta discourse/plugins/ y cambiar el código JS en el plugin sí se ve sin hacer d/shutdown_dev; d/boot_dev, pero solo reiniciando d/rails s y d/ember-cli
Siéntete libre de probar lo anterior. El plugin en cuestión es discourse-math, cambiando el código en assets/initializers/javascript/*.js (ten en cuenta que estos archivos de plugin en particular se cargan por separado y no son llamados directamente por el navegador; no estoy seguro de si eso marca la diferencia, todavía no he profundizado mucho en cómo funciona Discourse internamente).
p.d. Sé que necesito refrescar el navegador (saltándome la caché)… tenme algo de consideración.
De la fuente original, por así decirlo:
Así que el problema es posiblemente local para ti, o alguna regresión en la compilación actual, pero esto último parece poco probable.
Me rindo, tú ganas. Si alguna vez lo intentas tú mismo, házmelo saber.
No estoy intentando “ganar”, pero debemos llegar a una base de entendimiento:
- se supone que se reinicia automáticamente ante cambios en el código del backend.
d/shutdown_dev; d/boot_devsolo debería ser necesario cuando cambias la población de plugins, no solo líneas de código individuales.
Esto debería reducir dónde necesitas buscar para arreglar las cosas.
Acabo de hacer git pull y probé un cambio, se reinicia, así que no es una regresión de compilación.
Lo aún más extraño para mí es que, al ser una configuración de Docker, es más difícil anular inadvertidamente el comportamiento empaquetado, por lo que debería ser más confiable.
Probaré esto en mi compilación de Docker cuando llegue a casa.
Aprecio que esto sea frustrante y molesto como flujo de trabajo en este momento, ciertamente me molestaría y frustraría.
Si has borrado completamente tu caché, no estoy seguro de qué sugerir en esta etapa.
Ten en cuenta que los inicializadores solo se ejecutan una vez cuando abres la página por primera vez. Por lo tanto, el reinicio de los procesos del servidor es irrelevante (y solo cubre el código del backend).
Desactivo la caché de las herramientas de desarrollo cada vez que desarrollo aplicaciones web. Solo soy nuevo en el código y las herramientas de Discourse, no en el desarrollo (web). También publiqué una pregunta en el hilo de la guía. Por ahora, simplemente copié el directorio del plugin en discourse/plugins/ para evitar las molestias.
1 me gusta
Intentaré algo similar más tarde hoy y le informaré.
Por lo que puedo ver en las llamadas del navegador, el código JS del inicializador JS se carga lateralmente a través de discourse-math.js, mediante eval() (en cada apertura de página), lo que sugiere claramente que algún componente del lado del servidor está procesando y almacenando en caché ese código JS del inicializador (que es el que estoy cambiando), y por lo tanto, es ese caché del lado del servidor en particular el que necesita ser activado para volver a almacenarlo en caché… lo que no sucede si el plugin está enlazado simbólicamente pero sí cuando se copia.
No estoy familiarizado (y no quería familiarizarme en este momento por falta de tiempo) con la cadena de herramientas de Discourse… de ahí mi ingeniería inversa y mis preguntas.
1 me gusta
desarrollo sin docker:
Lo intenté ahora mismo en un inicializador, no fue necesario reiniciar ningún proceso, solo refrescar el navegador detectó el cambio en el código js… esto fue sin docker… lo intentaré más tarde
…un tiempo después…
desarrollo con docker:
OK, ahora estoy en mi PC y probé la solución de docker para la cual hice una instalación completamente nueva, y estoy viendo el mismo comportamiento: las ediciones en el inicializador funcionan para mí, dejando los servidores en ejecución y simplemente guardando el archivo y refrescando el navegador, no es necesario reconstruir el contenedor.
Así que el mismo comportamiento
(Usé el plugin Discourse Locations como ejemplo.)
¿Estás seguro de que no hay nada malo con tu inicializador?
Dado que funciona después de reiniciar, sí, estoy seguro. Para una reproducibilidad 100% confiable, podrías probar el plugin específico que mencioné, habilitarlo en la GUI y elegir la opción Katex en la GUI, luego editar el archivo JS inicializador que mencioné, y luego hacer una publicación con código Latex dentro; este plugin puede ser especial, posiblemente cargando su inicializador JS sobre la marcha solo si la publicación contiene código Latex (eso es lo que haría si diseñara Discourse)… pero no espero que pierdas tiempo en este problema, ni estoy tratando de convencerte de que no me estoy inventando las cosas
1 me gusta
Sí, buen punto.
Eso es muy, muy extraño.
Mi única sugerencia por el momento es cambiar a una instalación no Docker (que lamentablemente tarda más en configurarse 
) y ver cómo va.
Sería bueno obtener alguna opinión del equipo sobre lo que podría estar saliendo mal para ti. Sin embargo, la solución Docker seguramente reduciría las posibilidades de un comportamiento diferente aquí, ya que está contenerizada y es atómica 