Si "prueba" libA-dev utilizando libT, que depende de libA (estable), entonces realmente no está probando libA-dev, ya que se comportaría en un entorno de producción. La única forma de probar realmente el libA-dev es tomar la zambullida completa y hacer que libT dependa de libA-dev. Si esto rompe las pruebas de su unidad, entonces eso es algo bueno: le muestra lo que debe arreglarse.
Si no tiene pruebas unitarias, entonces este es el momento de comenzar a hacerlas (usando estable libA y libT primero!).
Recomiendo usar un "sistema de control de versiones" (por ejemplo, bzr, hg, svn, git). Entonces podrías hacer las ramas de tu proyecto, "estable" y "devA".
Para trabajar en la rama de Deva, primero ejecutar
export PYTHONPATH=/path/to/devA
Asegurándose de que la variable de entorno PYTHONPATH excluye a las otras ramas, usted tiene la seguridad de Python está usando sólo los módulos que desea.
Cuando llegue el momento de combinar el código de dev -> estable, el software de control de versiones proporcionará una manera fácil de hacerlo también.
El control de versiones también le permite ser más audaz: intentar cambios importantes no es tan aterrador. Si las cosas no funcionan, revertir es súper fácil. Entre eso y el truco PYTHONPATH, siempre puedes volver al código conocido y funcional.
Si cree que lo anterior simplemente no le va a funcionar, y debe usar libT-which-depends-on-libA para probar libA-dev, tendrá que cambiar el nombre de todos los módulos y modificar todas las declaraciones de importación para hacer una separación clara entre libA-dev y libA. Por ejemplo, si libA tiene un módulo llamado moduleA.py, renómbrelo moduleA_dev.py.
El comando
rename -n 's/^(.*)\.py/$1_dev.py/' *.py
añadirá "_dev" a todos los archivos * .py. (Con el indicador "-n", el comando de cambio de nombre solo le mostrará el cambio de nombre contemplado. Quite la "-n" para continuar con el cambio de nombre.)
para revertir el cambio de nombre, ejecute
rename -n 's/^(.*)_dev\.py/$1.py/' *.py
A continuación, tendrá que cambiar todas las referencias a moduleA a moduleA_dev dentro del código. El comando
find /path/to/LibA-dev/ -type f -name '*.py' -exec sed -i 's/moduleA/moduleA_dev/g' {} \;
alterará todos los archivos * .py en Liba-dev, cambiando "moduleA" -> "moduleA_dev".
Tenga cuidado con este comando. Es peligroso, porque si tienes una variable llamada moduleAB, se cambiará de nombre a moduleA_devB, mientras que lo que realmente querías podría ser moduleAB_dev.
Para revertir este cambio (sujeto a la advertencia anterior),
find /path/to/LibA-dev/ -type f -name '*.py' -exec sed -i 's/moduleA_dev/moduleA/g' {} \;
Una vez que se separan los espacios de nombres, que ha roto la dependencia circular. Una vez que esté satisfecho de que su libA-dev es bueno, puede cambiar el módulo. A_dev.py -> moduleA.py y cambia todas las referencias al moduleA_dev -> moduleA en su código.
¿Por qué no puede usar sus herramientas ordinarias de administración de código fuente para construir la configuración deseada de código estable y de desarrollo? Todos los demás hacen esto en SVN con sucursales. Y sin programación. ¿Por qué no puedes usar ramas SVN para hacer esto? –
No pude ver qué ramificación tiene que ver con esto, así que hice la pregunta un poco más clara, con la esperanza de que te ayude a entender lo que estoy tratando de hacer. – abyx