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.

[ramiadavid]

@yajo Y poner requests-pkcs12<=1.22 No solucionaría también el problema, Si lo que se pretende es que no use una versión mas nueva porque no es compatible?

[yajo]

La cuestión es que estamos mezclando conceptos diferentes.

Una cosa es qué dependencias tiene un módulo u odoo, y otra muy diferente es cuál versión de dicha dependencia vamos a desplegar.

A) Dependencias. Se establecen en __manifest__.py y son de uso obligatorio en cualquier despliegue de Odoo de cualquier tipo que quiera usar este módulo. Esto afecta a absolutamente todo el mundo, independientemente de las decisiones del equipo de sistemas. Da igual que uses venv, doodba, uv o cualquier otro sistema, estás obligado a incluir estas dependencias. Tradicionalmente se establecían en un requirements.in con pocos o ningún constraint. Odoo las establece en su setup.py.

B) La versión escogida de dichas dependencias. Cada sistema tiene su forma de decidir esto. Hay quien no pone restricciones e instala siempre la última versión, quien escoge la última versión de las major release, quien prefiere los paquetes de debian estable (esto hace Odoo), y un largo etc. Mecanismos modernos como Poetry, PDM o uv crean un lockfile consistente que evita conflictos de interdependencias. Tradicionalmente se construían usando el requirements.in para producir un requirements.txt con versiones estáticas establecidas. Odoo lo hace en su requirements.txt.

Así que el problema es que se estaba poniendo la versión específica de las dependencias (B) en el __manifest__.py, que es el sitio donde debemos declarar las dependencias de forma más laxa (A).

Y poner requests-pkcs12<=1.22 No solucionaría también el problema

Lo que ocurriría es que moverías el problema a otro sitio. Si alguien decide que quiere ignorar los requirements.txt de Odoo y poner una versión más moderna de esa librería, empezaría el mismo baile otra vez.

Como se puede ver en 74b3eeb (el commit anterior a #3954), el CI de OCA funcionaba bien antes de ese cambio.

¿Cómo se pudo haber solucionado entonces? Puesto que el problema está en el paso B (al resolver la versión final), la solución está ahí también. El usuario que tenga problemas porque en su sistema se está instalando una versión incorrecta de requests_pkcs12 debió haber instalado el módulo con un constraint. Ejemplo:

pip install odoo-addon-l10n_es_ticketbai_api_batuz -c requests_pkcs12==1.22

Es algo que debe añadir a su sistema de instalación o despliegue.

De esta forma, alteras la versión final de la dependencia que se instalará (B) sin afectar la forma en que se declaran (A).

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[rafaelbn]

Hola @extrememicro @ramiadavid , ¿pudisteis leer la respuesta de @yajo ? Podéis comentar por favor? Gracias! 😄