Cómo instalar software desde el código fuente... y eliminarlo después

Resumen:esta guía detallada explica cómo instalar un programa desde el código fuente en Linux y cómo eliminar el software instalado desde el código fuente.

Una de las mayores fortalezas de su distribución de Linux es su administrador de paquetes y el repositorio de software asociado. Con ellos, tienes todas las herramientas y recursos necesarios para descargar e instalar nuevo software en tu computadora de manera completamente automatizada.

Pero a pesar de todos sus esfuerzos, los mantenedores de paquetes no pueden manejar todos y cada uno de los casos de uso. Tampoco pueden empaquetar todo el software disponible. Por lo tanto, todavía hay situaciones en las que tendrá que compilar e instalar software nuevo usted mismo. En cuanto a mí, la razón más común, con diferencia, por la que tengo que compilar algún software es cuando necesito ejecutar una versión muy específica o modificar el código fuente mediante el uso de algunas opciones de compilación sofisticadas.

Si sus necesidades pertenecen a la última categoría, es probable que ya sepa qué hacer. Pero, para la gran mayoría de los usuarios de Linux, compilar e instalar software desde el código fuente por primera vez puede parecer una ceremonia de iniciación:algo aterrador; pero con la promesa de entrar en un nuevo mundo de posibilidades y un lugar de prestigio en una comunidad privilegiada.

[irp posts=”13491″ name=”Cómo instalar y quitar software en Ubuntu”]

A. Instalación de software desde el código fuente en Linux

Y eso es exactamente lo que haremos aquí. A los efectos de este artículo, digamos que necesito instalar NodeJS 8.1.1 en mi sistema. Esa versión exactamente. Una versión que no está disponible en el repositorio de Debian:

sh$ apt-cache madison nodejs | grep amd64
    nodejs | 6.11.1~dfsg-1 | http://deb.debian.org/debian experimental/main amd64 Packages
    nodejs | 4.8.2~dfsg-1 | http://ftp.fr.debian.org/debian stretch/main amd64 Packages
    nodejs | 4.8.2~dfsg-1~bpo8+1 | http://ftp.fr.debian.org/debian jessie-backports/main amd64 Packages
    nodejs | 0.10.29~dfsg-2 | http://ftp.fr.debian.org/debian jessie/main amd64 Packages
    nodejs | 0.10.29~dfsg-1~bpo70+1 | http://ftp.fr.debian.org/debian wheezy-backports/main amd64 Packages

Ahora, instalar NodeJs en Ubuntu o Debian es bastante simple si lo hace con el administrador de paquetes. Pero hagámoslo a través del código fuente.

Paso 1:obtener el código fuente de GitHub

Como muchos proyectos de código abierto, las fuentes de NodeJS se pueden encontrar en GitHub:https://github.com/nodejs/node

Entonces, vayamos directamente allí.

Si no está familiarizado con GitHub, git o cualquier otro sistema de control de versiones, vale la pena mencionar que el repositorio contiene la fuente actual del software, así como un historial de todas las modificaciones realizadas a lo largo de los años. Eventualmente hasta la primera línea escrita para ese proyecto. Para los desarrolladores, mantener ese historial tiene muchas ventajas. Para nosotros hoy, el principal es que podremos obtener las fuentes para el proyecto tal como estaban en cualquier momento dado. Más precisamente, podré obtener las fuentes tal como estaban cuando se lanzó la versión 8.1.1 que quiero. Incluso si hubo muchas modificaciones desde entonces.

En GitHub, puede usar el botón "sucursal" para navegar entre diferentes versiones del software. "Rama" y "etiquetas" son conceptos algo relacionados en Git. Básicamente, los desarrolladores crean "ramas" y "etiquetas" para realizar un seguimiento de los eventos importantes en el historial del proyecto, como cuando comienzan a trabajar en una nueva característica o cuando publican un lanzamiento. No entraré en detalles aquí, todo lo que necesita saber es que estoy buscando la versión etiquetada "v8.1.1"

Después de haber elegido la etiqueta "v8.1.1", la página se actualiza, el cambio más obvio es que la etiqueta ahora aparece como parte de la URL. Además, notará que la fecha de cambio del archivo también es diferente. El árbol de origen que está viendo ahora es el que existía en el momento en que se creó la etiqueta v8.1.1. En cierto sentido, puede pensar en una herramienta de control de versiones como git como una máquina de viajar en el tiempo, que le permite ir y venir en el historial de un proyecto.

En este punto, podemos descargar las fuentes de NodeJS 8.1.1. No te puedes perder el gran botón azul que sugiere descargar el archivo ZIP del proyecto. En cuanto a mí, descargaré y extraeré el ZIP de la línea de comando por el bien de la explicación. Pero si prefiere usar una herramienta GUI, no dude en hacerlo:

wget https://github.com/nodejs/node/archive/v8.1.1.zip
unzip v8.1.1.zip
cd node-8.1.1/

La descarga del archivo ZIP funciona muy bien. Pero si quieres hacerlo "como un profesional", te sugiero usar directamente git herramienta para descargar las fuentes. No es complicado en absoluto, y será un buen primer contacto con una herramienta que encontrará a menudo:

# first ensure git is installed on your system
sh$ sudo apt-get install git
# Make a shallow clone the NodeJS repository at v8.1.1
sh$ git clone --depth 1 \
              --branch v8.1.1 \
              https://github.com/nodejs/node
sh$ cd node/

Por cierto, si tiene algún problema, considere la primera parte de este artículo como una introducción general. Más adelante tengo explicaciones más detalladas para las distribuciones basadas en Debian y RedHat para ayudarlo a solucionar problemas comunes.

De todos modos, cada vez que descargaste la fuente usando git o como un archivo ZIP, ahora debería tener exactamente los mismos archivos de origen en el directorio actual:

sh$ ls
android-configure  BUILDING.md            common.gypi      doc            Makefile   src
AUTHORS            CHANGELOG.md           configure        GOVERNANCE.md  node.gyp   test
benchmark          CODE_OF_CONDUCT.md     CONTRIBUTING.md  lib            node.gypi  tools
BSDmakefile        COLLABORATOR_GUIDE.md  deps             LICENSE        README.md  vcbuild.bat

Paso 2:comprensión del sistema de compilación del programa

Por lo general, hablamos de "compilar las fuentes", pero la compilación es solo una de las fases necesarias para producir un software que funcione a partir de su fuente. Un sistema de compilación es un conjunto de herramientas y prácticas que se utilizan para automatizar y articular esas diferentes tareas a fin de compilar completamente el software con solo emitir unos pocos comandos.

Si el concepto es simple, la realidad es algo más complicada. Porque diferentes proyectos o lenguajes de programación pueden tener diferentes requisitos. O por los gustos del programador. O las plataformas compatibles. O por razones históricas. O... o... hay una lista casi interminable de razones para elegir o crear otro sistema de compilación. Todo eso para decir que hay muchas soluciones diferentes que se utilizan por ahí.

NodeJS utiliza un sistema de compilación de estilo GNU, es una opción popular en la comunidad de código abierto y, una vez más, es una buena manera de comenzar su viaje.

Escribir y ajustar un sistema de compilación es una tarea bastante compleja, pero para el "usuario final", los sistemas de compilación estilo GNU facilitan la tarea mediante el uso de dos herramientas:configure y make .

El configure El archivo es una secuencia de comandos específica del proyecto que verificará la configuración del sistema de destino y la función disponible para garantizar que el proyecto se pueda construir y, finalmente, se ocupe de las especificidades de la plataforma actual.

Una parte importante de una típica configure el trabajo es construir el Makefile . Ese es el archivo que contiene las instrucciones requeridas para construir efectivamente el proyecto.

El make La herramienta, por otro lado, es una herramienta POSIX disponible en cualquier sistema similar a Unix. Leerá el Makefile específico del proyecto y realice las operaciones requeridas para compilar e instalar su programa.

Pero, como siempre en el mundo de Linux, todavía tiene cierta indulgencia para personalizar la compilación según sus necesidades específicas.

./configure --help

El configure -help El comando le mostrará todas las opciones de configuración disponibles. Una vez más, esto es muy específico del proyecto. Y para ser honesto, a veces es necesario profundizar en el proyecto antes de comprender completamente el significado de todas y cada una de las opciones de configuración.

Pero hay al menos una opción estándar de GNU Autotools que debe conocer:el --prefix opción. Esto tiene que ver con la jerarquía del sistema de archivos y el lugar donde se instalará su software.

[irp posts=”14419″ name=”8 consejos y trucos de Vim que lo convertirán en un usuario profesional”]

Paso 3:El FHS

La jerarquía del sistema de archivos de Linux en una distribución típica cumple principalmente con el Estándar de jerarquía del sistema de archivos (FHS)

Ese estándar explica el propósito de los distintos directorios de su sistema:/usr , /tmp , /var y así sucesivamente.

Cuando use GNU Autotools, y la mayoría de los otros sistemas de compilación, la ubicación de instalación predeterminada para su nuevo software será /usr/local . ¿Cuál es una buena opción según la FSH “La jerarquía /usr/local es para uso del administrador del sistema al instalar el software localmente? Debe estar a salvo de que se sobrescriba cuando se actualice el software del sistema. Puede usarse para programas y datos que se pueden compartir entre un grupo de hosts, pero que no se encuentran en /usr”.

El /usr/local La jerarquía de alguna manera replica el directorio raíz, y encontrará allí /usr/local/bin para los programas ejecutables, /usr/local/lib para las bibliotecas, /usr/local/share para archivos independientes de la arquitectura, etc.

El único problema al usar /usr/local El árbol para la instalación de software personalizado es que los archivos de todo su software se mezclarán allí. Especialmente, después de haber instalado un par de software, será difícil rastrear a qué archivo exactamente de /usr/local/bin y /usr/local/lib a qué software pertenece. Sin embargo, eso no causará ningún problema en el sistema. Después de todo, /usr/bin es casi el mismo lío. Pero eso se convertirá en un problema el día que desee eliminar un software instalado manualmente.

Para resolver ese problema, normalmente prefiero instalar un software personalizado en /opt sub-árbol en su lugar. Una vez más, para citar a la FHS:

_”/opt está reservado para la instalación de paquetes de software de aplicación complementarios.

Un paquete que se va a instalar en /opt debe ubicar sus archivos estáticos en un árbol de directorio /opt/ o /opt/ separado, donde es un nombre que describe el paquete de software y es el nombre registrado LANANA del proveedor.”_

Entonces crearemos un subdirectorio de /opt específicamente para nuestra instalación personalizada de NodeJS. Y si algún día quiero eliminar ese software, simplemente tendré que eliminar ese directorio:

sh$ sudo mkdir /opt/node-v8.1.1
sh$ sudo ln -sT node-v8.1.1 /opt/node
# What is the purpose of the symbolic link above?
# Read the article till the end--then try to answer that
# question in the comment section!

sh$ ./configure --prefix=/opt/node-v8.1.1
sh$ make -j9 && echo ok
# -j9 means run up to 9 parallel tasks to build the software.
# As a rule of thumb, use -j(N+1) where N is the number of cores
# of your system. That will maximize the CPU usage (one task per
# CPU thread/core + a provision of one extra task when a process
# is blocked by an I/O operation.

Cualquier cosa menos "ok" después de make el comando se ha completado significaría que hubo un error durante el proceso de compilación. Como ejecutamos una compilación paralela debido a -j opción, no siempre es fácil recuperar el mensaje de error dado el gran volumen de salida producido por el sistema de compilación.

En el caso de un problema, simplemente reinicie make , pero sin -j opción esta vez. Y el error debería aparecer cerca del final de la salida:

sh$ make

Finalmente, una vez que la compilación haya llegado al final, puede instalar su software en su ubicación ejecutando el comando:

sh$ sudo make install

Y pruébalo:

sh$ /opt/node/bin/node --version
v8.1.1

B. ¿Qué pasa si algo sale mal durante la instalación desde el código fuente?

Lo que expliqué anteriormente es principalmente lo que puede ver en la página de "instrucciones de construcción" de un proyecto bien documentado. Pero dado que el objetivo de este artículo es permitirle compilar su primer software a partir de fuentes, podría valer la pena tomarse el tiempo para investigar algunos problemas comunes. Entonces, haré todo el procedimiento nuevamente, pero esta vez desde un sistema Debian 9.0 y CentOS 7.0 nuevo y mínimo para que pueda ver los errores que encontré y cómo los resolví.

De Debian 9.0 “Estiramiento”

[email protected]:~$ git clone --depth 1 \
                             --branch v8.1.1 \
                             https://github.com/nodejs/node
-bash: git: command not found

Este problema es bastante fácil de diagnosticar y resolver. Solo instala el git paquete:

[email protected]:~$ sudo apt-get install git

[email protected]:~$ git clone --depth 1 \
                             --branch v8.1.1 \
                             https://github.com/nodejs/node && echo ok
[...]
ok

[email protected]:~/node$ sudo mkdir /opt/node-v8.1.1
[email protected]:~/node$ sudo ln -sT node-v8.1.1 /opt/node

Aquí no hay problema.

[email protected]:~/node$ ./configure --prefix=/opt/node-v8.1.1/
WARNING: failed to autodetect C++ compiler version (CXX=g++)
WARNING: failed to autodetect C compiler version (CC=gcc)
Node.js configure error: No acceptable C compiler found!
        Please make sure you have a C compiler installed on your system and/or
        consider adjusting the CC environment variable if you installed
        it in a non-standard prefix.

Obviamente, para compilar un proyecto, necesita un compilador. NodeJS está escrito usando el lenguaje C++, necesitamos un compilador de C++. Aquí instalaré `g++`, el compilador GNU C++ para ese propósito:

[email protected]:~/node$ sudo apt-get install g++
[email protected]:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok

[email protected]:~/node$ make -j9 && echo ok
-bash: make: command not found

Otra herramienta perdida. Mismos síntomas. Misma solución:

[email protected]:~/node$ sudo apt-get install make
[email protected]:~/node$ make -j9 && echo ok
[...]
ok

[email protected]:~/node$ sudo make install
[...]
[email protected]:~/node$ /opt/node/bin/node --version
v8.1.1

¡Éxito!

Tenga en cuenta:he instalado las diversas herramientas una por una para mostrar cómo diagnosticar los problemas de compilación y mostrarle la solución típica para resolver esos problemas. Pero si busca más información sobre el tema o lee otros tutoriales, descubrirá que la mayoría de las distribuciones tienen “meta-paquetes” que actúan como un paraguas para instalar algunas o todas las herramientas típicas que se usan para compilar un software. En los sistemas basados ​​en Debian, probablemente encontrará el paquete build-essentials para ese propósito. Y en las distribuciones basadas en Red-Hat, serán las “Herramientas de desarrollo” grupo.

Desde CentOS 7.0

[[email protected] ~]$ git clone --depth 1 \
                               --branch v8.1.1 \
                               https://github.com/nodejs/node
-bash: git: command not found

¿Comando no encontrado? Simplemente instálelo usando el yum administrador de paquetes:

[[email protected] ~]$ sudo yum install git

[[email protected] ~]$ git clone --depth 1 \
                               --branch v8.1.1 \
                               https://github.com/nodejs/node && echo ok
[...]
ok

[[email protected] ~]$ sudo mkdir /opt/node-v8.1.1
[[email protected] ~]$ sudo ln -sT node-v8.1.1 /opt/node

[[email protected] ~]$ cd node
[[email protected] node]$ ./configure --prefix=/opt/node-v8.1.1/
WARNING: failed to autodetect C++ compiler version (CXX=g++)
WARNING: failed to autodetect C compiler version (CC=gcc)
Node.js configure error: No acceptable C compiler found!

        Please make sure you have a C compiler installed on your system and/or
        consider adjusting the CC environment variable if you installed
        it in a non-standard prefix.

Lo adivinas:NodeJS está escrito usando el lenguaje C++, pero mi sistema carece del compilador correspondiente. Mmm al rescate. Como no soy un usuario habitual de CentOS, tuve que buscar en Internet el nombre exacto del paquete que contiene el compilador g++. Llevándome a esa página:https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

[[email protected] node]$ sudo yum install gcc-c++
[[email protected] node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok

[[email protected] node]$ make -j9 && echo ok
[...]
ok

[[email protected] node]$ sudo make install && echo ok
[...]
ok

[[email protected] node]$ /opt/node/bin/node --version
v8.1.1

Éxito. De nuevo.

C. Realizar cambios en el software instalado desde el código fuente

Puede instalar software desde la fuente porque necesita una versión muy específica que no está disponible en su repositorio de distribución, o porque desea modificar el programa para corregir un error o agregar una función. Después de todo, el código abierto se trata de hacer modificaciones. Por lo tanto, aprovecharé esta oportunidad para darle una idea del poder que tiene a mano ahora que puede compilar su propio software.

Aquí, haremos un cambio menor en las fuentes de NodeJS. Y veremos si nuestro cambio se incorporará a la versión compilada del software:

Abra el archivo node/src/node.cc en tu editor de texto favorito (vim, nano, gedit,…). E intenta localizar ese fragmento de código:

   if (debug_options.ParseOption(argv[0], arg)) {
      // Done, consumed by DebugOptions::ParseOption().
    } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) {
      printf("%s\n", NODE_VERSION);
      exit(0);
    } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) {
      PrintHelp();
      exit(0);
    }

Está alrededor de la línea 3830 del archivo. Luego modifique la línea que contiene printf para que coincida con ese en su lugar:

      printf("%s (compiled by myself)\n", NODE_VERSION);

Luego regresa a tu terminal. Antes de continuar, y para darle una idea más clara del poder detrás de git, puede verificar si modificó el archivo correcto:

diff --git a/src/node.cc b/src/node.cc
index bbce1022..a5618b57 100644
--- a/src/node.cc
+++ b/src/node.cc
@@ -3828,7 +3828,7 @@ static void ParseArgs(int* argc,
     if (debug_options.ParseOption(argv[0], arg)) {
       // Done, consumed by DebugOptions::ParseOption().
     } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) {
-      printf("%s\n", NODE_VERSION);
+      printf("%s (compiled by myself)\n", NODE_VERSION);
       exit(0);
     } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) {
       PrintHelp();

Debería ver un "-" (signo menos) antes de la línea tal como estaba antes de cambiarla. Y un "+" (signo más) antes de la línea después de los cambios.

Ahora es el momento de volver a compilar y reinstalar su software:

make -j9 && sudo make install && echo ok
[...]
ok

Esta vez, la única razón por la que podría fallar es que cometió un error tipográfico al cambiar el código. Si este es el caso, vuelva a abrir el node/src/node.cc archivo en su editor de texto y corrija el error.

Una vez que haya logrado compilar e instalar esa nueva versión modificada de NodeJS, podrá verificar si sus modificaciones se incorporaron realmente al software:

[email protected]:~/node$ /opt/node/bin/node --version
v8.1.1 (compiled by myself)

¡Felicidades! ¡Has hecho tu primer cambio a un programa de código abierto!

D. Deje que el shell localice nuestro software de compilación personalizado

Es posible que haya notado que siempre inicié mi software NodeJS recién compilado especificando la ruta absoluta al archivo binario.

/opt/node/bin/node

Funciona. Pero esto es molesto, por decir lo menos. En realidad, hay dos formas comunes de arreglar eso.

En realidad, hay dos formas comunes de solucionar el molesto problema de especificar la ruta absoluta a los archivos binarios:
pero para comprenderlos primero debe saber que su shell localiza los archivos ejecutables buscándolos solo en los directorios especificados por la variable de entorno PATH.

[email protected]:~/node$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Aquí, en ese sistema Debian, si no especifica explícitamente ningún directorio como parte del nombre de un comando, el shell primero buscará los programas ejecutables en /usr/local/bin , entonces si no se encuentra en /usr/bin , entonces si no se encuentra en /bin luego, si no se encuentra en /usr/local/games luego, si no se encuentra en /usr/games , entonces, si no se encuentra... el shell informará un error “comando no encontrado” .

Dado eso, tenemos dos formas de hacer que un comando sea accesible para el shell:agregándolo a uno de los PATH ya configurados directorios. O agregando el directorio que contiene nuestro archivo ejecutable al PATH .

Agregar un enlace desde /usr/local/bin

Solo copiando el ejecutable binario del nodo de /opt/node/bin a /usr/local/bin sería una mala idea ya que al hacerlo, el programa ejecutable ya no podría ubicar los otros componentes requeridos pertenecientes a /opt/node/ (Es una práctica común que el software ubique sus archivos de recursos en relación con su propia ubicación).

Entonces, la forma tradicional de hacerlo es usando un enlace simbólico:

[email protected]:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node
[email protected]:~/node$ which -a node || echo not found
/usr/local/bin/node
[email protected]:~/node$ node --version
v8.1.1 (compiled by myself)

Esta es una solución simple y efectiva, especialmente si un paquete de software está hecho de solo unos pocos programas ejecutables conocidos, ya que debe crear un enlace simbólico para todos y cada uno de los comandos invocables por el usuario. Por ejemplo, si está familiarizado con NodeJS, conoce el npm aplicación complementaria debo enlazar desde /usr/local/bin también. Pero te lo dejo como ejercicio.

Modificando la RUTA

Primero, si probó la solución anterior, elimine el enlace simbólico del nodo creado anteriormente para comenzar desde un estado claro:

[email protected]:~/node$ sudo rm /usr/local/bin/node
[email protected]:~/node$ which -a node || echo not found
not found

Y ahora, aquí está el comando mágico para cambiar tu PATH :

[email protected]:~/node$ export PATH="/opt/node/bin:${PATH}"
[email protected]:~/node$ echo $PATH
/opt/node/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Simplemente dicho, reemplacé el contenido de PATH variable de entorno por su contenido anterior, pero con el prefijo /opt/node/bin . Entonces, como puede imaginarlo ahora, el shell buscará primero en el /opt/node/bin Directorio de programas ejecutables. Podemos confirmar que usando el which comando:

[email protected]:~/node$ which -a node || echo not found
/opt/node/bin/node
[email protected]:~/node$ node --version
v8.1.1 (compiled by myself)

Mientras que la solución de "enlace" es permanente tan pronto como haya creado el enlace simbólico en /usr/local/bin , la PATH el cambio es efectivo solo en el shell actual. Te dejaré investigar un poco sobre cómo hacer cambios en el PATH permanentes Como pista, tiene que ver con tu “perfil”. Si encuentra la solución, no dude en compartirla con los demás lectores utilizando la sección de comentarios a continuación.

E. Cómo eliminar ese software recién instalado del código fuente

Dado que nuestro software NodeJS compilado personalizado se encuentra completamente en /opt/node-v8.1.1 directorio, eliminar ese software no requiere más esfuerzo que usar el comando rm para eliminar ese directorio:

sudo rm -rf /opt/node-v8.1.1

CUIDADO: sudo y rm -rf ¡son un cóctel peligroso! Siempre verifique su comando dos veces antes de presionar la tecla "enter". No tendrá ningún mensaje de confirmación ni recuperación si elimina el directorio incorrecto...

Luego, si ha modificado su PATH , tendrás que revertir esos cambios, lo cual no es nada complicado.

Y si ha creado enlaces desde /usr/local/bin tendrás que eliminarlos todos:

[email protected]:~/node$ sudo find /usr/local/bin \
                                 -type l \
                                 -ilname "/opt/node/*" \
                                 -print -delete
/usr/local/bin/node

¿Esperar? ¿Dónde estaba el Infierno de la Dependencia?

Como comentario final, si lee acerca de cómo compilar su propio software personalizado, es posible que haya oído hablar del infierno de las dependencias. Este es un apodo para esa molesta situación en la que antes de poder compilar con éxito un software, primero debe compilar una biblioteca de requisitos previos, que a su vez requiere otra biblioteca que a su vez podría ser incompatible con algún otro software que ya haya creado. instalado.

Parte del trabajo de los mantenedores de paquetes de su distribución es resolver realmente ese infierno de dependencias y asegurarse de que los distintos programas de su sistema utilicen bibliotecas compatibles y se instalen en el orden correcto.

Para este artículo, elegí, a propósito, instalar NodeJS, ya que prácticamente no tiene dependencias. Dije "virtualmente" porque, de hecho, tiene dependencias Pero el código fuente de esas dependencias está presente en el repositorio fuente del proyecto (en el node/deps subdirectorio), por lo que no tiene que descargarlos e instalarlos manualmente de antemano.

Pero si está interesado en comprender más acerca de ese problema y aprender a lidiar con él, hágamelo saber usando la sección de comentarios a continuación:¡ese sería un gran tema para un artículo más avanzado!