[pyar] Importación de módulos

Leandro E. Colombo Viña colomboleandro en gmail.com
Dom Mar 1 23:55:16 ART 2015


Buenísimo Juan Pablo,

voy a ver si implemento lo que me sugerís. Gracias por el dato de baker,
muy copado. También voy a probar Authcode a ver cómo me resulta, aún no
implementamos la autenticación y lo tenemos pendiente.

Abrazo!

El 27 de febrero de 2015, 11:24, Juan Pablo Scaletti <
juanpablo en jpscaletti.com> escribió:

>
> On Feb 26, 2015, at 6:41 PM, Leandro E. Colombo Viña <
> colomboleandro en gmail.com> wrote:
>
> Estimados!
>
> Vengo a consultarles cómo me sugieren o cómo es la mejor manera de hacer
> esta importación...
>
> Estamos trabajando en una aplicación y pensamos la siguiente estructura:
>
> app/
>     run.py
>     controlador/
>         __init__.py
>         controlador.py
>     db/
>         __init__.py
>         db.py
>     monitor/
>         __init__.py
>         monitor.py
>
> La idea es la siguiente: la app se corre desde run.py, es una aplicación
> web en Flask que consulta una base de datos y controla unos dispositivos
> electrónicos. En monitor está toda la parte web y lo que sería la interfaz
> de usuario. En db está la configuración de la base de datos (ahí se importa
> el conector y está la clase que maneja la conexión) que usaría tanto el
> monitor como el controlador. Y en controlador está todo lo necesario para
> comunicarse con la electrónica.
>
> El tema es que queremos ver cuál es la mejor manera de realizar la
> importación de los parámetros de configuración de la base de datos para
> ambos paquetes (monitor y controlador).
> Recomiendan usar importaciones relativas? O cargar en el sys.path los
> directorios donde estan los paquetes e importarlos así?
>
> Si recomiendan otra estructura de directorios, escuchamos ofertas...
> La idea es tener un único módulo con todo lo de la db, y que pueda ser
> llamado por el controlador y el monitor. Además necesitamos la
> funcionalidad de que el monitor pueda llamar (y ejecutar) al controlador.
>
> Abrazo!
>
> Hola!
>
> *A mi* me parece que usar imports relativos es mucho más limpio y claro
> que agregar cada folder a tu PYTHON_PATH
> Pero con tu estructura actual no funcionará, por que si desde
> `controlador.py` intentas hacer algo como:
>
>     from ..monitor import monitor
>
> se va a quejar de: `ValueError: Attempted relative import beyond toplevel
> package`
>
> Necesitas un folder intermedio, de esta manera:
>
> app/
>     run.py
>     webapp/
>         __init__.py
>         controlador/
>             __init__.py
>             controlador.py
>         db/
>             __init__.py
>             db.py
>         monitor/
>             __init__.py
>             monitor.py
>
> Sobre la configuración, lo que yo hago es tener un folder `config` con
> archivos separados para cada entorno
>
> webapp/
>     config/
>         __init__.py
>         common.py
>         development.py
>         production.py
>
> El `common.py` tiene la configuración común (o base) para todos los
> entornos. Los demás hacen
>
>     from .common import *
>
> al principio y sobreescriben o agregan cualquier configuración específica.
> El truco está en el archivo `__init__.py`
>
> En que entorno estás puedes leerlo desde... una variable de entorno:
>
>     # coding=utf-8
>     import os
>
>     APP_ENV = 'AWESOMEAPP_ENV'
>
>     if os.environ[APP_ENV] == 'production':
>         from .production import *
>     else:
>         from .development import *
>
>     # Import local settings
>     try:
>         from .local import *
>     except ImportError:
>         pass
>
> Yo además le agrego un archivo `local.py` que **no** se supe al control de
> versiones, donde cada desarrollador puede poner su configuración específica
> para su computadora (user/passw de su BD local por ejemplo).
>
> Sobre la estructura más plana, pues depende de que tan grande sea tu
> proyecto.
> A mi me gusta tener cada modelo y cada vista en un archivo separado (para
> encontrarlas rápidamente), así que esas carpeta se llenan rápidamente.
>
> Otros consejos sueltos:
>
> - Piense en usar algo como Baker (
> https://bitbucket.org/mchaput/baker/wiki/Home) para tu run.py. optparse
> IMHO es más complejo de lo que debería.
> - Y dode están los requirements.txt ? Necesitas uno para cada entorno ¿no?
> - Es una aplicación web? Authcode [by me ;)] (http://authcode.lucuma.co/)
> para la autenticación
>
> Suerte!
>
>
> — Juan Pablo
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20150301/d8a77a8e/attachment.html>


More information about the pyar mailing list