Por qué PHP 8 no satisface el requisito ^7.3 de composer

He ejecutado el comando:

composer install

En un ordenador de desarrollo recién instalado. Me ha arrojado un error:

Root composer.json requires php ^7.3 but your php version (8.1.0) does not satisfy that requirement

¿No se supone que si tengo la versión 8 de PHP ese requisito debería no dar un error?

Me crucé con esta consulta recientemente y me pareció interesante responderla ya que, probablemente, quien la realizó no sea el único con este problema u otro similar.

Claramente la respuesta a la pregunta ¿No se supone que si tengo la versión 8 de PHP ese requisito debería no dar un error? es un No rotundo. Vamos que si no fuese así la pregunta ni existiría pero bueno… tomémosla como una pregunta retórica y un buen disparador para este post.

Es más, cambiaré la pregunta por la que puse como título: ¿Por qué PHP 8 no satisface el requisito ^7.3 de composer?

Para responder a esta pregunta es necesario comprender qué significa el ^7.3 que está en el archivo composer.jon.

Antes de meterme en los detalles es importante saber que, en este contexto, esa expresión corresponde a un requisito de versión (Version constraint).

Cómo funcionan los version constraints de composer

Una de las características más potentes (¡y más confusas!) de composer es esta: la especificación de las versiones aceptables de cada dependencia.

Precisamente, el motivo de la creación de composer fue el poder evitar tener la versión X.Y.Z de una librería en desarrollo y luego, en producción encontrarte con la versión X+1.Y.Z y que todo explote misteriosamente.

La premisa en la que se basa composer es que las dependencias definen sus versiones utilizando versionado semántico. Si este supuesto no se cumple… difícilmente composer pueda hacer bien su trabajo.

Ahora, el modo de expresar estos requerimientos requiere prestarle bastante atención a los detalles.

Para comenzar, existen diferentes tipos de restricción.

La más simple de ellas es la exacta. Este tipo de restricción debe usarse cuando sabés exactamente qué versión de una dependencia querés usar. En este ejemplo sería algo como 7.3.33.

En un caso como este no hay dudas, el trabajo de composer es bien sencillo: descargar los archivos correspondientes al tag 7.3.33 del repo de php.

Un caso de uso más realista es aquel en que no sabés el número exacto de la versión si no un aproximado.

Sería algo como decir quiero usar una versión de php 7.3, el patch no me interesa demasiado.

Esto sería similar a decir quiero una versión que se encuentre entre la 7.3.0 y la última antes de la 7.4.0.

Para expresar dicha restricción podés usar la combinación de dos restricciones:

• >=7.3
• <7.4

En el caso de composer, estas se combinan usando un simple espacio en blanco, que se interpreta como un &:

>=7.3 <7.4

Un detalle importante: composer siempre responderá con la versión más reciente que pueda, es decir, aquella que satisfaga todas las restricciones solicitadas.

Qué significan los símbolos de las versiones en composer

Ahora sí, vamos a ir un poco más abajo y veamos cada uno de los símbolos que se pueden usar para especificar versiones.

>= y < se explican por si mismos creo.

Pero también existen ~, ^ y *… la cosa se complica, ¿no?

Intentaré ir del más simple al más complejo.

El * es un viejo conocido de quienes estamos en software. ¿Tal vez te suene de las experesiones regulares? Pues sí, es el comodín.

Esto significa que una restricción de tipo 7.3.* se interpreta como cualquier patch de la rama 7.3. Es decir, composer mapeará este valor al tag más reciente que encuentre en dicha rama.

El ~ es una forma abreviada de escribir una restricción tipo >= <.

El ^ se comporta casi como ~ pero es algo más estricto.

La idea tanto de ~ como de ^ es evitar problemas de incompatibilidad hacia atrás.

Esta es la clave para comprender el problema que está experimentando el protagonista de esta historia:

La restricción ^7.3 marca, ante todo, que el major de la versión de php a utilizar debe ser 7, el minor podría cambiar (y, por supuesto, también el patch).

Esto se debe a que, en cualquier salto de versión major es posible encontrar cambios que rompan compatibilidad hacia atrás.

Es por eso que composer no permitirá que inadevertidamente introduzcamos un cambio de infraestructura que ponga nuestro sistema en riesgo.

El sistema de restricciones de versiones es bastante complejo, si quieres conocer más sobre él te recomiendo ir directo a la fuente.

De hecho, si te encuentras en una situación como la que dio origen a este post, te recomiendo abrir ese documento en una ventana y tu composer.json en otra.