Revert "[16.0][FIX] pinned requests_pkcs12 version due cryptography dependency"

[yajo]

Aquí revierto #3954 pues el fix empezó a romper nuestro CI:

ERROR: Cannot install requests_pkcs12 because these package versions have conflicting dependencies. The conflict is caused by:
    requests-pkcs12 1.22 depends on requests>=2.26.0
    The user requested (constraint) requests==2.25.1
To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

En resumidas cuentas, lo que viene diciendo es que al exigir requests-pkcs12==1.22, estamos rompiendo este constraint de Odoo.

Esto me ha empezado a suceder porque usamos el archivo requirements.txt de Odoo como un pip contraint y no como un pip requirements. Algo así:

pip install \
    -r https://github.com/OCA/l10n-spain/raw/refs/heads/16.0/requirements.txt \
    -c https://github.com/odoo/odoo/raw/refs/heads/16.0/requirements.txt

Lo hacemos así para siempre coger las dependencias más modernas que necesitan los módulos de OCA, pero respetando las restricciones últimas que establece Odoo. Para que esto funcione, es mejor que los repos de OCA no definan restricciones de versiones¹, y dejar que sea Odoo quien las restrinja.

Dicho de otra forma, si usas el requirements.txt de OCA, es mejor que dicho archivo no congele versiones para que sea Odoo quien lo haga.

Dejo el PR en borrador hasta que compruebe si esto realmente resuelve el problema.

---

¹ Las restricciones de versiones que tengan sentido se deben poner, por supuesto (si el módulo es incompatible con cierta versión de cierta dependencia). Pero si se ponen solo para evitar conflictos o reinstalaciones, es contraproducente, y es preferible hacerlo con constraints como se explica arriba.

@moduon MT-8983

[OCA-git-bot]

Hi @ao-landoo,
some modules you are maintaining are being modified, check this out!

[rafaelbn]

Hola! ao-landoo ya no es mantendor, ¿quíén podría revisar este PR por favor @OCA/local-spain-maintainers ?

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[pedrobaeza]

@extrememicro fue el que tuvo el problema, así que debéis acordar entre los dos la solución adecuada para todos.

[extrememicro]

@yajo pero creo que muchos instalaran los requirements de la localización sin el constraint al requirements de Odoo, como el Runboat, o Doodba, por ejemplo.
Si se revierte, se instalarán últimas versiones de requests-pkcs12 y por consiguiente de cryptography y daría error.
No es más compatible para todos los casos usar la versión compatible de requests==2.25.1 fijada: requests-pkcs12==1.12 ?

[yajo]

Es otra opción. No obstante, en general, usar los constraints es mucho mejor porque permites a cualquiera la libertad de instalar la versión que no colisione con el resto de su entorno.

Se pueden usar los constrains en Doodba y básicamente cualquier sitio que use un requirements.txt porque se puede incluir en el propio archivo requirements.txt. Este sería un ejemplo válido:

# requirements.txt
-r https://github.com/OCA/l10n-spain/raw/refs/heads/16.0/requirements.txt
-c https://github.com/odoo/odoo/raw/refs/heads/16.0/requirements.txt

# También puedes tener tus propios constraints diferentes
-c requests<3

Puesto que nuestros constraints se autogeneran, si los escribimos en el manifest estamos realmente creando una dependencia estricta. Puede ser que alguien prefiera actualizar los paquetes más allá de lo que Odoo recomienda (y por tanto tenga sus propios requirements o constraints), como se ve en OCA/oca-ci#66 (comment).

En resumen, no deberíamos restringir la instalación de una determinada versión de una dependencia solamente porque una subdependencia no sea exactamente la favorita de Odoo SA, sino solamente porque realmente es la única versión compatible. Este acercamiento permite más flexibilidad a la hora de reutilizar las piezas que la OCA proporciona, y por eso creo que es mejor.