Identifica las dependencias de cualquier script: guía completa 2025

Controla las bibliotecas y módulos que necesita tu código para ejecutarse sin errores.

Por HolaGPT Editorial · 10 min lectura · 2026-07-26

Pones un script a correr en un servidor nuevo y truena. No encuentra un módulo. Después otro. La mitad del fin de semana depurando imports, versiones y paquetes fantasma. El problema no es el código: son sus dependencias.

Identificar dependencias debería ser mecánico y estar documentado desde el minuto uno, pero la realidad es distinta. Muchos proyectos heredados carecen de listados explícitos; otros mezclan entornos globales con requisitos implícitos que fallan al cambiar de máquina. Esta guía te da los métodos exactos, por lenguaje y por contexto, para dominar esa deuda técnica antes de que te estalle en producción.

Qué son exactamente las dependencias en un script

Una dependencia es cualquier fragmento de código externo que tu script necesita para ejecutarse. Puede ser una biblioteca de terceros, un módulo de la biblioteca estándar que no está disponible por defecto en ciertos entornos, un binario del sistema (como ffmpeg o wkhtmltopdf) o incluso otro script local cuya ruta asumes correcta. El término se usa sobre todo para paquetes instalados via gestores: pip, npm, composer, cargo, etc.

El problema se agrava cuando hay dependencias transitivas: paquetes que necesita el paquete que usas. En Node.js, esa cadena puede superar los mil módulos. En Python, un simple requests arrastra certifi, charset-normalizer, idna y urllib3. Si no los identificas todos, tendrás instalaciones inconsistentes.

Por qué debes identificar las dependencias de forma explícita

Traslado de entornos: desarrollar en local y desplegar en un contenedor o en un VPS exige reproducir exactamente el mismo árbol de dependencias. Sin un listado explícito, confías en tu memoria o en el «a mí sí me funciona».

Control de versiones: muchas roturas se dan porque la versión 2.0 de una librería rompe la API. Identificar congelando versiones exactas o rangos semánticos evita sorpresas. El clásico pip freeze guarda todo; pip-tools te permite separar dependencias directas de las transitivas.

Auditoría de seguridad: los listados explícitos se pueden escanear con herramientas como safety, npm audit o bundler-audit. Sin ese archivo, un equipo de seguridad no puede revisar vulnerabilidades automáticamente.

Rendimiento y tamaño del paquete: instalar «por si acaso» librerías que el script no usa hincha imágenes Docker y ralentiza despliegues. Identificar solo las reales acelera CI/CD y reduce la superficie de ataque.

Métodos directos para scripts en Python

pip freeze y requirements.txt

El comando clásico vuelca todo lo instalado en el entorno activo:
pip freeze > requirements.txt
Esto incluye dependencias directas y transitivas. Suficiente para replicar el entorno, pero ruidoso: no sabes cuáles son realmente necesarias para tu script. Úsalo como captura temporal.

pipdeptree y pip-tools

pipdeptree muestra un árbol ASCII de dependencias y marca las que están sueltas o en conflicto. Instálalo y ejecuta:
pipdeptree
Con pip-compile de pip-tools, mantienes un archivo requirements.in con tus dependencias directas y generas un requirements.txt bloqueado con hashes. Así identificas exactamente qué necesitas y qué traen consigo.

Análisis estático del script

Si solo tienes un archivo .py suelto sin entorno documentado, puedes extraer las importaciones con ast o herramientas como pigar:
pigar -p script.py
Generará un requirements.txt basado únicamente en los imports que encuentra, contrastando con los paquetes disponibles en PyPI. No es perfecto, pero sirve como punto de partida. Otra opción es pipreqs.

Para scripts que llaman __import__ dinámicamente o evalúan cadenas, el análisis estático falla. Ahí necesitas ejecutar el script en un entorno aislado y monitorizar las importaciones.

Monitorización en tiempo de ejecución

El módulo importlab (de Google) y extensiones como modulefinder pueden rastrear qué módulos se cargan durante la ejecución. Es más preciso pero requiere cobertura completa del código. Una opción casera: ejecutar con python -v script.py 2>&1 | grep 'import ' para ver todos los módulos que intenta cargar, aunque genera mucho ruido.

Identificar dependencias en proyectos JavaScript / Node.js

En el ecosistema npm, el archivo package.json dicta las dependencias directas, pero no las versiones exactas bloqueadas. Ese papel lo cumple package-lock.json (npm) o yarn.lock. Ambos capturan el árbol completo con versiones y hashes.

Para identificar si un script suelto tiene dependencias ocultas, revisa los require o import en el código. Herramientas como dependency-cruiser dibujan un grafo y alertan sobre módulos no declarados en package.json. Ejecuta:
depcruise --config .dependency-cruiser.js src
El comando npx check-dependency-updates también revisa si lo instalado difiere de lo declarado.

Si heredaste un proyecto sin package.json, puedes generar uno base con npm init -y y luego ir añadiendo paquetes a medida que el análisis de require los detecte. Un script en Node.js puede recorrer todos los archivos con detective o precinct para listar los módulos usados:

const precinct = require('precinct');
const deps = precinct.paperwork('script.js');
console.log(deps);

Así obtienes un array de strings con las dependencias tal cual están declaradas en el código. Luego puedes contrastarlo con lo que existe en npm.

Scripts en Bash y dependencias de sistema

Un script .sh suele llamar a comandos externos como jq, curl, ffmpeg o docker. Identificar esas dependencias exige revisar cada línea en busca de binarios. Un truco: usar command -v para verificar disponibilidad al inicio del script y abortar con mensajes claros. Para automatizarlo, herramientas como shellcheck pueden señalar dependencias externas no verificadas.

Otra opción es parsear el script con grep -oE '^([a-zA-Z0-9_\-]+)' para extraer posibles comandos y contrastarlos con el PATH. No es infalible, pero ayuda con scripts largos heredados. Documenta estas dependencias en un Dockerfile o en un README con los comandos de instalación (apt install, brew, etc.).

Lenguajes compilados: Go, Rust y C/C++

En Go, el archivo go.mod y go.sum contienen las dependencias declaradas y sus hashes. El comando go mod tidy limpia cualquier dependencia no usada y añade las faltantes. Si tienes un script suelto, lo compilas con go build y Go resolverá automáticamente las dependencias listándolas en go.mod si está inicializado.

En Rust, cargo tree muestra el árbol completo de dependencias. Cargo.toml define las directas y Cargo.lock las bloquea. Para identificar dependencias no usadas, usa cargo-udeps.

En C/C++, el infierno de dependencias es artesanal. El análisis de cabeceras #include con herramientas como include-what-you-use ayuda a mapear dependencias reales y eliminar las superfluas. Para encontrar las bibliotecas enlazadas, puedes usar ldd sobre el binario compilado.

Herramientas automáticas de identificación para cualquier lenguaje

Los escáneres de composición de software (SCA) como Snyk, OWASP Dependency-Check o FOSSA analizan archivos de manifiesto y código fuente para generar una lista completa de dependencias, incluyendo vulnerabilidades. No siempre funcionan en scripts huérfanos, pero para proyectos con gestores estándar son la opción más robusta.

Plataformas como HolaGPT pueden acelerar este proceso: subes un fragmento de código o el script completo y la IA lo analiza, extrayendo imports, llamadas a módulos y sugerencias del ecosistema correcto. Aunque no sustituye a un gestor de paquetes, te da un punto de partida inmediato, especialmente cuando trabajas con lenguajes o frameworks que no dominas del todo. Puedes pedirle, por ejemplo: «Identifica todas las dependencias externas de este script Python y sugiere el comando pip para instalarlas». La respuesta incluye un listado listo para copiar.

Buenas prácticas para que la identificación no sea un problema

1. Mantén un manifiesto único por proyecto. requirements.txt, package.json, pyproject.toml… el archivo que corresponda según el ecosistema. Nada de listas perdidas en wikis.
2. Congela versiones exactas en entornos productivos. El manifiesto puede tener rangos flexibles, pero el lockfile debe ser exacto. Commit a ambos.
3. Automatiza la verificación en CI. Un step que ejecute pip check, npm ls o depcruise detecta inconsistencias antes del deploy.
4. Usa entornos virtuales o contenedores. Aísla las dependencias de cada proyecto para que el análisis de uno no contamine al otro. Con Docker, el mismo Dockerfile sirve como documentación ejecutable de las dependencias del sistema.
5. Documenta las dependencias del sistema operativo. Si tu script necesita ffmpeg, agrégalo explícitamente en un Dockerfile o en un Brewfile.
6. Audita periódicamente. Una dependencia que hoy es segura puede tener una vulnerabilidad mañana. Programa escaneos semanales con pip-audit, npm audit o similares.

Cuando el script no tiene dependencias declaradas: plan de rescate

Te encuentras con un script.py en un repositorio muerto. Sin requirements.txt, sin setup.py, sin documentación. Sigue este protocolo:

1. Ejecuta el script en un entorno virtual vacío y anota cada ModuleNotFoundError.
2. Con esos nombres, busca el paquete correcto en PyPI (a veces el módulo no coincide con el nombre del paquete, como lxml vs. lxml o MySQLdb que viene de mysqlclient).
3. Si el script usa import dinámicos, recurre a la técnica de ejecución con -v o a un decorador que registre cada import.
4. Genera un requirements.txt mínimo con las versiones que funcionen y ve ampliándolo hasta que el script corra sin errores en todos los flujos.
5. Comenta cada dependencia: por qué se necesita y qué versión fue probada. Eso le salva la vida al próximo desarrollador.

En Node.js, un proceso similar con npm install a ciegas y luego npm ls para ver qué se instaló realmente. En Bash, ejecutar con set -x para ver cada comando y luego mapear los binarios a paquetes del sistema.

Errores comunes al identificar dependencias y cómo evitarlos

Confiar en el entorno global. Si identificas dependencias ejecutando pip list en tu máquina de desarrollo, obtendrás decenas de paquetes que el script no usa. Siempre hazlo en un entorno limpio, recién creado.

Ignorar dependencias transitivas críticas. Algunas bibliotecas exponen una API que funciona incluso si falta una dependencia opcional, pero truena con ciertos parámetros. Especifica las extras en el manifiesto: pip install 'library[extra]'.

Usar rangos de versión demasiado amplios. package>=1.0 puede traer la versión 5.0 con cambios incompatibles. Define al menos el minor: package~=1.2 en Python o ^1.2.3 en npm.

Olvidar las dependencias de compilación. Muchos paquetes Python requieren compiladores C, librerías de desarrollo como python3-dev o libpq-dev. Sin ellas, pip install falla con errores crípticos. Docalas en un Dockerfile o en instrucciones de instalación.

Integración con flujos modernos y IA

Los flujos de trabajo modernos integran la identificación de dependencias desde el inicio. Con pre-commit, por ejemplo, puedes añadir un hook que revise que todo import esté declarado. En monorepos, herramientas como Bazel o Pants fuerzan la declaración explícita de dependencias entre módulos, lo que elimina ambigüedades.

La inteligencia artificial añade una capa de interpretación: cuando el código es complejo o usa metaprogramación, plataformas como HolaGPT pueden examinar el contexto y sugerir no solo los paquetes, sino también las dependencias del sistema y las variables de entorno necesarias. Por ejemplo, ante un script que llama a subprocess.run(['ffmpeg', ...]), la IA indica que ffmpeg debe estar en el PATH y la versión mínima recomendada. Este nivel de detalle acelera la puesta a punto, sobre todo en equipos donde el conocimiento está distribuido.

Identificación de dependencias en scripts que mezclan lenguajes

Es frecuente encontrar proyectos que usan un script Python para invocar comandos Node.js o un shell script que orquesta contenedores. La identificación se vuelve multinivel: dependencias del lenguaje principal, binarios de sistema y dependencias de los lenguajes invocados. La solución pasa por tratar cada capa como un miniproyecto separado con su propio manifiesto. Una estructura así:

proyecto/
  script_orquestador.py
  requirements.txt
  node_modules/
    package.json
  utilidades/
    Dockerfile

Documenta en el README el orden de instalación: primero crear entorno Python, luego instalar dependencias del sistema, luego npm install, etc. De nuevo, un Dockerfile multi-etapa es la ejecución viviente de esa identificación.

El valor de una identificación precisa en equipos distribuidos

Cuando el conocimiento sobre lo que necesita un script para correr reside solo en la cabeza de una persona, cualquier baja o rotación puede paralizar un despliegue. Una lista de dependencias completa y verificable, acompañada de instrucciones claras, convierte ese conocimiento tácito en explícito. En términos de DevOps, es el equivalente a tener un «runbook» automatizado. Invertir una hora en documentar dependencias ahorra decenas de horas de debugging futuro.

Además, la identificación temprana de dependencias ayuda a evaluar el coste de adopción de una herramienta: si un script necesita 50 paquetes con licencias restrictivas, quizás conviene buscar una alternativa. Sin esa visibilidad, la decisión se toma a ciegas.