Dependencias y entornos: conseguir que el código funcione fuera de tu equipo
El archivo ocupa dos kilobytes. Las instrucciones para hacerlo funcionar incluyen una versión de Python que nadie recuerda, una carpeta del escritorio del autor y un «si no va, llámame». Me impresiona la capacidad de convertir un programa pequeño en una relación de dependencia personal. Antes de añadir una biblioteca BIM podemos resolver algo menos vistoso y bastante más rentable: saber qué ejecuta el archivo y cómo repetir esa ejecución.
Vamos a preparar un ejercicio mínimo en Python, sin Revit, cuenta Autodesk ni paquetes externos. Imprimirá un registro ficticio y mostrará qué intérprete está utilizando. La modestia es deliberada: si esta pieza no arranca, no tendremos que investigar a la vez el modelo, sus permisos y cuatro dependencias. Al acabar quedará una carpeta comprensible, un comando de ejecución y una manera de comprobar qué entorno está trabajando. No hace falta instalar medio catálogo tecnológico para conocer un identificador de puerta.
El editor guarda el texto; alguien tiene que ejecutarlo
Un archivo de código contiene instrucciones escritas. El editor ayuda a verlas, modificarlas y detectar ciertos problemas, pero guardar un archivo no ejecuta su contenido. En el recorrido que vamos a utilizar, Python interpreta el programa. Puedes abrir el mismo archivo con dos editores distintos y ejecutarlo con el mismo intérprete; también puedes tener un editor impecablemente configurado que termine lanzando otro Python diferente del que creías.
La terminal será aquí una forma de expresar la orden de manera explícita. No necesitas convertirte en administrador de sistemas para utilizarla. Sí necesitas reconocer dos cosas: en qué carpeta estás y qué programa estás invocando. Una instrucción como python consulta.py pide ejecutar el archivo consulta.py con el Python que resuelva ese comando en tu entorno. Si has abierto otra carpeta o el nombre apunta a otra instalación, el comportamiento puede cambiar aunque el texto de la instrucción sea idéntico.
Empieza comprobando el intérprete. En una instalación donde el comando sea python, escribe:
python --version
Si utilizas Windows y tienes instalado el lanzador que ofrece el comando py, puedes comprobarlo con py --version. En otros entornos puede haberse configurado python3. No hay que probar nombres hasta encontrar uno que produzca cualquier respuesta y dar el asunto por resuelto: interesa identificar qué instalación has elegido. La documentación oficial de uso de Python en Windows distingue los componentes y sus mecanismos de lanzamiento.
Si el sistema dice que no encuentra el comando, todavía no has descubierto un fallo del artículo ni del futuro script. Falta una instalación utilizable desde esa terminal o la configuración que permita encontrarla. En Windows, un alias también puede conducir a una propuesta de instalación en lugar de al intérprete que esperabas. Resuelve ese paso antes de continuar y vuelve a consultar la versión. Un editor abierto no acredita que Python esté disponible; acredita, con bastante precisión, que hay un editor abierto.
Una carpeta de ejercicio evita las primeras dependencias invisibles
Crea una carpeta nueva llamada consulta-puertas y abre una terminal en ella. Los comandos siguientes utilizan PowerShell en Windows; si tu sistema es otro, conserva la idea y utiliza la sintaxis de rutas que corresponda. Trabajaremos en esta carpeta, no en el directorio de una aplicación real ni dentro de una instalación de Revit.
mkdir consulta-puertas
cd consulta-puertas
Dentro guarda un archivo de texto llamado consulta.py, con este contenido:
import sys
print(sys.executable)
print("P001 | L01")
La primera línea importa un módulo incluido con Python. sys.executable permite consultar la ruta del intérprete en uso y print muestra un valor en la salida. La última instrucción escribe el identificador P001 y el nivel L01 de nuestro ejemplo. No está leyendo un modelo: ese texto forma parte del archivo. Ya habrá tiempo para recuperar datos reales; atribuirle capacidades que todavía no tiene sería una manera muy rápida de avanzar y muy lenta de explicar después.
Ejecuta el archivo con el mismo comando que has comprobado antes:
python consulta.py
La salida debe incluir una ruta al intérprete y, en otra línea, P001 | L01. La ruta concreta dependerá de tu instalación; no tiene que coincidir con una captura del autor. Esa diferencia es información útil. Permite comprobar si la ejecución proviene de donde esperabas en vez de confiar en que el botón del editor haya elegido por ti una configuración razonable.
Si aparece un mensaje indicando que no se puede abrir consulta.py, comprueba el directorio de la terminal y el nombre real del archivo. En Windows también merece la pena comprobar que no se haya guardado como consulta.py.txt. Instalar una biblioteca no corrige ninguna de estas dos situaciones. Es una respuesta ambiciosa a un problema de localización, pero el archivo seguirá estando donde estaba.
El entorno virtual separa las dependencias de cada ejercicio
El ejemplo anterior solo utiliza la biblioteca estándar y podría ejecutarse sin un entorno virtual. Vamos a crearlo de todas formas para reconocer el mecanismo antes de necesitar paquetes de terceros. Un entorno virtual permite mantener un conjunto de paquetes asociado a un proyecto y separado de los de otros entornos. La guía oficial de entornos virtuales explica ese aislamiento y su relación con la instalación desde la que se crea.
Desde consulta-puertas, utilizando el intérprete elegido, ejecuta:
python -m venv .venv
Aquí -m solicita ejecutar el módulo venv, y .venv es el nombre de la carpeta que contendrá el entorno. Ese nombre es una convención cómoda, no una palabra que transforme automáticamente cualquier directorio en un entorno. El Python utilizado para crearlo determina su versión base; el comando no descarga por intuición la versión que necesita tu proyecto.
En Windows puedes ejecutar el intérprete del entorno directamente, sin activar nada:
.\.venv\Scripts\python.exe consulta.py
Ahora la primera línea de salida debería apuntar al intérprete dentro de .venv, y el registro seguirá siendo P001 | L01. Hemos cambiado el entorno de ejecución sin cambiar la información que muestra el programa. En sistemas tipo Unix la ruta habitual será .venv/bin/python; no copies una ruta de Windows esperando que el sistema la traduzca por simpatía.
La activación es otra manera de trabajar: ajusta el entorno de la terminal para que los comandos encuentren primero los ejecutables del entorno virtual. Resulta cómoda, pero no es un requisito para usarlo. Invocar la ruta explícita ayuda a entender qué se está ejecutando y evita convertir una política de ejecución de PowerShell en un obstáculo para este ejercicio. No necesitas debilitar la configuración del sistema para lanzar el intérprete por su ruta.
Un entorno virtual tampoco convierte el programa en una aplicación completamente aislada. El proceso puede seguir leyendo archivos o utilizando la red según el código y los permisos con los que se ejecute. Lo que acabamos de separar es principalmente la instalación de paquetes del ejercicio. Llamarlo «entorno» no le concede las propiedades de una máquina virtual, un contenedor y un sistema de seguridad al mismo tiempo. Las palabras técnicas también agradecen que no les adjudiquemos tres trabajos extra.
Las dependencias deben poder explicarse antes de instalarse
Nuestro programa no necesita paquetes externos. Esa es una situación perfectamente válida y no exige inventar un requirements.txt lleno de herramientas por si acaso. Si una ampliación necesitase una biblioteca, entonces habría que declarar cuál es, qué versión se ha utilizado y cómo instalarla en el entorno del proyecto. La dependencia tiene que responder a una función concreta del programa.
Para comprobar el instalador asociado al entorno, puedes utilizar:
.\.venv\Scripts\python.exe -m pip --version
Esta forma vincula la llamada a pip con el intérprete seleccionado. Es más explícita que ejecutar un pip suelto y dar por supuesto que corresponde al mismo Python. Cuando hay varias instalaciones, una biblioteca puede quedar instalada en una y el programa ejecutarse con otra. El mensaje «ya está instalada» resulta entonces escrupulosamente cierto y completamente inútil para el proceso que la necesita.
Al compartir un proyecto con paquetes externos, un archivo de requisitos puede declarar versiones concretas para reproducir la instalación probada. Un proyecto mayor puede utilizar otros mecanismos de resolución y bloqueo. No necesitamos elegirlos todos ahora. El criterio básico es que otra persona sepa qué instalar y que podamos relacionar esa decisión con una versión del código. Copiar de manera indiscriminada todo lo instalado en el ordenador del autor conserva también dependencias que quizá no tengan nada que ver con la herramienta.
La carpeta .venv se puede recrear y contiene archivos ligados al entorno. No la utilizaría como el recurso descargable principal ni la guardaría como código del proyecto. Compartiría los archivos de la aplicación, sus requisitos cuando existan y las instrucciones para reconstruir el entorno. En el artículo de Git veremos cómo excluir estos archivos generados sin perder las decisiones que sí merecen historial.
La entrega empieza cuando otra persona puede repetirla
Para este ejercicio basta con consulta.py y unas instrucciones que indiquen Python 3, la creación del entorno, el comando de ejecución y la salida que debe reconocerse. Si se ha probado en una versión concreta, se registra esa versión en la documentación de la entrega. Eso describe la evidencia disponible; no demuestra compatibilidad automática con cualquier versión anterior o futura.
Una comprobación útil consiste en copiar únicamente el archivo a otra carpeta, crear allí un entorno nuevo y repetir la ejecución. Si continúa mostrando P001 y L01, sin depender de un archivo de tu escritorio o de un paquete que olvidaste declarar, hemos verificado una propiedad pequeña pero real. Si falla, la nueva carpeta ha cumplido su función: ha mostrado una dependencia que la instalación habitual disimulaba.
Quien prefiera C# seguirá un recorrido distinto: necesitará el SDK de .NET adecuado para crear y compilar un proyecto, y tendrá que reconocer el destino de ejecución elegido. dotnet --list-sdks permite ver los SDK instalados. La guía oficial de introducción a .NET sitúa esas piezas. No hace falta instalar los dos ecosistemas para continuar con los ejemplos Python; los compararemos cuando esa comparación ayude a entender el concepto.
La primera entrega de nuestra consulta no tiene un instalador espectacular. Tiene algo que considero más convincente: una persona puede identificar el programa que ejecuta el archivo, reconstruir su entorno y reconocer el resultado. Cuando el próximo error aparezca al leer una tabla o conectar una API, al menos no tendremos que empezar preguntando qué Python se ha presentado a trabajar. Es una ceremonia de bienvenida que prefiero celebrar una sola vez.
Respuestas