HerlockSholmes

Archivos útiles en doom

Como se ha visto en entradas anteriores, las usuarias pueden seleccionar dentro del conjunto de paquetes que vienen definidos ya en doom-emacs mediante la manipulación en ~/.doom.d/init.el (al que se puede acceder rápidamente mediante los atajos C-x p p lo que EViL sería SPC f p); en el directorio ~//.doom.d están los tres archivos que permiten cambiar el funcionamiento de Emacs doom: init.el, config.el, y packages.el.

En el caso de que la usuaria necesite agregar un paquete nuevo a su configuración, basta con que lo declare en el archivo de su configuración personal ~/.doom.d/packages.el, y que luego edite las opciones que quiere de ese paquete en el archivo ~/.doom.d/config.el.

Instalando un paquete de ejemplo:

Para esta entrada de blog, se guiará a través del proceso de instalación del paquete org-super-agenda como ejemplo del proceso de personalización de doom. Lo primero que se debe hacer es definir el paquete a utilizar en el archivo packages.el, en este archivo la usuaria puede tener toda la lista de paquetes que quiera agregar incluyendo la fuente desde dónde descargarlo (un repositorio en git, melpa, elpa, etc.) pero sin declarar la versión del paquete. Para hacerlo es tan simple como agregar la siguiente línea en el archivo packages.el:

(package! nombre-del-paquete)

En nuestro caso, sería:

(package! org-super-agenda)

Una vez guardado el archivo, se debe correr la orden refresh de doom, para que éste busque e instale las fuentes más actuales en elpa:

$ sh ~/.emacs.d/bin/doom refresh

Va a reconocer el nombre del nuevo paquete y debemos aceptar mediante la tecla y cuando se nos consulte.

Configurando el paquete instalado:

Una vez lista la instalación del paquete, podemos configurarlo de acuerdo a las necesidades de la usuaria mediante una macro bastante útil que se llama def-package! y es una capa de abstracción del conocido use-package. Para esto, se debe abrir el archivo config.el y escribir la configuración que se requiera, por ejemplo:

(def-package! org-super-agenda :after org-agenda :init (setq org-super-agenda-groups '(grupos que correspondan, ver)) :config (org-super-agenda-mode))

Ya cuando se haya configurado el paquete, basta con que la usuaria guarde el archivo config.el, vuelva a abrir una instancia de Emacs y revisar las nuevas funcionalidades que integran sus paquetes preferidos.

El uso de otra macro:

Si la usuaria quiere configurar un paquete que ya está incluido en Emacs doom, en vez de utilizar def-package! es posible que quiera probar con after!, que es una macro parecida a la primera pero que permite configurar algo después de que se haya cargado un paquete, revisemos un ejemplo configurando org-mode:

(after! org (setq alguna-configuración-deseada))

De esta manera, Emacs doom se convierte en una configuración de Emacs que es muy personalizable y que puede ser amigable para las usuarias novicias para experimentar con esta interfaz de texto programable.

#emacs #doomemacs #instalarpaquetes

Buffers en Emacs

Emacs, más allá de editor de texto, es (si la usuaria permite esta redefinición) una interfaz orientada a texto que además es programable. Este cambio en la perecepción de ¿Qué es Emacs? permite a las usuarias comprender el ¿Por qué? hay términos cuya definición cambia en Emacs.

Tal es el caso de los buffers y las ventanas que pueden confundir a las usuarias novicias en Emacs, ya que tradicionalmente llamamos ventana a la interfaz del programa que estamos corriendo; mientras en Emacs este concepto aplica a nuevos cuadros (o frames) abiertos dentro del programa. Para abrir una “nueva” ventana se debe presionar C-x 3 para dividir la ventana verticalmente (SPC w v en EViL) o si se quiere divir de manera horizontal se debe presionar C-x 2 (SPC w s en EViL). En el caso de los buffers, estos se refieren a la interfaz de todo aquello que tiene nombre o dicho con otras palabras: cuando se abre un archivo, estoy editando un buffer, pero lo mismo se puede decir en el caso de dired o de la terminal eshell.

Navegación en Emacs

Entre buffers

Utilizando la redefinición anterior, la navegación en Emacs se hace mucho más fluida ya que considera toda aquella interfaz de texto abierta como un buffer (que puede a su vez ser un espacio de trabajo u otro tipo). Para cambiar entre estos buffers basta con presionar C-x b en Emacs (SPC b B en EViL) y se mostrará una lista de los buffers a la que nos podemos mover; y debido a que son todo aquello que tiene nombre, la usuaria puede escribir el nombre (o alguna parte del mismo) para encontrar el buffer deseado.

Esto también es aplicable al contexto de un proyecto en que se esté trabajando con projectile. Si la usuaria ya se encuentra en un archivo que está editando, pero quiere acceder a otro, lo puede hacer con C-x C-f en Emacs (SPC SPC con EViL siempre y cuando se haya abierto anteriormente el archivo), esto le permitirá buscar todos los archivos que integran el proyecto (y de ser necesario, buscar archivos en otros proyectos).

Entre ventanas

Cuando las usuarias acostumbran tener varias ventanas abiertas, navegar entre ellas se puede hacer con el atajo C-x o que marcará cada ventana con una letra diferente para así moverse a ella. Pero muchas veces este atajo resulta algo tosco, por lo que usar C-w w que irá circulando entre las ventanas abiertas pero podría tardar tiempo demás; por lo que utilizar C-w (teclas de movimiento de Vi) en Emacs (SPC w (teclas de movimiento de Vi) con EViL) es lo que permite un mayor control de los movimientos de selección para ventanas.

Las ventanas se cierran mediante el atajo C-w c en Emacs (SPC w c en EViL), pero además la usuaria podría variar el tamaño de las ventanas utilizando C-w < o C-w > para reducir o ampliar el ancho de la ventana (SPC w < o SPC w > con EViL); pero si se quiere igualar el ancho, basta con presionar C-w = (SPC w = en EViL). Esto también se puede aplicar para ventanas divididas horizontalmente, usando C-w + para aumentar el alto (SPC w +) o C-w - para disminuirlo (SPC w -).

Notas de interés

Si bien este capítulo fue algo más abstracto en cuanto a su primera sección, espero que el control de navegación en Emacs le pueda servir a la lectora para introducirse con mayor profundidad en esta interfaz orientada a texto que es ajustable a las necesidades de quien lo ocupa (un pilar fundamental de las 4 libertades de software según el autor de estas entradas).

#emacs #doomemacs #guix #navegación

Capítulo 4: Agregando un canal público.

Una vez más ha vuelto esta serie, luego de un breve descanso que permite hacer lindos experimentos con Guix. Si bien en otras distros también existen repositorios personales (como los ppa's y AUR), en Guix la construcción de los mismos se ve facilitada por la extensibilidad de Guile-Scheme.

Se puede tener una máquina personal dedicada a compilar los programas que la usuaria estima convenientes y luego hacer las actualizaciones desde ahí ya pre-compiladas, porque al ser construcciones reproducibles, los estados generados en /gnu/store serán siempre los mismos.

Además de esa facilidad, las usuarias de Guix pueden mantener recetas de configuración de paquetes (que idealmente sigan las posturas éticas del Software Libre) escritas en la implementación de Scheme llamada Guile; estas recetas se pueden mantener en un repositorio público (indicando desde dónde descargar el código fuente) para compartir nuevos paquetes definidos según las reglas que detalla el manual.

Una vez las usuarias tienen un canal escrito con las definiciones necesarias, se puede incluir en la ruta de descargas mediante el siguiente procedimiento, que se detalla en profundidad en esta sección del manual.

Se debe crear un archivo de configuración en la ruta ~/.config/guix/channels.scm, si la usuaria desea usar otra fuente para descargar los paquetes principales de guix (diferentes de los oficiales de GNU), lo que debe incluir es lo siguiente:

;; Le dice a "guix pull" que use un repositorio local. (list (channel (name 'guix) (url "<https://ejemplo.org/mi-guix.git>") (branch "super-hacks")))

Así, cuando se invoque guix pull para calcular las diferencias de las fuentes con el local, se hará la derivación desde https://ejemplo.org/mi-guix.git.

Pero si lo que desea la usuaria es seguir usando las fuentes oficiales de GNU, entonces no es necesario que se agregue un canal llamado 'guix; haré énfasis en esto: Para guix, las fuentes personales o de voluntarias mantenedoras se llaman canales.

Si la usuaria quiere configurar un canal que tiene sólo nuevos paquetes (sin reemplazar las fuentes de GNU), lo que debe hacer es editar ~/.config/guix/channels.scm y agregar lo siguiente:

;; Añade mis paquetes personales a aquellos que Guix provee. (cons (channel (name 'mis-paquetes-personales) (url "<https://ejemplo.org/paquetes-personales.git>")) %default-channels)

Y luego de esto, ejecutar guix pull lo que actualizará todos los canales desde los que se buscan definiciones de paquetes.

Aplicando el uso de canales: instalación de telega.el

Ahora veamos un ejemplo real en que esto puede ser útil, el mantenedor de este canal se ha dedicado a empaquetar tanto tdlib (la librería que se usa para generar clientes de Telegram) y telega.el lo que es de especial interés tanto para el autor de este blog, como para unos amigos integrantes del canal 4libertades Chile.

Los procedimientos para usar telega desde Emacs son los siguientes:

• Instalar emacs y emacs-guix desde guix (lo que hace de este gestor de paquetes una dependencia fuerte).
• Añadir el canal de https://git.sr.ht/~brettgilio/cfg.
• Instalar emacs-telega desde el nuevo canal.
• Instalar emacs-visual-fill-column desde guix.

Para instalar guix en una máquina hospedera con una distribución diferente a Guix system, es recomendable revisar esta entrada del blog (sigo recalcando lo de leer el manual). Luego de eso, se procede a instalar la versión de Emacs y el paquete emacs-guix que está en los repositorios oficiales de GNU Guix (esto es porque esa versión de Emacs lee lo que está en la /gnu/store además de los clásicos directorios de configuración para Emacs).

Esto se hace simplemente mediante:

guix package -i emacs emacs-guix

o

guix install emacs emacs-guix

Luego pasamos a editar los canales que formarán parte de nuestros repositorios en ~/.config/guix/channels.scm, sin alterar el original de GNU, sería un archivo en blanco al que agregar lo siguiente:

;; Canal de Brett, para su config (cons (channel (name 'brett) (url "<https://git.sr.ht/~brettgilio/cfg>")) %default-channels)

Y para que se actualicen los canales nuevos, actualizamos las fuentes mediante:

guix pull

Lo que entrega el mensaje de que hay nuevos paquetes disponibles (los que están definidos en esa configuración).

Una vez listo esto, se puede instalar emacs-telega y emacs-visual-fill-column invocando guix package de la siguiente forma:

guix install emacs-telega emacs-visual-fill-column

Con este conjunto de procedimientos listos, basta con que la usuaria haga correr la versión de Emacs instalada mediante guix (que será la única que reconozca estos paquetes recién instalados) y correr M-x guix-emacs-autoload-packages, luego de eso invocar a Telega mediante M-x telega.

Actualización

Desde hace unas semanas que tanto TDLib como emacs-telega están disponibles en la rama master de guix, por lo que añadir el canal de Brett no es necesario.

Sin embargo, esta entrada de blog quedará como ejemplo e instructivo para esta función tan versátil de guix.

#guix #canalesPersonales #emacs #telega

¿Qué es Dired?

En el capítulo anterior se presentaban herramientas para el flujo de trabajo en Emacs por medio de proyectos; en esta entrada se hará una breve introducción al uso del paquete Dired que viene de “Directory editor” y significa Editor de directorios en inglés.

Para revisar un archivo de proyecto, se utiliza Projectile, pero ¿Qué pasaría cuando en vez de abrir un archivo, se abre un directorio?. En esta situación es cuando se invoca el modo Dired, que muestra detalles del contenido en el directorio y permite interactuar con el mismo presionando ( en Emacs () en EViL) para ver más o menos información; si la usuaria desea seleccionar un archivo o directorio, lo puede hacer presionando RET (la tecla Enter en ambas configuraciones de teclado) o se puede mover al directorio anterior presionando ^ (- en EViL).

En caso de que la usuaria quiera cambiar esos atajos de teclado, basta con agregar en ~/.doom.d/config.el lo siguiente:

(global-set-key (kbd "atajo que desee") 'nombre-de-la-función)

Dired nos permite gestionar los directorios tal como se hace desde la terminal, creando, moviendo, borrando o incluso generando symlinks entre los directorios de una manera simple y directa.

Funciones avanzadas de Dired

Para crear un nuevo directorio, basta con presionar la tecla +, lo que abrirá una intefaz de consulta sobre el nombre de este nuevo directorio. Si lo que se quiere es borrar un directorio, se debe marcar con la tecla d y luego eso se presiona x para ejecutar la deleción marcada; si se marca algo accidentalmente, se puede deshacer la selección con u (si es un único archivo) o con U si son todos los archivos los que se quieren dejar de marcar.

Se puede usar s (o en EViL) para ordenar los archivos y directorios según nombre o fecha de modificación, también se le pueden modificar los atributos a directorios o archivos presionando la tecla M (esto mostrará opciones de modificación para lectura y escritura). Modificar las usuarias a las que pertenece un archivo o la carpeta se puede realizar presionando O.

Si la usuaria quiere trabajar con dos buffers abiertos, lo puede hacer con C-x 3 (que corresponde a SPC w v en EViL), moviéndose entre estos buffers con C-x o y luego, para copiar archivos entre dos carpetas con Dired lo único que debe hacer es marcar los archivos a transferir con m para después presionar C que lo ejecutará en el buffer adyacente. Por otra parte, si lo que se quiere es mover archivos, se deben marcar con m y luego presionar R para que se transfieran los archivos o directorios marcados al buffer adyacente.

Finalmente, para renombrar los directorios o archivos, se puede hacer con C-x C-q (i que activa el modo insert de EViL) y, una vez finalizada la edición del nombre, presionar C-c C-c (C-w en EViL) para que se escriba al disco.

Esto no es más que una pincelada de lo que se puede hacer con Dired, una herramienta que facilita la interacción tanto con archivos como con directorios de nuestros proyectos.

#doomEmacs #emacs #dired #distroEmacs #guix

En el capítulo anterior se detalla el inicio rápido de esta configuración dogmática que es Doom Emacs, ahora profundizaremos en el uso de tres herramientas incluidas en esta distribución.

Como somos animales de costumbres, suele ser bueno tener espacios cuyo comportamiento sea consistente; la administración de ese trabajo (documentos de texto, programas de configuración, pequeños y grandes programas creados) también debería tener cierta consistencia. Como Emacs es un editor de texto tan hackeable, hay quienes escriben paquetes para que su utilización sea semejante a los editores más modernos.

Durante estas entradas, utilizaré los atajos por defecto de Emacs y entre paréntesis los que corresponden a EViL. Por ejemplo, para abrir un archivo el atajo es C-x f que significa presionar la tecla Control junto a x y luego, la tecla f (con EViL, sería SPC f . o SPC . donde SPC es la tecla espacio). En Doom Emacs, cuando se presiona C-x o C-c (SPC) se abre un pequeño buffer en la zona inferior de la ventana que permite visualizar las siguientes teclas asociadas a este atajo, mostrando en azul los comandos, y en violeta secuencias que se pueden encadenar (simbolizadas también por un + como prefijo).

En la presente entrada, las usuarias podrán aprender a usar tres herramientas versátiles incluidas en Doom Emacs, la primera de ellas un gestor de proyectos llamado Projectile.

Projectile

Es un gestor de proyectos en los que los directorios marcados por la usuaria son tratados con accesos más directos (por ejemplo usando treemacs). Para estos efectos, la usuaria puede asociar sus proyectos por medio del comando M-x projectile-discover-in-directory (donde M es la tecla Meta o Alt, también se puede presionar Alt gr para que de inmediato se tome como M-x) y luego seleccionando un directorio que contenga los proyectos, así Projectile lo anexará a sus entradas marcadas.

Projectile reconoce los contenidos para un directorio como proyectos si contienen archivos relacionados a git, mercurial, darcs, y bazaar. Si se quiere que reconozca un directorio como proyecto, basta con que ese directorio contenga un archivo vacío llamado .projectile.

Luego de marcar los directorios que la usuaria quiere tener asignados como proyecto, puede acceder a la lista presionando C-c p p (SPC p p) lo que puede tratar para seleccionar directamente archivos en los que esté trabajando.

Así mismo, se pueden especificar un conjunto de directorios en los que projectile puede buscar, si la usuaria así lo estima, puede modificar en su configuración personal accediendo al archivo config.el en el directorio .doom.d (el atajo para esto es C-c f c o SPC f p), ingresando lo siguiente:

(setq projectile-project-search-path ("/Directorio1" "/Directorio2"))

Y luego actualizar mediante M-x projectile-discover-in-path, lo que agregará nuevos proyectos en dichos directorios.

Si bien trabajar en proyectos definidos es siempre útil, también se puede querer visualizar los directorios en los que se está trabajando; una excelente herramienta para esto es Treemacs.

Treemacs

Es un paquete que da visualización a los directorios de trabajo, o a proyectos que uno desee agregar directamente, se puede acceder presionando <f9> o invocando M-x treemacs (SPC o p). Inmediatamente se abrirá un buffer de tamaño 35 caracteres por defecto, que permitirá navegar por los directorios o proyectos que la usuaria haya destacado para su configuración, mostrando la jerarquía de los mismos con fuentes vistosas e íconos.

Finalmente, si se llega a necesitar usar la línea de comandos, Emacs posee un emulador de terminal integrado, llamado EShell.

EShell

Emulador de terminal al que se puede acceder con M-x eshell (SPC o e), como los objetivos de estas entradas no son analizar en profundidad el uso de la shell de Emacs, me remito a decir que es versátil para cuando la usuaria quiere ahorrar tiempo trabajando en su proyecto y (en vez de abrir un nuevo programa) mantiene todo su flujo de trabajo en Emacs, pudiendo cambiar rápidamente entre el archivo en que trabaja y la terminal abierta en Emacs.

#doomEmacs #emacs #projectile #distroEmacs #guix

¿Qué es Doom?

Es una configuración dogmática de Emacs (similar a Spacemacs y Centaur) orientada a usuarias de Vim que quieran experimentar en El editor.

La gran diferencia que tiene con las otras dos distribuciones de Emacs es que contiene menos paquetes que Centaur, e implementa un modo de gestión de la configuración bastante interesante cuando se compara con Spacemacs.

Es posible que esta breve introducción no le haga justicia, pero mi firme compromiso es demostrar mediante estos posts el uso habitual de Emacs en el ambiente de un profesor chileno que adscribe a la ética y política que implica la defensa del software libre.

Doom fue desarrollado por Henrik Lissner quien quería usar extensivamente la capa de compatibilidad con Vi (llamada EViL en Emacs por sus siglas en inglés). Como toda configuración, Doom es dogmática respecto de las opiniones y expectativas que tiene su desarrollador, sin embargo, a diferencia de las dos mencionadas con anterioridad Doom tiene la ventaja de contener una cantidad menor de paquetes por defecto y alentar que sea la usuaria quien decida los paquetes a utilizar.

Cabe destacar que esta instalación y el uso de Emacs es en distribuciones GNU/Linux (puntualmente, el sistema Guix que está usando el autor), por lo que no puedo asegurar su funcionamiento en condiciones diferentes.

Instalación rápida

Lo primero que se debe hacer es tener instalado git y clonar el repositorio desde github:

$ git clone https://github.com/hlissner/doom-emacs.git ~/.emacs.d

Luego debemos cambiar la rama objetivo, ya que la rama master está ligeramente atrasada; usaremos la rama develop. Para eso, debemos entrar en la carpeta .emacs.d con:

$ cd .emacs.d

Y luego hacer el seguimiento de la rama:

~/.emacs.d $ git checkout develop

Doom viene con un script de bash que hará más sencilla la instalación, se puede invocar desde la línea de comandos con lo siguiente:

~/.emacs.d $ sh bin/doom quickstart

Comenzará preguntando si se desean instalar los paquetes, así como crear un entorno propio (env); se sugiere permitir la instalación del paquete all-the-icons para que la apariencia de Emacs sea consistente.

Luego de terminada la instalación, si se arranca Emacs se verá un buffer de inicio característico para esta distribución; al margen de esto, la usuaria ya está lista para utilizar Emacs con este conjunto de paquetes seleccionados por hlissner.

¿Qué hacer si no soy un vimmer?

En el caso que la usuaria no esté familiarizada con Vim (o prefiera usar los atajos propios de Emacs), puede cambiar su configuración personal que se encuentra en el directorio .doom.d dentro de home (si se quiere utilizar Doom como punto de partida para su propia distribución de Emacs, este es el directorio que se recomienda modificar, y no .emacs.d).

En el directorio .doom.d se encuentran tres archivos:

• config.el (que contendrá la configuración local de la usuaria)
• init.el (que carga los paquetes al inicio de Emacs)
• packages.el (que contiene las definiciones de paquetes a utilizar por parte de la usuaria)

Para quienes deseen dejar de lado el uso de teclas de Vim, pueden editar (usando Emacs u otro editor) la parte dentro de .init.el que incluye “evil”, ya sea dejándolo como comentario (agregando “;” al inicio de esa línea) o borrando la línea completa (siendo cuidadosa de no alterar el sangrado de las líneas posteriores).

Una vez hecho esto se cierra Emacs y queda repetir el quickstart de la sección anterior o utilizar el script de la siguiente manera:

~.emacs.d $ sh bin/doom update

Lo que hará que se actualicen los paquetes y se omita esta vez la instalación de todos los paquetes que utilizan EViL.

En la próxima entrada se revisará la gestión de proyectos, el uso de Treemacs y de la EShell.

#doomEmacs #emacs #instalacion #distroEmacs #guix

Capítulo 3: ¿Qué hacer desde aquí?

Esta será una pausa a la producción de la presente sección del blog, por dos razones:

• La primera es que los paquetes en Guix son bastante estables, y si ocurre algún accidente, volver a un estado anterior funcional es bastante simple (usando guix package --roll-back en cualquier momento).

• La segunda es que aún no aprendo lo suficiente de Guile o Scheme para hacer experimentos interesantes con este gestor de paquetes o configuraciones (y así seguir con estas entradas de blog).

Sin embargo, con las entradas anteriores quedan como posibles respaldos y fuentes a quien quiera iniciarse con este gestor de paquetes tan interesante (me sigue picando la curiosidad por aprender); al menos, como documentos y evidencia anecdótica en español.

Mi siguiente desafío será aprender bien Guile y algo de Scheme, para intentar domar a la bestia que sería GuixSD (la distribución GNU/Linux-libre). Por mientras cambiaré el enfoque de estas publicaciones semanales a mi nueva afición: doom-emacs, el que pueden encontrar en este enlace.

No contaré esto como una victoria de Guix, sólo estamos en el medio tiempo. El contador, gracias a Emacs-Guix se queda así por ahora:

• Guix : 2
• Herlock : 1
• Emacs : Todo

#gestorDePaquetes #guix #softwareLibre

Capítulo 2: Instalando Emacs-Guix

Me comprometeré con la siguiente idea: Guix es la Emacs de las distros y de los gestores de paquetes. En el sentido de que como Guix usa GNU Guile, un lenguaje de programación que a la vez es un dialecto de Scheme y por consiguiente, de Lisp; lo que en principio sería una mera coincidencia con el dialecto emacs lisp, luego se convierte en un paralelo ingenioso e incluso útil.

Emacs y Guix comparten la capacidad de personalización que brinda Lisp; pero además existe una interfaz de implementación de Emacs propia para Guix (llamada, muy acertadamente Emacs-Guix). Cuando se comienza con Guix, instalando Guile y Emacs-Guix, la gestión de los paquetes en el equipo se vuelve una tarea muchísimo más simple y directa; en realidad, muy similar a trabajar con ELPA y MELPA para quienes acostumbran usar Emacs.

Para tener esta versión en el equipo que tiene instalado Guix basta con hacer:

guix package -i emacs-guix

Lo que resolverá las dependencias y prontamente tendrá funcionando la versión más reciente del paquete (que tiende a estar tan avanzada como la versión estable).

Una vez más todo el honor a Emacs, el entorno perfecto.

El contador quedará así:

• Guix : 2
• Herlock : 1
• Usuarios de Software Libre : 2
• Emacs : Todos los puntos

#gestorDePaquetes #guix #softwareLibre #emacs

Capítulo 1: Resolviendo los problemas de configuración

En el post anterior dejé claro que es muy recomendable leer el manual. Pero acá pondré una recopilación de las posibles soluciones a los problemas enfrentados.

En Trisquel GNU/Linux pareciera que los cambios a los archivos de lenguaje local le “cuestan” a Guix; este fue el primer problema al que me enfrenté luego de mi re-instalación:

guile: warning: failed to install locale

Buscando, encontré varias respuestas y soluciones, incluidas las que sugiere el propio Guix en la terminal:

guix package -i glibc-locales

Y luego exportar las variables

export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

Lo que, en varias distribuciones GNU/Linux podría servir; pero en Trisquel es sólo una solución temporal (hasta que se hace un nuevo guix pull y se queja de nuevo de que falta establecer el local).

Aquí es donde debo sincerarme: Caí como pollo, sólo hacía los export en el momento, no los incluí en mi .bashrc. Cuando los incluí, pues no me volvió a salir la advertencia. Otra victoria para Guix, pero esta vez agradezco el aporte de un usuario de Fedora que hizo esto y me permitió emular su solución.

• Guix : 2
• Herlock : 0.5
• Usuarios de Software Libre : 1

#gestorDePaquetes #guix #softwareLibre

Capítulo 0: Lee el jodido manual

Con el anuncio de la publicación de Guix 1.0 se me metió una idea en la cabeza: Probar este gestor de paquetes.

Me quedo sólo con el gestor debido a que mi labor docente me tiene algo limitado de tiempo y no puedo hacer distro hopping. Leyendo la documentación, me encontré con este paper sobre bioinformática que me compró completamente; y me decidí a la aventura de instalar Guix 1.0 en Trisquel 8 GNU/Linux-libre Flidas.

El script instalador que está disponible en la web es bastante intuitivo y avisa si faltan dependencias en la máquina hospedera, por lo que esa primera parte se descarta fácilmente, es recomendable eso sí estar leyendo el manual durante y después de la instalación para asegurarse de que todo funcione correctamente.

Este es el punto en el que daré énfasis: Leer el manual que está disponible completamente en español y, a pesar de que hace un énfasis bastante marcado en los aspectos técnicos de Guix, es maravillosamente simple de navegar y entender ¿Qué? está haciendo y ¿Por qué? se está haciendo.

Finalmente, el proceso de instalación fue simple, sólo faltó una dependencia que se instaló con el gestor de paquetes apt, pero se me presentó un problema: la generación de los archivos locales de idioma dice que no se puede cambiar. Así que comienzo este blog semanal para reportar todas esas pequeñas dificultades que surjan al momento de instalar guix en una distribución GNU/Linux distinta a GuixSD.

La siguiente entrada versará sobre solucionar el problema de los locales (espero tenerlo solucionado para esa fecha); mientras el contador queda así:

• Herlock : 0
• Manual : 2

#gestorDePaquetes #softwareLibre #registroAnecdotico #guix