Cargo-edit: `cargo add`: incluye solo MAJOR.MINOR

¿Por qué?

¿Por qué?

¿Por qué, por ejemplo, semver y regex se especifican en este formulario en Cargo.toml de cargo-edit? :Cara de burla:

Por lo general, desea especificar un nivel de característica mínimo requerido, por lo que, por ejemplo, docopt usa este modelo.

Preferiría preguntarle por qué desea especificar la versión completa.

¡Buenos puntos!

Si agrego dependencias a mano, tiendo a omitir la versión del parche, excepto si
es un 0.xy sé que esta función se agregó recientemente, como regex = "0.1.66" .

Sin embargo, desde un punto de vista práctico, esto es estética: 1.2.3 y 1.2 y
1 cargarán todos 1.4.9 (si esa es la última versión), como lo interpreta la carga
esto como ^1.2.3 etc.

Desde un punto de vista pesimista: 1.2.0 a 1.2.2 probablemente tengan errores
versiones, ¿por qué si no iban a publicar una 1.2.3? Entonces, asegurémonos de que nosotros (y
¡con suerte, als otras dependencias) están usando la última versión!

Como puede ver, parece haber buenos argumentos para ambas partes, y me encantaría
para escuchar un poco más antes de decidir!

Andronik Ordian [email protected] schrieb am Do. 29 de junio de 2017 um
01:18:

¿Por qué?

Por qué, por ejemplo, semver y regex se especifican en este formulario en cargo-edit's
Cargo.toml? [imagen:: trollface:]

Por lo general, desea especificar un nivel de característica mínimo requerido, por ejemplo,
docopt https://github.com/docopt/docopt.rs/blob/master/Cargo.toml utiliza
Este modelo.

Preferiría preguntarle por qué desea especificar la versión completa.

-
Estás recibiendo esto porque hiciste un comentario.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/killercup/cargo-edit/issues/126#issuecomment-311818430 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AABOX0xJ-m_uioA7lhD29mlL6mlAvgvEks5sIt9DgaJpZM4OIifr
.

Sin embargo, desde un punto de vista práctico, esto es estética: 1.2.3 y 1.2 y
1 cargarán todos 1.4.9 (si esa es la última versión), como lo interpreta la carga
esto como ^1.2.3 etc.

Yo diría que 1.2 es mejor que 1 porque el último no especifica el conjunto mínimo de características, mientras que el primero lo hace.

Desde un punto de vista pesimista: 1.2.0 a 1.2.2 probablemente tengan errores
versiones, ¿por qué si no iban a publicar una 1.2.3? Entonces, asegurémonos de que nosotros (y
¡con suerte, als otras dependencias) están usando la última versión!

Considere el siguiente ejemplo. En algún momento, agrega una dependencia X a través de cargo add, digamos 1.2.1.
Más tarde se encontró un error en X. Pero olvidó actualizar la dependencia. En este escenario, 1.2.1 es peor que 1.2, porque 1.2 solo se compilará a la última versión.

Yo diría que 1.2 es mejor que 1 porque el último no especifica el conjunto mínimo de características, mientras que el primero lo hace.

Cierto. Pero puede argumentar fácilmente que 1.2.3 es mejor que 1.2 porque el último no especifica el nivel mínimo de parches que hacen que la característica necesaria funcione mientras que el primero sí :)

En este escenario, 1.2.1 es peor que 1.2, porque 1.2 solo se compilará a la última versión.

Si te entiendo correctamente, esto es falso, en realidad. Asumiendo

Pero olvidó actualizar la dependencia.

significa que ya tiene la versión de dependencia fijada en su Cargo.lock, ambos actúan de la misma manera. Y cargo update actualizará ambos a la última versión <2.0.0. Cargo asume ^ predeterminado, consulte esto para obtener más detalles.

Cierto. Pero puede argumentar fácilmente que 1.2.3 es mejor que 1.2 porque el último no especifica el nivel mínimo de parches que hacen que la característica necesaria funcione mientras que el primero sí :)

Es cierto, pero solo si confía en que se corrija el error.

Si te entiendo correctamente, esto es falso, en realidad.

Sí, mi cerebro no funcionaba a altas horas de la noche. Lo siento por eso.

Entonces, lo que estaba diciendo en el punto pesimista es que si tenemos una dependencia transitiva X = "= 1.2.0" y si especificamos dependencia directa X = "1.2" - se compilará, mientras que con X = "1.2.3 "¿No lo hará, obligándonos a actualizar la dependencia transitiva? Creo que este es un ejemplo bastante elaborado.

En resumen, creo que agregar una opción para eliminar la versión del parche no hará daño.
Además, agregar una opción para no ensuciar todo Cargo.toml: rofl: (pero ese es el problema diferente).

En resumen, creo que agregar una opción para eliminar la versión del parche no hará daño.

¿Daño? No. Pero es una cosa más que mantener, y todavía no he visto una razón para molestarme. ¿Quizás haya otras personas que también quieran tener esto?

una opción para no ensuciar todo Cargo.toml

¡No! No es una opción_! ¡El valor por defecto! Y sin bandera --mess 😄 (cf. # 15)

Encontré este boleto porque generalmente solo he estado grabando major.minor en mis archivos manuales Cargo.toml porque pensé que era lo recomendado. El único caso en que puedo ver que cambia el comportamiento funcional es si alguien publicara y luego tirara una versión de una caja (por ejemplo, si se aplicó un parche de optimización, pero luego se descubrió que introducía un agujero de seguridad o regresión) - en este En caso de especificar la versión del parche, evitaría que la biblioteca se construya si alguien simplemente la revisa hasta que se publique una versión más nueva de la biblioteca.

Sin embargo, cambia la forma en que se lee, ya que tener tres en lugar de dos números sugiere que el autor de la biblioteca eligió muy específicamente ese número de parche y más nuevo, en lugar de simplemente elegir el último parche de los números mayores y menores.

Sin embargo, alternativamente, podría ver el Cargo.toml más como un registro en lugar de una especificación de lo que el autor creó por última vez con la biblioteca. Sin embargo, esto parece más un deber de Cargo.lock, y el resto de la información en Cargo.toml parece ser, en general, una definición lo más mínima posible de lo que es la biblioteca y cómo debe construirse.

EDITAR: NB: encontré esto después de ejecutar el comando de actualización de carga, no agregar carga, pero esperaría que los dos comandos tuvieran la misma convención (dos o tres puntos de versión).

Hoy me encontré con otro problema: usar la actualización de carga restringe más el gráfico de dependencia en comparación con usar solo "major.minor". Tuve que retroceder serde y tokio_core por una versión (por ejemplo, 1.0.38 a 1.0.37) debido a bibliotecas dependientes con las que esto entraba en conflicto.

Definitivamente agradecería una opción en cargo add y cargo upgrade para ceñirse a la especificación de información mínima.

Es una verruga muy pequeña, pero prefiero mantener todas mis versiones de dependencia como 0.4 o 1 lugar de especificar más detalles y así terminar editando manualmente Cargo.toml después de cada uso de un comando cargo-edit para eliminar las versiones menor y parche.

Probé cargo upgrade por primera vez hoy y también soy una de estas personas que preferiría que se ciñara a 1 y 0.4 lugar de major.minor.patch. 😃

Voy a intervenir diciendo que estoy a favor de que la edición de carga mantenga el número de versión más específico posible. Estoy feliz de que use el nivel de parche actual ...

De hecho, me encantaría que hubiera una manera de caminar hacia atrás en las versiones para encontrar la primera versión utilizable / compatible de una dependencia para que mis requisitos sean los más flexibles para las personas que usan mi caja.

Sin duda alguna, encontrar la versión más antigua es una mala idea porque:

• faltarán posibles correcciones de errores y parches de seguridad;
• si es una caja -sys o si depende transitivamente de una caja -sys, y alguna otra dependencia del usuario de su caja depende de una versión más nueva de esa caja -sys que se vincula a una versión más nueva de la biblioteca nativa, ganaron ' No podrá construir su biblioteca ya que cargo rechazará la vinculación en dos versiones diferentes de la biblioteca nativa. Golpeé este con openssl , una de las dependencias de mi caja estaba desactualizada y dependía transitivamente de un antiguo openssl-sys y otra de las dependencias de mi caja tenía incluso su primera versión dependiendo de un openssl-sys . No encontré salida a la situación y tuve que abandonar la idea que tenía que implicaba esa nueva dependencia.

@YaLTeR No estoy de acuerdo con su evaluación porque parece que no tiene en cuenta la lógica de resolución de Cargo.

Si mi caja A se basa en libc 0.0.1 y otra caja B se basa en 0.0.2 , una tercera caja C dependiendo de A y B usará 0.0.2 sin problemas. El usuario obtiene las máximas correcciones de errores posibles.

Poner 0.0.1 en Cargo.toml no requiere que se elija una versión específica, solo una semver-compatible con ella. Consulte los documentos de Cargo para obtener la lista completa de operadores que puede utilizar para expresar las restricciones de versión de su caja. Por ejemplo, twox-hash es compatible con rand 0.3.10, 0.4.xy 0.5.x porque la superficie API que necesita no ha cambiado en esas versiones. No hay ninguna razón para que yo sea incompatible con otra caja que requiera rand 0.4 y obligue al usuario a actualizar a 0.5.

y otra de las dependencias de mi caja tenía incluso su versión más antigua dependiendo de una openssl-sys más nueva

Ese es el problema que estoy abogando por evitar. Si esa caja fuera compatible tanto con la versión anterior como con la más reciente y la hubiera especificado en Cargo.toml, no habría tenido el problema en primer lugar .

Hmm, sí, buen punto. ¿Hay alguna manera de forzar una caja con un requisito como twox-hash es para usar una versión específica, no la última, de la caja dependiente?

una caja con un requisito como twox-hash es

En un proyecto que usa twox-hash y una dependencia lateral, Cargo elegirá varias versiones (por el motivo que sea), pero puede elegir unificarlas:

''
$ gato Cargo.toml
[dependencias]
twox-hash = "1.1.1"
rand = "0.4"

$ árbol de carga
ex v0.1.0 (archivo: /// privado / tmp / ex)
├── rand v0.4.3
│ └── libc v0.2.43
└── twox-hash v1.1.1
└── rand v0.5.5
├── libc v0.2.43 (*)
└── rand_core v0.2.1

$ cargo update -p rand: 0.5.5 --precise 0.4.3

$ árbol de carga
ex v0.1.0 (archivo: /// privado / tmp / ex)
├── rand v0.4.3
│ └── libc v0.2.43
└── twox-hash v1.1.1
└── rand v0.4.3 (*)

De hecho, me encantaría que hubiera una manera de caminar hacia atrás en las versiones para encontrar la primera versión utilizable / compatible de una dependencia para que mis requisitos sean los más flexibles para las personas que usan mi caja.

Si se proporciona este comportamiento, estaría feliz de no tener soporte MAJOR.MINOR sin parche.

Sin embargo, hasta que tengamos eso, seguiré presionando por la opción de excluir el parche y posiblemente versiones menores.

La razón principal por la que elimino el parche es que es bastante arbitrario. El 99% de las veces es solo la versión de parche más reciente cuando agregué la dependencia. Por lo general, ni siquiera representa las funciones utilizadas, ya que podría terminar dependiendo de las funciones más nuevas sin actualizar la versión del parche; solo actualizaría la versión realmente utilizada en Cargo.lock . ¡Nunca actualizaría las versiones del parche en cualquier caso, ya que eso crea confirmaciones y abandonos sin ningún motivo! Alguien que use cargo update en el proyecto final obtendrá la última versión compatible de todas mis dependencias de todos modos.

Prefiero enumerar el menos específico que todavía tiene información semver porque más información (versión MINOR si MAJOR> 0, o PARCHE si MAJOR.MINOR> 0) es, en el mejor de los casos, inútil y, en el peor, completamente incorrecta.

Fácilmente podría terminar dependiendo de las funciones más nuevas sin actualizar la versión del parche

Recomiendo agregar una línea a su CI para evitar esto:

cargo +nightly -Z minimal-versions test

versión en Cargo.lock

No creo haber dicho esto explícitamente, pero lo que más me preocupan son las bibliotecas . Para binarios que no parece como que realmente importa lo que usted pone en su Cargo.toml porque hay un Cargo.lock .

@hepmaster

Realmente debería acostumbrarme a usar minimal-versions . Simplemente no he actualizado las configuraciones de CI desde que se convirtió en una cosa. Gracias por mencionar eso.

Si obtenemos eso y "actualizamos a la versión mínima que aún compila y pasa las pruebas", entonces sería bueno abandonar esto por completo.

También estaba considerando las cajas binarias solo porque sigo el mismo principio de excluir versiones de parches para ellos, y este problema también es un problema para ellos. Sí, no importa tanto lo que haya en Cargo.toml , pero esa es una razón más para no incluir versiones innecesarias y semi-arbitrarias.

Otra preocupación que tengo con versiones como en el ejemplo twox-hash : probablemente esté desarrollando y probando la caja en la última versión de la caja (rand 0.5 en este ejemplo), por lo que accidentalmente puede comenzar a usar una API que no era ' t cubierto por versiones anteriores (0.3 o 0.4) sin darse cuenta. ¿Eso significa que ahora esencialmente necesitas probar cada combinación de cada versión de una dependencia como esa? @hepmaster

EDITAR: también ¿por qué estaba marcado como no se corrigió? ...

probablemente estés desarrollando

Sí, lo más probable

y probando la caja en la última versión de la caja

Vea mi comentario anterior para ver una forma de probar esto.

¿Eso significa que ahora esencialmente necesitas probar cada combinación de cada versión de una dependencia como esa?

Debido a que semver es una construcción humana y no algo exigido por el compilador, técnicamente sí, siempre necesitaría probar con todas las versiones posibles para estar seguro. Adopto un enfoque más práctico y confío en que otros desarrolladores lo hagan bien la mayor parte del tiempo.

Tenga en cuenta que esto ya es un problema que podría experimentar. Si pones itertools = "1.0" en tu Cargo.toml, como sugiere este problema, entonces estás diciendo que tu código funciona con 1.0.0, que parece más probable que sea incorrecto que itertools = "1.2.35" . El comportamiento actual, de elegir la versión actual, tiene la ventaja de que su código se probó con la versión de la caja que especificó en un momento determinado.

La mayoría de las configuraciones de CI aseguran que trabaje con las versiones más recientes de todas las cajas posibles (dado que el archivo de bloqueo no está comprometido, se vuelve a resolver en cada ejecución). Es posible buscar la versión más antigua de todas las cajas posibles a través de -Z minimal-versions . No conozco ninguna forma de comprobar cada permutación 😉

Adopto un enfoque más práctico y confío en que otros desarrolladores lo hagan bien la mayor parte del tiempo.

Sí, pero en caso de un requisito como >= 0.3, < 0.6 es perfectamente válido para, por ejemplo, 0.5 para agregar una nueva API que podría comenzar a usar sin darse cuenta de que no estaba disponible en 0.3. Supongo que -Z minimal-versions es de gran ayuda aquí.

Quería hacer un seguimiento de esto, ya que se está volviendo un poco viejo para seguir necesitando manualmente eliminar la revisión de todas las dependencias en mi archivo Cargo.toml . ¿Hay algún plan para admitir ignorarlo y permitir solo versiones principales y menores en esta caja?

No tengo tiempo para trabajar en esto, pero puedo revisar un PR si alguien quiere implementarlo.

Tenía un pensamiento para todos en este hilo. Además de la especificación o límite major.minor, ¿ayudaría también tener una opción para usar comodines?

Abrí una posible solución a esto, agradecería los comentarios de los mantenedores, así como de cualquier persona interesada en esta función.

Creo que esto se haría mejor por proyecto o mediante un indicador de línea de comandos cuando agrega o actualiza algo.

Creo que lo más probable es que esto se deba a la política del proyecto del proyecto que agrega las dependencias; o el proyecto del que se depende. Algunos proyectos pueden preocuparse más por la compatibilidad con versiones anteriores que otros y adherirse a ella o rastrearla mejor.

Diferentes usuarios abren la puerta a la posibilidad de que un usuario obtenga un resultado diferente con la actualización de la carga que otro usuario o el CI sin querer y esto podría causar pérdidas innecesarias, especialmente para proyectos que requieren contribuciones de mantenedores incidentales. Especialmente si cada desarrollador trabaja en varios proyectos que tienen diferentes políticas sobre cómo quieren administrar su .toml.

a través de la bandera de la línea de comandos cuando agrega o actualiza algo

Estoy de acuerdo. Una razón clave es cómo Cargo trata a 1.x.y frente a 0.x.y .

• Si especifico foo = "1.1" , eso incluye 1.1.0 , 1.1.1 y 1.99.99 .
• Si especifico foo = "0.1" , eso incluye 0.1.0 , 0.1.1 , pero no 0.99.99 .

En los últimos días, he tenido algunos pensamientos sin refinar sobre esto ...

• Realmente desearía que el ecosistema Rust impulsara más las dependencias mínimas para las bibliotecas.
• Esto se aplica tanto a las versiones como a las características.
• De hecho, me gustaría que cargo add elija el conjunto mínimo de versión / características que funcione para mi código
• Teniendo en cuenta que generalmente agrego la dependencia antes de escribir el código, eso podría ser difícil
• Deberíamos usar restricciones de versión más complicadas con más frecuencia. Por ejemplo, tener la restricción como ^1.2.19, ^1.3.4, ^1.4 no debería ser extraño para nosotros (aunque esto depende de que las bibliotecas mantengan activamente las versiones simultáneas)