3 puntos por GN⁺ 2023-09-07 | 1 comentarios | Compartir por WhatsApp
  • Se eliminaron la opción --argfile, que había quedado sin soporte, y los filtros leaf_paths y recurse_down
  • La imagen de Docker ahora se ofrece en ghcr.io/jqlang/jq en lugar de Docker Hub
  • Se especifican múltiples arquitecturas de Linux, macOS, Windows y Docker como objetivos de compilación para el lanzamiento
  • Se agregó --raw-output0, que permite insertar bytes NUL entre salidas; además, la salida de cadenas que contienen NUL ahora se maneja como error
  • En Windows, se agregó la opción --binary/-b para permitir la salida con fin de línea \n en lugar de \r\n
  • JQ_COLORS ahora permite configurar el color de las claves de objetos, y se respeta la variable de entorno NO_COLOR para desactivar la salida con color
  • Se corrigió el problema con los códigos de salida de la opción --exit-code/-e: ahora devuelve 0 si el último valor de salida es verdadero, 1 si es false o null, y 4 si no hay salida
  • Para preservar la precisión de los literales numéricos, se usan literales decimales; las operaciones de comparación respetan la precisión, pero las operaciones aritméticas pueden truncarse
  • Se agregaron las nuevas funciones integradas pick(stream), debug(msgs), scan($re; $flags) y abs
  • En las sentencias if, ahora se puede omitir la rama else, y un else omitido se trata con el comportamiento de .
  • halt y halt_error fueron modificados para finalizar de inmediato sin continuar con la siguiente entrada
  • Se corrigieron problemas como salida JSON incorrecta con números grandes en algunas plataformas, errores de segmentación al usar libjq con hilos y el crash de assert en --jsonarg
  • CI, Scan Build, el proceso de lanzamiento y la compilación del sitio web pasaron a usar GitHub Actions, y se añadió OSS-Fuzz

1 comentarios

 
GN⁺ 2023-09-07
Opiniones de Hacker News
  • Me gusta mucho JQ porque es excelente
    En nuestro producto (una herramienta para Kafka basada en JVM y navegador) implementamos en Clojure un subconjunto de JQ para que los usuarios puedan transformar/filtrar datos. Fue uno de los trabajos más divertidos entre el código que he escrito, y como me gusta escribir gramáticas, también le agradezco mucho a Instaparse: https://github.com/Engelberg/instaparse
    Al implementarlo descubrí que JQ es LISP-2, y me sorprendió porque no se siente así solo viendo la sintaxis: https://github.com/jqlang/jq/wiki/jq-Language-Description#:~...

    • Simplemente no puedo hacer que me guste jq. En la base de código de mi trabajo hay mucho jq en scripts de bash, también hay algo de código escrito por mí, y cuando es la mejor opción lo uso a regañadientes
      Pero me molestan su sintaxis de consultas poco intuitiva, el hecho de tener que buscar cosas a cada pasito, y que el resultado termine pareciendo un conjuro difícil de descifrar si no eres experto en jq. En general siento un rechazo instintivo a los DSL que van incrustados dentro de strings, como htmx o tailwind
      Aun así reconozco que es software bien hecho y que a veces no hay una mejor alternativa. También es la opción menos mala en el sentido de que, para manejar JSON en bash, es mucho mejor que un monstruo hecho con sed/awk/cut. Pero esos comandos jq incrustados en medio de un script, siempre como strings indescifrables, están cerca de las cosas que no quiero ver en el código, junto con las expresiones regulares. Como alternativa he probado pasar inline Python por pipe dentro de un heredoc, pero eso termina igual de sucio que los scripts de jq
    • También agregué un parser/gramática de JQ a un editor/probador en línea de gramáticas LALR(1)/FLEX: https://mingodad.github.io/parsertl-playground/playground/
      En los ejemplos, selecciona "Jq parser (partially working)" y presiona "Parse" para ver el árbol del parser correspondiente al código en "Input source". Cualquier feedback es bienvenido
    • En la JVM ya existe una implementación de JQ. No está completa al 100%, pero se puede usar: https://github.com/eiiches/jackson-jq
    • jq es muy bueno para permitir que los usuarios transformen sus propios datos. Nosotros también usamos un enfoque parecido: dejamos que los usuarios creen endpoints de webhooks entrantes, envíen datos JSON arbitrarios y configuren mapeos útiles con pruebas de regresión y monitoreo incluidos
      jq simplifica la mayoría de los casos (en la práctica, notación de punto para JSON) y también permite cubrir la larga cola de casos complejos
    • Si el producto ya está en un estado usable, me encantaría probarlo
  • Me gusta jq, pero también uso JMESPath (especialmente con AWS CLI), yq (incluyendo tomlq y xq) y dasel. Es una lástima que hclq esté prácticamente muerto
    https://jmespath.org/
    https://kislyuk.github.io/yq/
    https://github.com/TomWright/dasel
    https://hclq.sh/

    • Hagamos que JSON sea grepeable: https://github.com/tomnomnom/gron
      Llevo años usando jq y siempre termino armando de alguna forma lo que necesito, pero todavía nunca me ha parecido intuitivo. En cuanto se vuelve un poco complejo, es difícil llegar a la solución sin leer bastante la documentación, y me gustaría que fuera más fácil de usar
    • La página del tutorial interactivo de JMESPath es muy buena: https://jmespath.org/tutorial.html
      Me ayudó cuando estaba aprendiendo la sintaxis por primera vez, y todavía vuelvo a consultarla cuando me topo con alguna sintaxis rara
    • Hice una pequeña herramienta para convertir de varios formatos a varios formatos
      Su uso principal es convertir a JSON cosas como CSV, TOML y XML para luego pasarlas por pipe a jq: https://github.com/sentriz/rsl
    • Como alternativas también existen estas herramientas
      https://github.com/kellyjonbrazil/jello
      https://github.com/wwkimball/yamlpath
    • Otra excelente alternativa es JSONPath, que es muy buena, aunque es una lástima que no tenga soporte ni reconocimiento más amplios
      Inspirada en XPath, resulta familiar frente a un DSL completamente nuevo, y creo que su función central es la búsqueda recursiva de claves. Si escribes people..address, encuentra en cualquier parte del JSON todas las claves "address" que estén debajo de "people". Es mi lenguaje de parsing favorito para JSON, y también escribí un artículo sobre cómo usarlo para parsear datasets JSON
      https://github.com/JSONPath-Plus/JSONPath
      https://scrapfly.io/blog/parse-json-jsonpath-python/
  • Si usas jq solo de vez en cuando y cada vez tienes que consultar la documentación, vale la pena probar gron. Es JSON que se puede buscar con grep
    https://github.com/tomnomnom/gron

    • Es simple, pero parece muy útil
      Llevo años usando curl cheat.sh/jq, y me parece que cheat.sh en general es un recurso excelente. Hoy en día probablemente usaría algo como ChatGPT
    • Está realmente muy bien diseñado
      También se pueden hacer cosas como gron | grep | sed | gron -u
    • Siempre sufrí con la sintaxis de jq, pero cada vez me sorprende lo bien que ChatGPT genera el comando correcto cuando le das un JSON de ejemplo
  • Una de las razones por las que me gusta jq, o puedo tolerarlo, es su estabilidad. Los scripts que escribí hace años siguen funcionando exactamente igual hoy
    En cambio, el código que dejé para yq se rompía con frecuencia a medida que yq seguía mejorando de formas no compatibles hacia atrás. No investigué con qué frecuencia hubo cambios así, pero me afectó varias veces en lugares como scripts de CI, donde las versiones de las herramientas base varían y los ritmos de actualización también son distintos
    Por eso siempre agradecí que los mantenedores de jq entendieran la importancia de la compatibilidad hacia atrás. Espero que este anuncio no signifique que esa estabilidad era solo un subproducto accidental del estancamiento, y que al corregir ese estancamiento se sacrifique la estabilidad

  • Además de las herramientas parecidas a jq, hay herramientas interesantes para usar junto con jq, como jo y jc
    https://github.com/jpmens/jo
    https://github.com/kellyjonbrazil/jc

    • También están jless y gron
      Oí hablar de gron por primera vez aquí, pero lo agrego por completitud. Por otro lado, parece que JSON se está volviendo algo así como el formato estándar de salida para herramientas CLI. Lo ideal sería que todas las herramientas CLI ofrecieran una bandera como --json, de modo que jc ya no fuera necesario
      https://jless.io/
      https://github.com/tomnomnom/gron
  • Artículo relacionado del mes pasado, “First release of jq in 5 years”: https://news.ycombinator.com/item?id=36951830
    Soy un fan entusiasta de jq y lo uso siempre

  • Por fin se logró
    Fue realmente genial ver cómo la comunidad unió fuerzas para reclutar nuevos mantenedores y revivir el proyecto. Un agradecimiento especial, en particular, a @stedolan, @itchyny y @owenthereal por sus nombres de usuario de GitHub

  • jq y miller son imprescindibles en mi caja de herramientas, junto con awk y vim
    https://github.com/johnkerl/miller

  • La nueva función integrada pick(stream) agrega la capacidad de emitir una proyección del objeto o arreglo de entrada
    jq -n '{"a": 1, "b": {"c": 2, "d": 3}, "e": 4} | pick(.a, .b.c, .x)'
    Esta función es una verdadera salvación. Gracias a los contribuidores

    • Si no necesitas profundizar, también se puede hacer así
      $ jq -n '{"a": 1, "b": {"c": 2, "d": 3}, "e": 4} | {a, e}'
      {
      "a": 1,
      "e": 4
      }
    • Hace unos días lo instalé desde Git para usar esta función, y es muy útil
    • Es una nueva función realmente excelente. Actualmente parece imposible sin reensamblar primero el stream, así que me gustaría que hubiera una versión de pick que también funcione con datos en streaming
  • También quiero recomendar jaq. Es un clon de jq enfocado en la corrección, la velocidad y la simplicidad
    Implementa solo un subconjunto de jq, pero hasta ahora lo he estado usando con bastante satisfacción: https://github.com/01mf02/jaq