codicoop / boilerplates

Common setup that we use for most of the new projects.
0 stars 0 forks source link

Correccions al document de «Cració i inicialització d'un projecte Django» #2

Open barraquito opened 2 years ago

barraquito commented 2 years ago

Com que no tinc superclar on fer això, faig servir les "issues". Ho podem moure a un altre espai si volem.

En primer lloc, em falta entendre o clarificar el objectiu, com es vol treballar:

  1. En el entorn de desenvolupament local farem servir sempre docker/docker-compose per executar l'aplicació?
  2. La idea es tenir el entorn virtual també per poder accedir al codi de les llibreries al PyCharm (això es degut a que el PyCharm no pot navegar per les llibreries instalades dins del Docker)?

Ho dic per que el pas del pyenv e inicialitzar el poetry tenen sentit per el pas 2 per aquesta limitació del PyCharm, però potser amb altres IDE no cal, ja que tot estarà dins del contenidor Docker o en el entorn virtual propi que faci servir el tox.

Entenc que el tox serà el que farem servir per tot el que estigui relacionat amb corre el linting i la execució de testos, oi?

També comentava amb la @Arlaxia que pot ser el directori docker-develop està obsolet, ja que dins del docker ja hi ha una configuració per desenvolupament. @perepicornell segur que tu tens més clar això.

Em sembla que amb això estan totes les dubtes que en tinc de moment 😃

perepicornell commented 2 years ago
1. En el entorn de desenvolupament local farem servir sempre `docker`/`docker-compose` per executar l'aplicació?

Correcte

2. La idea es tenir el entorn virtual també per poder accedir al codi de les llibreries al PyCharm (això es degut a que el PyCharm no pot navegar per les llibreries instalades dins del Docker)?

Sí, exacte

Ho dic per que el pas del pyenv e inicialitzar el poetry tenen sentit per el pas 2 per aquesta limitació del PyCharm, però potser amb altres IDE no cal, ja que tot estarà dins del contenidor Docker o en el entorn virtual propi que faci servir el tox.

Sona interessant, tot i que em pregunto si això obligaria a tenir el contenidor funcionant? O d'alguna manera estarà accedint a la imatge? També cal tenir en compte que aleshores la gestió de paquets caldrà entrar a fer-la dins del contenidor, a diferència d'ara que faig els poetry add poetry remove etc. des de l'entorn virtual i després torno a fer build de la imatge.

Entenc que el tox serà el que farem servir per tot el que estigui relacionat amb corre el linting i la execució de testos, oi?

Sí, qualsevol altra cosa que hi hagi està obsoleta.

També comentava amb la @Arlaxia que pot ser el directori docker-develop està obsolet, ja que dins del docker ja hi ha una configuració per desenvolupament. @perepicornell segur que tu tens més clar això.

Sí, s'ha d'eliminar

Mercii :smile:

barraquito commented 2 years ago

Ho dic per que el pas del pyenv e inicialitzar el poetry tenen sentit per el pas 2 per aquesta limitació del PyCharm, però potser amb altres IDE no cal, ja que tot estarà dins del contenidor Docker o en el entorn virtual propi que faci servir el tox.

Sona interessant, tot i que em pregunto si això obligaria a tenir el contenidor funcionant? O d'alguna manera estarà accedint a la imatge? També cal tenir en compte que aleshores la gestió de paquets caldrà entrar a fer-la dins del contenidor, a diferència d'ara que faig els poetry add poetry remove etc. des de l'entorn virtual i després torno a fer build de la imatge.

Doncs això se m'escapa de moment. Sí que sé que fer servir docker per PyCharm es una característica de la versió de pagament. Ho podem deixar com està de moment i cap al futur ja veure.

La cosa es que si em fet corre el tox es genera un entorn virtual a .tox/py39 que probablement podríem fer servir per aquesta tasca. Així no cal tenir dos entorns virtuals pel mateix.

Mercii :smile:

De res 😊