DevMan para Visual Studio Code

Elige las versiones de desarrollo de cada proyecto y abre su terminal sin salir de VS Code.

Requisitos

• Visual Studio Code 1.96 o posterior, versión de escritorio.
• Instala el VSIX 0.5.0 correspondiente al sistema y arquitectura del host: Windows, Linux o macOS, x64 o ARM64.
• Una carpeta de trabajo de confianza. En SSH, WSL o contenedores, instala la extensión correspondiente al host remoto.

El VSIX incluye DevMan CLI 1.3.0 y su motor .NET autocontenido. No necesitas instalar DevMan Desktop, una CLI separada ni .NET. Al activarse verifica SHA-256 y prepara el motor en el almacenamiento privado del usuario de VS Code. Esta preparación funciona sin conexión ni elevación de permisos. Los runtimes que quieras descargar sí necesitan conexión y conservan sus propios requisitos.

El motor se actualiza con la extensión; no se modifica una CLI instalada por separado. Comparte el inventario y la configuración de ~/.devman con DevMan Desktop. Los runtimes y paquetes conservan las ubicaciones elegidas en DevMan. El motor privado está bajo globalStorage/gbvaldez.devman/cli del host de VS Code. Las versiones anteriores permanecen allí para no reemplazar ejecutables abiertos.

Instalar

1. Abre Extensiones en VS Code (Ctrl+Shift+X).
2. En el menú …, elige Instalar desde VSIX… y selecciona tu paquete, por ejemplo devman-0.5.0-win32-x64.vsix.
3. Abre el panel DevMan de la barra lateral.
4. El motor se prepara automáticamente. Si falla, abre Salida → DevMan y ejecuta DevMan: Actualizar para reintentar. Opcionalmente puedes elegir una CLI 1.3.0 o posterior mediante DevMan: Seleccionar ejecutable de DevMan.

También puedes usar code --install-extension devman-0.5.0-win32-x64.vsix. Después de actualizar, recarga la ventana y abre terminales nuevas.

Agregar un runtime que ya tienes

Ejecuta DevMan: Agregar runtime existente, elige Java, Python, Node.js, .NET, Go, Maven, Gradle, PHP o Ruby, selecciona su carpeta y escribe un alias único, por ejemplo oracle-21, python-empresa o dotnet-trabajo.

La instalación aparece como Externo. Puedes usarla en un proyecto (se guarda el alias en .devman.json) o activarla globalmente para tu usuario. Al quitar su registro, sus archivos se conservan. Registrar no activa globalmente ni cambia las variables del usuario; activar globalmente sí actualiza los accesos y variables correspondientes.

Se valida que existan los ejecutables necesarios; en Unix también sus permisos de ejecución. No se ejecuta el binario durante el registro ni se comprueba automáticamente su versión real, arquitectura o licencia. El alias es un identificador, no una versión detectada. Java requiere un JDK con java y javac; en macOS acepta el paquete .jdk o Contents/Home. Python puede usar una instalación o un entorno virtual con python/python3; PyPy sin esos ejecutables no es compatible automáticamente. Para .NET selecciona la carpeta que contiene dotnet, no una subcarpeta sdk/<versión>: si contiene varios SDK, global.json y las reglas de .NET siguen determinando el SDK elegido. Usa la raíz real del runtime en lugar de una carpeta general de accesos como /usr/bin.

Los alias admiten de 1 a 80 letras ASCII, números, puntos, +, guiones y guiones bajos; se rechazan nombres reservados y duplicados dentro del mismo runtime. El alias debe registrarse en cada equipo donde uses ese proyecto. Si mueves o eliminas la carpeta original, tendrás que volver a registrarla.

Un Python diferente para cada proyecto

1. Abre la carpeta del proyecto.
2. En DevMan → Proyectos, elige Elegir versión para el proyecto.
3. Selecciona Python y una versión instalada. Si hace falta, elige Instalar otra versión….
4. DevMan guarda la versión en .devman.json.
5. Abre una terminal nueva con + o tu atajo habitual y comprueba python --version.

Ejemplo del archivo generado:

{
  "schemaVersion": 2,
  "managed": {
    "python": "3.14.7",
    "node": "24"
  }
}

Cada terminal recibe el entorno de su proyecto. Si cambias .devman.json, abre una terminal nueva. exit cierra esa terminal. Entrar a otra carpeta con cd dentro de una terminal ya abierta no vuelve a seleccionar runtimes.

Terminales nuevas con el entorno del proyecto

Al detectar versiones en .devman.json, DevMan configura DevMan: Proyecto como perfil predeterminado del espacio de trabajo. Las terminales nuevas abiertas con +, Terminal → Nueva terminal o el atajo correspondiente usan las versiones del proyecto. No necesitas pulsar el botón de DevMan cada vez.

En Windows este perfil abre CMD mediante devman shell, con AutoRun desactivado para conservar la prioridad de los runtimes. En Linux y macOS usa la shell que selecciona DevMan CLI. Las terminales ya abiertas conservan su entorno: mostrar una terminal existente con un atajo no la actualiza.

Con varias carpetas, se usa el proyecto del editor activo; cuando no se puede determinar, aparece un selector. El cambio se guarda en terminal.integrated.defaultProfile.windows, .linux o .osx del espacio de trabajo, sin modificar la configuración global del usuario.

Para desactivarlo, ejecuta DevMan: Restaurar el perfil de terminal anterior o desmarca devman.autoProjectTerminal. DevMan guarda el perfil anterior para restaurarlo. Si eliges manualmente otro perfil predeterminado, respeta esa elección; puedes reactivarlo con DevMan: Usar DevMan en las terminales nuevas.

Funciones

Con varias carpetas abiertas, las acciones solicitan el proyecto correspondiente o usan la carpeta del elemento seleccionado. La barra de estado muestra la carpeta del editor activo y sus versiones declaradas.

Scripts

{
  "schemaVersion": 2,
  "managed": { "python": "3.14.7" },
  "scripts": {
    "test": { "command": "python", "args": ["-m", "unittest"] }
  }
}

Pulsa test en el panel del proyecto. Se ejecuta devman run test en una tarea con salida propia. Los scripts solo se ejecutan cuando los solicitas.

Configuración y compatibilidad

devman.executablePath permite indicar opcionalmente una ruta absoluta a una CLI 1.3.0 o posterior. Es una configuración del usuario/equipo; un repositorio no puede reemplazar el ejecutable mediante .vscode/settings.json. Si está vacía, usa el motor incluido en el VSIX. En Windows reconoce el lanzador estándar devman.cmd y usa directamente el .exe al que apunta. Una ruta explícita inválida produce un error; no se reemplaza silenciosamente.

Los procesos se ejecutan con argumentos separados, sin construir comandos de shell. Las rutas con espacios se conservan. La extensión se desactiva en espacios de trabajo no confiables y en sistemas de archivos virtuales; no es una extensión web para vscode.dev.

El código de la extensión admite Windows, Linux y macOS. La descarga y los requisitos de cada runtime dependen de DevMan y del host: PHP y Ruby siguen siendo experimentales; Ruby en Unix puede necesitar herramientas de compilación. La extensión conserva el comportamiento de devman shell de la plataforma. Las extensiones de depuración o lenguaje, como Python o Java, mantienen su propia selección de intérprete/SDK; esta extensión configura las terminales y ejecuciones de DevMan.

La instalación de un runtime se realiza en segundo plano y muestra su progreso en Salida → DevMan. Espera a que termine antes de cerrar VS Code. Los comandos de consulta tienen tiempo de espera; una instalación puede tardar más y no tiene un límite fijo.

Desarrollar y probar

El código de la extensión usa JavaScript sin dependencias npm de producción. Empaquetar la edición autónoma requiere .NET 10, Python, Node.js y PowerShell 7. Primero restaura la solución con dotnet restore DevMan.sln --locked-mode desde la raíz. El script genera seis VSIX con CLI autocontenida y manifiesto SHA-256; se firma el apphost de macOS cuando se empaqueta en macOS. La edición para Linux usa glibc; Alpine/musl no está incluido.

npm test
npm run check
pwsh ../../scripts/build-vscode.ps1

Para probar en una instancia de desarrollo:

code --extensionDevelopmentPath=/ruta/DevMan/extensions/vscode /ruta/proyecto

test/extension-host.js comprueba activación, comandos, árboles, CLI real y una terminal integrada que escribe la versión de Python. Requiere un perfil/carpeta de pruebas aislados, DEVMAN_TEST_CLI y un Python ya instalado (DEVMAN_TEST_PYTHON, por defecto 3.14.7). Se ejecuta con --extensionTestsPath=/ruta/DevMan/extensions/vscode/test/extension-host.js. El test modifica únicamente la configuración del perfil y proyecto de pruebas. Los tests de procesos y el host de VS Code necesitan un entorno que permita crear procesos y sus canales IPC.

Referencias de implementación

• API de árboles de VS Code
• API de terminales y tareas
• Confianza del espacio de trabajo
• Empaquetado e instalación de VSIX

Configuración de almacenamiento

Abre DevMan: Configuración: runtimes, paquetes y cachés desde la paleta de comandos, o pulsa el engranaje en la cabecera de Runtimes.

• Elige la carpeta base para nuevas instalaciones, descargas y caché del catálogo.
• Activa o desactiva las ubicaciones administradas de paquetes; elige una base común y excepciones para NuGet, npm, pip, Maven, Gradle, RubyGems/Bundler, Composer y Go.
• Usa Examinar…, Comprobar permisos y Guardar sin editar JSON ni ejecutar comandos.
• Puedes restaurar los valores predeterminados de paquetes o copiar las cachés de la configuración anterior. La copia admite cancelación y conserva los originales.
• Los errores aparecen en el panel con Mostrar detalle del error, y también en Salida → DevMan.

Esta configuración pertenece al usuario del host donde se ejecuta la extensión y se comparte con Desktop y CLI. En SSH/WSL se refiere al host remoto. No se guarda en .vscode/settings.json ni en .devman.json.

Las instalaciones existentes conservan su ubicación. Guardar una sección no borra cambios pendientes de la otra. Abre terminales nuevas después de guardar paquetes y reinicia Desktop después de cambiar la carpeta de runtimes. Comprobar permisos puede crear carpetas vacías. npm conserva node_modules y Composer conserva vendor en el proyecto; pip cambia únicamente su caché.

Extensiones de lenguajes y depuradores

devman.syncEditors está activado por defecto. Usa la versión local del runtime y, si no está fijada, la versión global activa. DevMan: Sincronizar runtimes con las extensiones permite revisar/aplicar la selección. Se conservan los ajustes manuales y las selecciones virtuales de Python. Consulta Salida → DevMan para ver conflictos y límites; guardar una versión no fuerza reemplazos de configuraciones ajenas.

Al desactivar devman.syncEditors, se restauran los valores que DevMan cambió si aún conservan el valor aplicado. No se borran cambios posteriores del usuario. Las rutas absolutas añadidas a la configuración de VS Code corresponden al host actual; revisa esos archivos antes de compartirlos entre equipos.

Dependencias por proyecto

En el árbol de proyectos, pulsa Dependencias del proyecto, o ejecuta DevMan: Configurar dependencias del proyecto. Puedes elegir ubicaciones habituales, paquetes locales o paquetes y cachés locales. La opción se guarda en .devman.json:

"packageStorage": { "mode": "project", "includeCaches": true }

• npm conserva node_modules y Composer conserva vendor; no redirige instalaciones explícitamente globales de esas herramientas.
• NuGet usa .devman/packages/nuget/packages; para proyectos .NET detectados se añade NuGet.Config conservando fuentes y rechazando rutas manuales incompatibles. Variables o propiedades explícitas de MSBuild/NuGet pueden tener prioridad.
• Maven, Gradle, Go y Ruby guardan dependencias bajo .devman/packages. Maven y Gradle no separan completamente repositorio/dependencias de otras cachés.
• Python utiliza .venv. Si no existe, DevMan lo crea con el Python seleccionado al preparar el entorno; requiere venv y ensurepip. Un .venv existente no se reconstruye ni cambia de versión automáticamente. Un fallo de creación se marca y se informa para evitar reutilizar un entorno incompleto.
• Se agregan .devman/packages y .venv al .gitignore. Los cambios se aplican a nuevos procesos DevMan; vuelve a ejecutar restore/install. No se trasladan ni eliminan paquetes al cambiar de modo.

CLI, desde la raíz del proyecto:

devman config project-packages project
devman config project-packages project --shared-caches
devman config project-packages shared
devman config environment

config environment resuelve runtimes y variables en JSON; puede preparar .venv cuando el proyecto tiene paquetes locales. Desktop ofrece los mismos modos en Proyectos, seleccionando una fila y guardando la ubicación de dependencias.