gestion - importar clases en python

estructura de directorios para un proyecto que mezcla C++ y Python

Question

Digamos que quiere crear un proyecto de programación que mezcle C ++ y Python . La estructura del proyecto Foo C ++ utiliza CMake , y se crea un módulo Python utilizando Swig . La estructura del árbol se vería así:

├── CMakeLists.txt
├── FooConfig.cmake.in
├── FooConfigVersion.cmake.in
├── Makefile
├── README
├── foo
│   ├── CMakeLists.txt
│   ├── config.hpp.in
│   ├── foo.cpp
│   └── foo.hpp
└── swig
└── foo.i

Ahora desea utilizar el proyecto Foo dentro de un proyecto de Python , digamos Bar :

├── AUTHORS.rst
├── CONTRIBUTING.rst
├── HISTORY.rst
├── LICENSE
├── MANIFEST.in
├── Makefile
├── README.rst
├── docs
│   ├── Makefile
│   ├── authors.rst
│   ├── conf.py
│   ├── contributing.rst
│   ├── history.rst
│   ├── index.rst
│   ├── installation.rst
│   ├── make.bat
│   ├── readme.rst
│   └── usage.rst
├── bar
│   ├── __init__.py
│   └── bar.py
├── requirements.txt
├── setup.cfg
├── setup.py
├── tests
│   ├── __init__.py
│   └── test_bar.py
└── tox.ini

Esta estructura se creó utilizando la plantilla de paquete de cookies de cookiecutter . Una plantilla BoilerplatePP también está disponible para generar un proyecto CMake C ++ utilizando un cortador de cookies (sin parte Swig ). Entonces, ahora que tengo la estructura de ambos proyectos, y considerando que el desarrollo tendrá lugar principalmente en Python y que el proyecto se ejecutará en diferentes sistemas, necesito abordar las siguientes preguntas:

1. ¿Cuál es la mejor manera de mezclarlos? ¿Debería colapsar ambos directorios raíz? ¿Debería tener el proyecto Foo C ++ como un directorio del proyecto Bar o al revés? Me inclino a poner toda la estructura de C ++ mostrada arriba en una carpeta en el nivel raíz del proyecto de Python , pero me gustaría saber a priori cualquier inconveniente ya que el sistema CMake es bastante poderoso y puede ser conveniente hacerlo otro camino alrededor.
2. En caso de que decida poner el proyecto Foo como un directorio dentro de Bar , ¿el paquete de herramientas de instalación de Python es tan poderoso como el sistema de compilación CMake ? Pregunto esto porque cuando echo un vistazo al proyecto Bar , en el nivel superior parece que hay solo un conjunto de scripts, pero no sé si esto es equivalente a CMake ya que soy nuevo en Python .
3. El proyecto de Bar descrito anteriormente tiene un único directorio de barras , pero asumo que cada vez que este proyecto se expanda, en lugar de tener muchos otros directorios en el nivel raíz, otros directorios que contengan el código de Python se colocarán dentro de la barra . ¿Es esto correcto (en el sentido Pythonic )?
4. Supongo que se producirá un solo huevo a partir de todo el proyecto, para que pueda instalarse y ejecutarse en muchos sistemas Python diferentes. ¿Es fácil la integración del módulo creado por el proyecto Foo ? Supongo que este módulo se creará en un directorio diferente de la barra .
5. Para que el código de Python esté dentro del directorio de la barra , el módulo creado por Swig debe estar disponible, así que supongo que la forma más sencilla de hacerlo es modificar la variable ambiental PYTHONPATH utilizando el sistema CMake . ¿Está bien o hay una mejor manera?

Answer 1

Si la aplicación C ++ no tiene uso fuera del paquete de Python que lo contendrá:

Puede colocar con bastante seguridad el código C ++ dentro del paquete python que lo posee. Tenga el directorio "foo" dentro del directorio "bar" dentro de su ejemplo. Esto hará que el empaquetado del módulo final de Python sea un poco más fácil.

Si la aplicación C ++ es reutilizable:

Definitivamente trataré de pensar las cosas en términos de "paquetes", donde las partes independientes son autónomas. Todas las partes independientes viven en el mismo nivel. Si una parte depende de otra, la importa desde su correspondiente "paquete" desde el mismo nivel. Así es como funcionan las dependencias.

NO incluiría uno dentro del otro, porque uno no pertenece estrictamente al otro. ¿Qué pasaría si comenzara un tercer proyecto que necesitara "foo", pero no necesitara "barra"?

Colocaría los paquetes "foo" y "bar" en el mismo directorio "proyecto" (y probablemente le daría a cada paquete su propio repositorio de código para que cada paquete pueda mantenerse e instalarse fácilmente).