"actualizar" es un alias trivial para "instalar - actualizar". Necesito pensar un poco más
acerca de "actualizar todo"; por un lado, supongo que solo actualizaría los paquetes
dentro de sys.prefix? (es decir, si estás dentro de un virtualenv, no intentaría
actualizar paquetes globales). Esa sería una razón para mudarse
UninstallPathSet.can_uninstall () a una función con un nombre más genérico (o
método de InstallRequirement), por lo que proporciona genérico "¿puedo tocar esto?"
decisiones.

Original Comment By: Carl Meyer

Para que conste, creo que parece una buena idea, dada la capacidad de
desinstalar antes de actualizar. Aunque preferiría una opción --all para
upgrade lugar de un comando propio upgrade-all .

En cuanto a can_uninstall (), estoy de acuerdo ... probablemente sea útil tener
de todos modos a nivel mundial.

Original Comment By: Jannis Leidel

No estoy del todo sin oposición a actualizar como un alias para instalar --upgrade. Pero
parece un poco trivial.

actualizar-todo requiere que averigües qué es "actualizable". Probablemente uno
prerrequisito es que vive en/lib/pythonX.Y/site-packages
(simplemente bajo sys.prefix no es suficiente).

Si permitimos algo como "importación zip" (para traer un paquete del padre
entorno en un entorno virtualenv) entonces probablemente paquetes en ese
el entorno principal no debe actualizarse, pero no está 100% claro que es lo que
el usuario esperará.

Intenté desinstalar un paquete editable con "desinstalar pip" y
razonablemente ofrecido para eliminar el .egg-link y actualizar easy-install.pth. Pero
no podría haber actualizado razonablemente el paquete, por lo que can_uninstall es algo
diferente de can_upgrade.

Original Comment By: Ian Bicking

Sí, tienes razón en que can_uninstall y can_upgrade son diferentes.

Creo que si tuviéramos "importación de pip" no querríamos actualizar
paquetes globales importados; pero (junto con los editables) podría valer la pena "no
actualizando esta "advertencia en la consola.

Original Comment By: Carl Meyer

+1 para este error

Original Comment By: smyrman

El número 167 se marcó como un duplicado de este problema.

Original Comment By: Carl Meyer

1

(echo pip; pip freeze | awk 'BEGIN{FS="=="}{print $1}') | xargs sudo pip

instalar -U

Esto debería actualizar todos los paquetes instalados (incluido el propio pip). Si
lo ejecuta en virtualenv, probablemente no necesite usar sudo.

Por supuesto, tiene un alto riesgo de falla, si se actualiza uno de los paquetes
falla todo el proceso fallará (es similar a port upgrade outdated en
MacPorts).

Original Comment By: Tomasz Elendt

+1 para mejorar --todos

¿Por qué en este momento todas las facilidades de administración de módulos de Python tienen que apestar? Porque no
uno proporciona actualización + actualización simple --todos los comandos?

Original Comment By: Anonymous

No me importaría intentar una implementación, pero primero algunas preguntas.

¿Es el consenso general que un nuevo comando de "actualización" que admita un '--todos'
¿Se agregará la opción a pip?

La ejecución de la actualización de pip solo debería afectar el entorno en el que se está ejecutando.
ejecutar desde un virtualenv, entonces solo se actualizarán los paquetes locales a ese env;
lo mismo para los no virtualenv

Original Comment By: Kelsey Hightower

Kelsey: de mi lectura de la discusión anterior, no veo ninguna
oposición a ella. Creo que es una buena adición para hacer. El caso del borde principal es
instalaciones de VCS editables: como sugirió Ian, creo que un comando de "actualización"
no debería tocar esos. Definir lo que significa "actualización" en el contexto de todos los
posibilidades editables (incluidos repositorios locales instalados editables que no tienen
origen) sería casi imposible, creo, e incluso si algunos trabajos a medias
definición se podría armar, solo aumentaría el mantenimiento
carga de los ya frágiles backends de VCS. Pero para los no editables, opte por
¡eso!

Original Comment By: Carl Meyer

Carl: Genial, empezaré y actualizaré este ticket con los resultados.

Original Comment By: Kelsey Hightower

Mientras trabajaba en el comando de actualización, surgieron las siguientes preguntas:

• ¿Qué métodos deben soportar la actualización de pip para especificar qué paquetes
  ¿ascender de categoría? ¿Debemos admitir un archivo de requisitos?
• ¿Cómo debe manejar pip upgrade los paquetes que aún no están instalados?
  ¿Debemos instalar los paquetes que faltan?

casos de uso de actualización de pip y cómo manejarlos:

# pip upgrade some_installed_package

Try and locate a package that satisfies the requirement. If the

no se cumple el requisito de actualizar a la versión solicitada. Esto incluye
actualizar a una versión anterior.

# pip upgrade --all

Locate all installed packages (non-editables) and update them to a new

versión si está disponible.

# pip upgrade some_other_package

Warning: some_other_package not installed, use pip install

algún_otro_paquete.

Mis objetivos son mantener el comando de actualización realmente simple. Puedes actualizar
paquetes específicos no editables para una versión nueva o anterior; o puedes actualizar
todos los paquetes no editables a una versión más reciente.

¿Pensamientos?

Original Comment By: Kelsey Hightower

Creo que "pip upgrade" debería ser un alias exacto para "pip install --upgrade" como
ahora funciona. Eso implica que sí, instala los paquetes solicitados si
no están instalados y sí, acepta archivos de requisitos con -r. Su deber
ser factible casi sin código nuevo.

Actualización: todo requerirá algún código para encontrar la lista de
paquetes actualizables instalados; entonces debería pasar esa lista para instalar
- actualizar, como arriba.

Original Comment By: Carl Meyer

Carl, gracias por la respuesta. Prácticamente he tomado el camino que tienes
descrito. Más tarde hoy debería poder publicar algunos ejemplos de ejecuciones.

Original Comment By: Kelsey Hightower

Terminé la mayor parte del código, solo queda un poco de pulido antes de publicar el código
para la revisión.

HACER:

• Pruebas
• Archivo de requisitos de filtro; agregar no editables a la lista de paquetes para
  ascender de categoría.

Ejecutando pip usando el comando de actualización

# pip upgrade --all

All packages up-to-date


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML

Package updates available:

  PyYAML: N/A (installed) 3.09 (latest)

Downloading/unpacking PyYAML

  Downloading PyYAML-3.09.tar.gz (238Kb): 238Kb downloaded

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  PyYAML: 3.09 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML==3.08

Downloading/unpacking PyYAML==3.08

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

Package updates available:

  PyYAML: 3.08 (installed) 3.09 (latest)

Downloading/unpacking PyYAML

...

Successfully installed PyYAML

Cleaning up...

  Removing temporary dir /root/upgrade_env/build...

Original Comment By: Kelsey Hightower

Último conjunto de preguntas (espero):

• ¿Debería pip actualizar analizar el archivo de requisitos y filtrar?
  editables? ¿Qué pasa con los requisitos de URL?

Para cada elemento no editable en el archivo de requisitos, me gustaría marcar el
índices para una versión posterior. Para hacer esto, necesitaría reunir los
información del paquete de cada línea en el archivo de requisitos.

Cualquier consejo es bienvenido (actualmente busca en pip.req.parse_requirements )

• ¿La actualización de pip debería buscar en los índices una versión posterior para instalar?
  (Esto es lo que estoy haciendo ahora). Si no, ¿cómo debería determinar el comando de actualización?
  si hay una actualización?

En este momento, solo estoy agregando paquetes a la lista de actualizaciones cuando:

• El paquete no esta instalado
• Hay una actualización disponible (versión posterior de los índices) y no explícita
  se solicitó la versión
• La versión solicitada es diferente a la instalada (Versión miss
  coincidir).
• Aplazo el archivo de requisitos al comando de instalación hasta que filtre
  los requisitos no editables.

Original Comment By: Kelsey Hightower

Carl, después de volver a leer tu publicación, parece que estoy haciendo más de lo que
requerido. Subiré mi rama para que puedas echarle un vistazo. Pude haber ido
por la borda comprobando PyPi para una versión posterior.

Original Comment By: Kelsey Hightower

Carl, después de volver a leer tu publicación, parece que estoy haciendo más de lo que
requerido. Subiré mi rama para que puedas echarle un vistazo. Pude haber ido
por la borda comprobando PyPi para una versión posterior.

Original Comment By: Kelsey Hightower

Sí, parece que estás haciendo más de lo necesario. Instalación de pip
--upgrade hace todo lo que ya estás discutiendo (buscando más
versiones, etc); toda "mejora de pip" debería ser como un pase de dos líneas
todo terminado para instalar pip --upgrade.

El único código real que se escribirá aquí es el código para "actualizar --todos" para obtener
la lista completa de paquetes actualizables instalados en el entorno.

Original Comment By: Carl Meyer

Sí, lo sabía. Bueno, aprendí mucho. Aunque no es necesario para esto
tarea, me gusta la capacidad de mostrar lo que está instalado y disponible durante la
proceso de actualización (consulte la ejecución de prueba más arriba).

Volveré a factorizar y limpiaré las cosas. Los cambios actuales en mi bifurcación en el
rama de comando de actualización.

https://bitbucket.org/khightower/pip/changeset/2bdc202b446c

Original Comment By: Kelsey Hightower

He eliminado el comando de actualización según las sugerencias de Carl (fui demasiado lejos
en primer lugar). No estoy seguro de que me gusten los resultados, pero se instala en espejo- actualización en funcionalidad.

Parece que pip intenta descargar y reinstalar el paquete incluso cuando el
El paquete ya está instalado y actualizado. Peor aún con la actualización--todos , pip reinstala todo, incluido el propio pip. ¿Es así como pip?
la actualización debería funcionar? Si es así, casi he terminado :)

Ejecutando el comando de actualización de pip

# pip upgrade Mako


Downloading/unpacking Mako

  Running setup.py egg_info for package Mako


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

Downloading/unpacking MarkupSafe>=0.9.2 (from Mako)

  Running setup.py egg_info for package MarkupSafe


Installing collected packages: Mako, MarkupSafe

  Found existing installation: Mako 0.3.6

    Uninstalling Mako:

      Successfully uninstalled Mako

  Running setup.py install for Mako

    changing mode of build/scripts-2.7/mako-render from 644 to 755


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

    changing mode of /root/upgrade_env/bin/mako-render to 755

  Found existing installation: MarkupSafe 0.11

    Uninstalling MarkupSafe:

      Successfully uninstalled MarkupSafe

  Running setup.py install for MarkupSafe


    building 'markupsafe._speedups' extension

    gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall

-Wstrict-prototypes -fPIC -I / opt / OpenPython-2.7.1 / include / python2.7 -c
markupsafe / _speedups.c -o build / temp.linux-x86_64-2.7 / markupsafe / _speedups.o

    gcc -pthread -shared

build / temp.linux-x86_64-2.7 / markupsafe / _speedups.o -o
compilación / lib.linux-x86_64-2.7 / markupsafe / _speedups.so

Successfully installed Mako MarkupSafe

Cleaning up...

Original Comment By: Kelsey Hightower

Kelsey: Sí, hay algunos errores con install --upgrade; en particular tu
identificado # 13 , que vuelve a descargar y reinstalar incluso los paquetes que
ya están actualizados. La solución no es hacer algo diferente
con el nuevo comando de actualización, es para corregir el error en install --upgrade.

Con la actualización --todos, me parece razonable que pip se actualice solo
también, si hay una actualización disponible. (Personalmente, nunca usaré la actualización
--todos, así que no sé qué comportamiento querrían de él las personas que lo usarán
aquí). Obviamente, una vez más, se comportaría mejor si se arreglara el número 13 .

Original Comment By: Carl Meyer

Gracias Carl, terminaré esto y comenzaré a mirar el n . ° 13

Original Comment By: Kelsey Hightower

Si alguien tiene tiempo, revise mi rama de comando de actualización. Mientras tanto
Trabajaré en pruebas unitarias que intentan no duplicar las existentes para el
instalar comando.

https://bitbucket.org/khightower/pip/src/fa7b2a6d2bf1/pip/commands/upgrade.py

Original Comment By: Kelsey Hightower

@vababiy : he probado su comando de actualización, pero parece que no funciona correctamente ... Así que hice uno propio:

https://github.com/pypa/pip/pull/313
https://github.com/jedie/pip/commit/7a31d70dabe0e809184fe1b5280c5a7ccf420dd5

@jedie, creo que @vbabiy migró su comentario aquí, pero no escribió el comando de actualización.

+1

@kelseyhightower ¿ Algún progreso?

+1

+1!

+1

+1

Deje de comentar sobre el problema con solo un "+1". Somos conscientes de que se desea la función, sin embargo, enviar spam a nuestra bandeja de entrada no ayuda.

En cambio, estaría encantado de ver un comentario "¡parche listo!" ;)

+1

¿Alguna actualización? ¿Hay algún plan para agregar esto, ya tiene 3 años?

@pradyun Ver https://github.com/pypa/pip/issues/59#issuecomment -9418336

+1

Pensé que esto ya estaba fusionado. Puedo desempolvar mi habilidad con la pitón y darle otra oportunidad.

¿Esta función se incluirá en 1.5? No puedo encontrar ninguna referencia a él en la documentación 1.5 ...

+1

¿Cuál es el estado de este problema?

Está bloqueado por # 988

Si es realmente importante para usted, existen soluciones para actualizar todos los paquetes; Reuní un script para hacerlo en paralelo (https://github.com/ariccio/update-pip-packages), y hay muchas otras implementaciones en otros lugares de Internet.

Este problema tiene dos partes. upgrade-all puede estar bloqueado por gh-988, pero no veo cómo se bloquea upgrade . pip upgrade puede ser un alias simple para pip install -U --no-deps . Esto resolvería uno de los principales problemas de usar install_requires en archivos setup.py. ¿No se puede hacer esto pronto?

pip upgrade puede ser un alias simple para pip install -U --no-deps

de la descripción:

pip upgrade sería como pip install --upgrade excepto que no sería recursivo por defecto (y ofrecería una opción --recursive ). Su comportamiento predeterminado recursivo actual ha causado dolor a muchos (# 304). En cuanto a cómo hacer actualizaciones no recursivas ahora, consulte aquí

eso no es pip install -U --no-deps

“No recursivo” en este contexto no significa simplemente –no-deps . Una actualización no recursiva actualizará las dependencias, pero solo si es necesario para cumplir con los requisitos de los padres.

@qwcode gracias por la aclaración. Entonces eso no es lo que me importa. ¿Por qué llamarías a esto "no recursivo", sigue siendo recursivo pero un poco más inteligente / diferente?

Tenía la impresión de la discusión en gh-571 que realmente no recursivo era el valor predeterminado deseado. Eso ciertamente tendría sentido y evitaría tener que escribir siempre código como https://github.com/scipy/scipy/commit/8e7ee0c4b3c16.

en el # 571, "no recursivo" no es --no-deps es el recursivo "más inteligente / diferente" como usted dice.
observe la prueba test_upgrade_with_needed_recursive_upgrades() de ese PR.

sin quedarse atascado en los términos, hay 3 cosas:

1. la "actualización más inteligente / diferente", es decir, del tipo que ocurre en el empaquetado del sistema operativo que también puede implicar dependencias de actualización (pero solo si realmente _necesitan_ actualización).
2. lo que hace ahora pip, que es actualizar todas las dependencias, independientemente de la necesidad o resolución de conflictos.
3. --no-deps

algunas formas posibles de distinguir el n. ° 1 y el n. ° 2

1. "no recursivo" frente a "recursivo"
2. "normal" frente a "recursivo"
3. "solo si es necesario recursivo" frente a "hacerlo independientemente del modo recursivo"

Estoy abierto a usar los mejores términos ... pero no estoy seguro de cuáles son.

Creo que me gusta esta frase "recursiva sólo si es necesario". tal vez debería usar eso aquí en los documentos:

A mí también me gusta. Si describiera las tres opciones juntas como

a. non-recursive
b. only if needed recursive
c. recursive (or "do it regardless recursive")

eso estaría claro.

Entonces querrás elegir buenos valores predeterminados. Tanto para upgrade como para install -U , (a) o (b) podrían tener sentido. Prefiero fuertemente (a), pero (b) también tiene sentido dado que eso es lo que hace el empaquetado del sistema operativo.

(c) no tiene ningún sentido por defecto, así que reconsidere su decisión de no cambiar install -U .

Para aclarar por qué prefiero (a): un usuario desprevenido que quiera (b) y obtenga (a) tendrá que leer un mensaje que diga "non-recursive upgrade can't satisfy all dependencies, please use only-if-needed recursive" , lo cual no es gran cosa. Si el valor predeterminado fuera (b), ese usuario desprevenido puede terminar con una actualización o incluso una instalación defectuosa de un paquete que realmente no quería tocar. Eso puede llevar horas o incluso días para recuperarse.

(c) no tiene ningún sentido por defecto, así que reconsidere su decisión de no cambiar install -U

la razón para dejar install -U solo es solo por razones de compatibilidad, y luego, eventualmente, desaprobarlo.

Si el valor predeterminado es (b), ese usuario desprevenido puede terminar con una actualización
o incluso una instalación defectuosa de un paquete que realmente no quería tocar

Si un usuario desea que las actualizaciones de dependencia necesarias no se cumplan, debería solicitarlas específicamente usando --no-deps . no hay forma en mi mente que pueda ser la predeterminada. ese comportamiento haría más daño de lo que está considerando (que es el caso atípico). Una y otra vez, los usuarios se quedarían sin las actualizaciones de dependencia que necesitaban.

Desaprobar install -U suena bien.

Estoy de acuerdo (b) es más común que (a). Incluso si fuera 100 veces más común, que no es el caso, creo, más daño no es cierto. Leer un mensaje de error claro antes de que comience la instalación es mucho mejor que, por ejemplo, un error de compilación a la mitad, que en mi humilde opinión (a) sigue siendo el mejor valor predeterminado.

Confiar en --no-deps puede estar bien para usuarios muy experimentados, pero los nuevos usuarios solo lo aprenderán después de que las cosas salgan mal.

De todos modos, parece que no podré convencerte. Luego de vuelta al manual

try:
   import dependency
except ImportError:
    install_requires.append('dependency')
else:
    if dependency.version < 'x.y.z':
        raise ValueError('Please upgrade dependency to x.y.z')

está.

@qwcode gracias por la explicación detallada. Espero que esto avance en el futuro cercano; solo si fuera necesario, la recursividad sería una gran mejora con respecto al comportamiento actual.

Pasando de nuevo muchas horas esta semana resolviendo problemas sobre por qué no usamos install_requires , estoy agregando un: +1: para alejarme del comportamiento actual.

¿Hay alguna actualización sobre este tema?

Tenemos ahora 2015 y todavía necesito copiar de pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U stackoverflow

Sí, básicamente todo el progreso está relacionado con este problema.

GitHub hace un buen trabajo al hacer referencias cruzadas. ¡Se puede hacer clic en todos ellos! (¿Estoy seguro de que sabes esto?)

Sí, seguro, pero no entiendo la razón por la que esta función "simple" tiene tanto retraso.

¿Cuál es la razón para esto?

Soy 16.04.2015 um 05:28 schrieb Alexander Riccio [email protected] :

Sí, básicamente todo el progreso está relacionado con este problema.

GitHub hace un buen trabajo al hacer referencias cruzadas. ¡Se puede hacer clic en todos ellos! (¿Estoy seguro de que sabes esto?)

-
Responda a este correo electrónico directamente o véalo en GitHub.

En cuanto a pip upgrade-all , el consenso parece ser esperar el trabajo relacionado con # 988 antes de lanzar cualquier comando nuevo y brillante que aún tenga fallas y pueda ser peligroso para un entorno de trabajo. Una versión simple de upgrade-all que no resuelve adecuadamente los requisitos puede romper fácilmente los paquetes existentes

+1

¿Qué vas a hacer a lo largo de 4 años?

+1

+1

+1

@muhasturk Actualmente, esperando ... https://github.com/pypa/pip/issues/59#issuecomment -93646462

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 ... perdón por el spam, pero ejecutar pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U duele!

+1

En caso de que alguien esté interesado en trabajar en esto, creo que los comentarios anteriores son algo confusos: AFAICT, el estado real es que pip upgrade-all está actualmente bloqueado por la necesidad de un sistema de resolución de dependencias adecuado, pero pip upgrade podría implementarse en cualquier momento. Si alguien quiere trabajar en esa parte, sería increíble :-).

(Vea también el hilo que comienza aquí y la respuesta de @dstufft aquí y comente aquí de acuerdo con la evaluación anterior).

aquí hay otra discusión de la lista pypa-dev de hace un año (que coincide en que pip upgrade FOO podría hacerse ahora) https://groups.google.com/forum/#!searchin/pypa -dev / pip $ 20 actualizar / pypa-dev / vVLmo1PevTg / oBkHCPBLb9YJ

¡Gracias @qwcode! También acabo de ver la nueva descripción en https://pip.pypa.io/en/latest/user_guide/#only -if-need-recursive-upgrade, eso es útil.

+1

Si no me equivoco:

Si xxx no está instalado:

• pip upgrade xxx sería equivalente a pip install xxx
• pip upgrade xxx --recursive sería el equivalente a pip install xxx --upgrade

Si xxx está instalado:

• pip upgrade xxx --recursive aún sería el equivalente a pip install xxx --upgrade (por diseño)
• pero actualmente no hay equivalente para pip upgrade xxx , esto podría ser pip install xxx --upgrade-only-if-needed/--upgrade-lazy

¿No está claro cuál es el valor agregado de un nuevo comando al agregar una nueva opción a pip install ?

¿No está claro cuál es el valor agregado de un nuevo comando al agregar una nueva opción a pip install ?

El comportamiento predeterminado pip install -U es inaceptable para muchos proyectos. Vea mi comentario anterior (https://github.com/pypa/pip/issues/59#issuecomment-52434862). Y aquí hay una explicación más extensa: http://article.gmane.org/gmane.comp.python.distutils.devel/24218

Si es inaceptable, entonces supongo que planea cambiar el uso de la instalación de pip: ¿actualizar a la actualización de pip?
¿Por qué no podría cambiar su instalación actual de pip --upgrade use a pip install --upgrade-only-need?
¿Qué proporciona un nuevo comando que no pueda ofrecer una nueva opción?

Todo está pavimentando caminos para vacas. No es el uso personal de @rgommers lo que le preocupa, son sus usuarios. La gente va a llegar a la respuesta "obvia" si no la conocen mejor y ahora mismo la respuesta obvia es problemática para algunas partes importantes del ecosistema de Python.

Por supuesto. La gente no lee documentos. De hecho, arreglaremos todos los documentos de instalación que podamos encontrar, pero tan pronto como un usuario vea -U o --upgrade eso es lo que usará. La posibilidad de que las personas usen --no-deps o --only-as-needed o lo que sea antes de haber sido gravemente mordidos es remota.

¿Por qué no podría cambiar su instalación actual de pip --upgrade use a pip install --upgrade-only-need?

Y para ser claros: evitamos pip install --upgrade ahora _y_ no usamos install_requires por esto. Eso es lo malo que es.

Creo que hay un pequeño malentendido aquí: IIUC @xavfernandez está de acuerdo con agregar la funcionalidad de actualización no recursiva, su pregunta es por qué la interfaz de usuario de esa funcionalidad debe ser como un nuevo comando de nivel superior en lugar de una nueva opción para pip install .

@xavfernandez : Tenga en cuenta que actualmente hay una discusión en el # 3194 sobre cuál sería la interfaz de usuario más clara para esta funcionalidad.

(Y pip install -U quedará obsoleto y luego se eliminará, por lo que responde a la pregunta sobre cómo los usuarios sabrán que no deben usarlo :-)).

Creo que hay un pequeño malentendido aquí.

Estoy bastante seguro de que no lo hay. Y sí, solo estamos debatiendo la interfaz de usuario. Pero eso es importante.

Sí, solo estoy debatiendo la interfaz de usuario y estoy de acuerdo en que es importante. Pero lo que veo venir es que una vez que finalice la actualización de pip, no habrá razón para seguir usando la instalación de pip ...
Y la interfaz de usuario para instalar cualquier paquete se convertirá en "pip upgrade foo"

no habrá razón para seguir usando pip install

¿Cuál es un problema por qué? El problema (al menos para @qwcode en los comentarios anteriores) con cambiar pip install --upgrade al comportamiento correcto es romper la compatibilidad con versiones anteriores. Entonces pip upgrade es la forma de evitar esa ruptura _y_ obtener el valor predeterminado correcto.

@rgommers : para ser justos, _ tendremos_ algunas preguntas confusas distintas de cero sobre por qué me dijiste que ejecutara pip upgrade foo cuando ni siquiera tengo foo instalado, no lo hizo no funciona (discuta de un lado a otro hasta que realmente intenten ejecutar el comando en lugar de asumir que no funcionará y fingir que lo ejecutaron)

En # 3194 hice el comentario de que tal vez la forma correcta de avanzar es simplemente eliminar --upgrade de pip install , hacer que pip install siempre haga una actualización de los elementos nombrados explícitamente, y por defecto a una estrategia de actualización mínima para dependencias con una bandera --recursive para obtener el comportamiento actual en la actualización.

Creo que estoy de acuerdo en que siento que con # 3194 la UX predeterminada se convertirá en pip upgrade foo lugar de pip install [-U] foo . El único problema que tengo con eso es que creo que es un poco confuso tener los dos comandos y, dado que creo que pip upgrade sería el "correcto" para que la gente lo use, creo que es horrible tener lo obvio nombre sea el nombre incorrecto.

Tengo migraña, por lo que también podría no estar pensando del todo correctamente, pero siento que descubrir cómo manejar el camino de la desaprobación hacia esa sugerencia podría ser el camino correcto a seguir.

Bueno, no voy a argumentar que la compatibilidad hacia atrás es importante aquí. Siempre estuve a favor de cambiar el comportamiento de pip install --upgrade . Es el más limpio y el costo parece pequeño. Pero me pareció que fue vetado por @qwcode , por lo que pip upgrade fue la mejor opción (y ya lo aprobaron los desarrolladores de pip hace un año).

Si ahora queremos volver a cambiar los valores predeterminados / comportamiento de pip install , genial.

@dstufft eso tiene mucho sentido para mí: el dolor de cabeza no puede ser tan fuerte :)

Dado que aceptamos desaprobar --upgrade, podríamos mantener eso y agregar dos opciones para pip install: --upgrade-only-required y --upgrade-eager, el segundo es un alias para el obsoleto --upgrade

@xavfernandez Forzar las decisiones a los usuarios es un poco horrible, creo. A menos que entienda los problemas bastante sutiles, no estoy seguro de saber realmente si quisiera --upgrade-only-needed y --upgrade-eager .

@xavfernandez, ¿estás proponiendo que en la situación final el comando sea pip install --upgrade-only-needed ? Parece feo.

Sería mucho mejor tener algo que se asigne al equivalente de la versión semántica disponible en, por ejemplo, npm , hex o Cargo . Eso ciertamente necesitaría un ajuste en el contexto de Python, ya que (a) las versiones de PEP 440 no se asignan ni pueden mapear con precisión al control de versiones semántico y (b) la comunidad de Python en general no necesariamente se adapta al control de versiones de tipo semántico en sus lanzamientos, incluso dentro de PEP 440.

No obstante, algo en ese sentido sería muy útil, al igual que la noción de fijar una versión específica.

Dadas las limitaciones, a corto plazo una opción viable podría ser hacer algo análogo a los comandos upgrade y upgrade --all homebrew, donde este último simplemente sigue adelante con la actualización de todo (potencialmente con una advertencia la primera vez). ).

Sin embargo, a largo plazo, sería enormemente útil crear convenciones compartidas sobre lo que significan las versiones en la comunidad de empaquetado de Python, y construir soporte pip torno a eso podría ser una gran parte de esto.

La ruta de migración obvia sería:

pip versión X:

• agregar opciones pip install --eager , pip install --no-eager , donde --eager significa que para los requisitos sin restricción de versión adjunta, intentamos instalar la última versión incluso si ya hay alguna versión instalada, y --no-eager significa que estamos satisfechos si se instala alguna versión
• también agregue la opción pip install --eager-recursive con la semántica actual -U
• --no-eager sigue siendo el predeterminado
• si no se especifica ninguna de estas opciones, y pip install se pasa un requisito sin número de versión adjunto, y este requisito ya está satisfecho, entonces genera una advertencia diciendo que no actualizamos su paquete, pero en el futuro lo haremos, por lo que debe usar --no-eager si desea mantener el comportamiento actual
• agregue una advertencia de depreciación a pip install -U refiriendo personas a pip install --eager-recursive

pip versión Y:

• cambie el valor predeterminado de pip install a --eager

pip versión Z:

• eliminar pip install -U

Hice versiones diferentes de Y y Z porque estoy ansioso por --eager así que tal vez podríamos hacer ese cambio en un horario más agresivo, mientras mantenemos pip install -U por un momento, ya que mucha documentación ya se refiere a él, y no causa ningún daño. Pero obviamente Y = Z es una opción :-)

@chriskrycho : Todo eso suena genial, pero esta discusión trata sobre cómo manejar la situación en la que el usuario está tratando explícitamente de solicitar una actualización a la última versión de un paquete, que es una situación que comúnmente ocurre hoy y no tenemos una buena respuesta a. No sé si hay un error abierto que solicita soporte para anclar todavía, pero si no es así, ¿quizás deberías iniciar uno?

Absolutamente; Mi punto (que ahora reconozco que no pude hacer explícito) fue simplemente señalar que cualquier solución que se adopte aquí no debería entrar en conflicto con tomar ese tipo de táctica en el futuro.

¿Cuál es la ruta de desaprobación normal de pip? ¿Basado en tiempo / versión? ¿Cuánto tiempo debe dejar de estar disponible algo antes de su eliminación?

Por cierto, creo que "ansioso" es una palabra que los usuarios no entenderán. recursivo / solo cuando sea necesario recursivo / siempre recursivo es mucho más claro.

Normalmente hacemos un ciclo de obsolescencia de dos versiones.

¿Versiones principales que supongo? Las versiones menores son realmente rápidas (7.0 -> 7.1 fue un mes). Por lo general, medio año entre las versiones principales, por lo tanto, ¿1 año de advertencias de obsolescencia?

Sí, lo siento. Versiones principales. Si desaprobamos algo en 8.x, será una advertencia amarilla para el resto de 8.x, una advertencia roja para todo 9.xy se eliminará en 10.x.

Gracias.

Copiar comentario @dstufft 's de https://github.com/pypa/pip/pull/3194#issuecomment -152357835 aquí, porque es el mejor resumen de la situación:

Supongo que el tl; dr es que creo totalmente que tenemos que arreglar el comportamiento "predeterminado", solo tenemos que conformarnos con la implementación específica para solucionarlo:

1. Mantenga la UX be pip install - actualice y cambie el valor predeterminado.
2. Mueva la UX a la actualización de pip con el valor predeterminado "correcto" y agregue un indicador --recursive.
3. Mueva la UX para instalar pip, elimine --upgrade y agregue una marca --recursive.

Mi 2c:

(1) tiene una buena experiencia de usuario, se puede hacer ahora
(2) UX un poco peor (tener tanto install como upgrade ), se puede hacer ahora
(3) la segunda mejor experiencia de usuario, cambiar pip install se puede hacer ahora, eliminar --upgrade solo se hará en 10.0 (obsoleto en 8.0 y 9.0).

No veo por qué el problema de compatibilidad hacia atrás (que debería ser menor de cualquier manera) para (1) sería peor que para (3). Entonces (1) parece lo mejor. Si bw compat es una preocupación real, elija (2).

De todos modos, es hora de terminar la noche.

Creo que la diferencia entre (3) y (1) se reduce a si pensamos que instalar o actualizar es la operación más común que la gente desea; de ser así, probablemente sea mejor convertirlo en el comando corto como en (3). Sin embargo, no es gran cosa.

Por cierto, creo que "ansioso" es una palabra que los usuarios no entenderán. recursivo / solo cuando sea necesario recursivo / siempre recursivo es mucho más claro.

No estoy en absoluto apegado a la ortografía "ansiosa", pero recursivo simplemente no tiene sentido como la palabra principal para activar y desactivar las actualizaciones. Supongo que podríamos usar --upgrade-non-recursive (futuro predeterminado), --upgrade-recursive , --upgrade-none o menos, pero todavía pone en primer plano el confuso comportamiento recursivo (no tendría idea de qué --upgrade-non-recursive significaba si no estaba familiarizado con el extraño comportamiento recursivo de la opción -U heredada), y --upgrade-none suena engañosamente como que se asegurará de que no se actualicen paquetes incluso si es necesario para preservarse. consistencia.

Si seguimos esta ruta, no me importa mucho el período de ortografía, ya que la opción que la mayoría de la gente quiere sería la predeterminada y las opciones de actualización recursiva y no actualización serían cosas especiales que rara vez se usan que la mayoría de los usuarios podría ignorar.

--upgrade-non-recursive (futuro predeterminado) ...

por supuesto que es confuso. pero está ignorando la opción más simple, que es no proporcionar este interruptor en absoluto. porque si es idéntico al comportamiento predeterminado, ¿por qué lo necesitarías?

Creo que la diferencia entre (3) y (1) se reduce a si pensamos que instalar o actualizar es la operación más común que la gente quiere

Esperaría "instalar". Al menos sé que solo actualizo paquetes que uso mucho a propósito, pero cada vez que veo algo interesante / útil es simplemente pip install pkgname distancia.

(aunque no es que sea un usuario típico, por lo que mis expectativas podrían ser incorrectas)

Creo que estaría a favor de:

• No hay pip upgrade nuevos que serían un alias para pip install
• pip install (sin la opción --upgrade* ) el comportamiento no cambia
• pip install --some_name solo intentaría actualizar los paquetes especificados en la línea de comando y no sus dependencias
• pip install --some_other_name para mantener disponible el antiguo comportamiento --upgrade

Y luego hay dos opciones:

• no necesitamos / queremos una ruta de desaprobación, entonces --some_name puede ser --upgrade y --some_other_name puede ser lo que parezca mejor
• necesitamos una ruta de desaprobación, luego --upgrade en pip8 dará una advertencia diciendo que está desaprobado y deberíamos usar --some_other_name para mantener el comportamiento anterior o, más bien, cambiar a un --some_name más seguro para actualizar solo los paquetes especificados y sus dependencias solo si es necesario.

En este segundo caso, --some_name no puede ser --upgrade . Entonces tenemos que encontrar dos nuevos nombres de opciones para --some_name y --some_other_name

Me parece que la "mejor" solución obvia es mantener pip install como comando y cambiar el comportamiento de --upgrade para no actualizar las dependencias. El único problema real es la compatibilidad con versiones anteriores, pero ¿hemos tenido _algunos_ usuarios que argumentan que confían en el comportamiento actual?

Personalmente, me inclino por la vista "hazlo y hazlo con la compatibilidad con versiones anteriores". Podría argumentar que el comportamiento actual es en realidad un error, y este cambio sería una corrección de errores. Pero sí creo que en algún momento debemos poder decir que hemos llegado a un buen punto y vamos a tener una visión mucho más estricta sobre la compatibilidad con versiones anteriores. No creo que estemos en ese punto todavía, pero es posible que debamos comenzar a dejar que la comunidad sepa lo que creemos que aún se debe hacer para llegar a ese punto.

Todavía existe (IMO) la necesidad de algún tipo de comando pip install --upgrade :all: para actualizar todos los paquetes instalados. Pero esa es una nueva funcionalidad, por lo que no es relevante aquí.

El comportamiento actual _es_ útil, particularmente para proyectos como Pyramid, que no son un solo proyecto, sino que en realidad son una colección de proyectos. Sería útil poder hacer algo como pip install --upgrade-recursive Pyramid para actualizar Pyramid y todas sus dependencias a la última versión. Eliminar todo lo recursivo significa que tengo que rastrear manualmente todas las dependencias y hacer pip install --upgrade Pyramid dep1 dep2 dep3 dep4 (con todo el árbol de dependencias) o necesito hacer un pip install --upgrade :all: hipotético y posiblemente actualizar más cosas de las que realmente quiero actualizar. En el # 3194, al menos un usuario mencionó que le gustaría que el comportamiento actual estuviera disponible a través de una bandera porque es útil en algunos casos.

¿Hay alguna razón (aparte de la compatibilidad con versiones anteriores) para no hacer que pip install implícitamente haga una actualización "mínima"? Estoy tratando de averiguar en qué situación realmente quisiera que solo se instale y no haga una actualización (IOW, una en la que la última versión está bien si aún no la tengo instalada, pero no si la tengo instalado) y tengo un problema para pensar en un caso en el que me gustaría tener el comportamiento actual.

Me gusta la idea de un comando _new_ pip upgrade [--recursive] como en # 3194 (y en desuso install --upgrade )

Me preocupan las opciones que rompen la compatibilidad o tienen obsolescencias complejas o que cargan un pip install que ya tiene muchas opciones con más cambios o complejidad. Además, personalmente me atrae un comando de "actualización" que, por defecto, solo actualiza de manera similar a cómo funcionan las herramientas de distribución. "instalar" instalaciones y "actualizar" actualizaciones ...

Me inclino por la vista "hazlo y hazlo con la compatibilidad con versiones anteriores"

No lo soy:) al menos para una lógica central como esta.

hacer que pip install implícitamente haga una actualización "mínima"

para mí, considerando que esto parece una tontería, ¿verdad? considere el número de fallas de compilación automatizadas que podrían ocurrir. Además, la gente queda atrapada en un modelo conceptual en cierto punto sobre lo que es pip install ... y esto forzaría una recarga de un nuevo modelo mental. a la gente no le gusta eso.

@qwcode No lo sé, no creo que esté bien. El principal problema con pip upgrade es que eliminas la forma para que la gente diga "dame la última versión de esto independientemente de si está instalada o no" o tienes dos comandos que hacen casi completamente lo mismo ( pip install y pip upgrade ). Puede haber algunas roturas a corto plazo, pero estoy un poco preocupado por el modelo mental real de pip upgrade porque puedo ver que la gente simplemente reemplaza sus instrucciones de instalación de pip install foo a pip upgrade foo (¡¿pero por qué estoy actualizando algo que aún no he instalado ?!).

Er, creo que estaría bien, quiero decir.

amplia extensión reemplazando sus instrucciones de instalación pip install foo a pip upgrade foo

Roger, por eso creo que upgrade debería actualizarse. en cuanto al "turd" --fill-in-missing , no estoy atascado en eso, así que no me interprete en el sentido de que tengo que tener eso, pero vea más abajo.

"Dame la última versión de esto, independientemente de si está instalada o no"

• si no tengo FOO , entonces pip install FOO y obtengo la última versión.
• si tengo FOO , entonces pip upgrade FOO y obtengo la última versión.

Creo que estamos hablando de 2 casos:

1. No sé si tengo FOO , y quiero que el comando _one_ obtenga el último FOO , lo tenga o no.
2. Quiero que el comando _one_ obtenga lo último de FOO y BAR . Tengo FOO instalado, pero no BAR .

¿Les debemos a los usuarios _un_ comando por estos? Preferiría la simplicidad y la claridad en los comandos antes que dar atajos a las personas. Pero si los usuarios lo exigen, ahí es donde entra algo como --fill-in-missing .

Además, personalmente me atrae un comando de "actualización" que, por defecto, solo actualiza de manera similar a cómo funcionan las herramientas de distribución. "instalar" instalaciones y "actualizar" actualizaciones ...

Punto de aclaración: acabo de comprobar cómo funcionan tres herramientas de distribución populares, y AFAICT (en parte, esto se basa en las páginas de manual porque no las uso todas):

• apto:
  
  
  
  • apt install <pkg> realiza un "upstall", ya sea actualizaciones o instalaciones, dependiendo de si ya está instalado o no.
  
  
  • apt upgrade actualiza todos los paquetes instalados
  
  
  • apt upgrade <pkg> no existe, la única forma de actualizar un solo paquete es apt install <pkg> (que también acepta varios tipos de especificadores de versión)
  
  
• mmm:
  
  
  
  • yum install <pkg> realiza un "upstall"
  
  
  • yum upgrade actualiza todos los paquetes instalados
  
  
  • yum upgrade <pkg> actualiza una lista específica de paquetes. No sé qué pasa si aún no están instalados.
  
  
• cerveza casera:
  
  
  
  • brew install <pkg> realiza un "upstall"
  
  
  • brew upgrade actualiza todos los paquetes
  
  
  • brew upgrade <pkg> actualiza una lista específica de paquetes. No sé qué pasa si aún no están instalados.
  
  

Entonces, usar la instalación para actualizaciones es en realidad lo que hacen las herramientas de distribución :-). No significa que tengamos que hacerlo también; solo un punto de datos.

No sé si tengo FOO, y quiero un comando para obtener el último FOO, lo tenga o no.

Creo que el caso de uso más obviamente convincente para esto está en la documentación. Ejemplo: los documentos de django que vinculé en el otro hilo que instruyen a las personas a ejecutar pip install -U <some package> . No quiere decirle a la gente que "ejecute pip install <pkg> excepto si ya lo tiene instalado, ejecute pip upgrade <pkg> " porque eso es demasiado confuso para los novatos, pero si install no lo hace ' t actualice y luego simplemente decirle a la gente que ejecute pip install <pkg> también creará confusión en la que las personas comenzarán a trabajar en su tutorial con una versión anterior instalada y luego no tendrán idea de por qué las cosas no funcionan bien y lo culparán por ello. Por lo tanto, definitivamente necesita un solo comando "upstall", y debe ser simple y obvio para incluirlo en los documentos.

Seguimiento del comportamiento de Homebrew para comparar: brew upgrade falla si intenta instalar un paquete no instalado:

$ brew upgrade git
Error: No such file or directory - /usr/local/Cellar/git

Además, el comportamiento actual de brew upgrade está cambiando (ver discusión aquí ); en una versión futura, cambiará a requerir --all para actualizar todos los paquetes instalados.

Punto de aclaración

Sabía que alguien se daría cuenta de esto. :)
Casi me respondo a mí mismo. Estaba concentrado en las actualizaciones.

actualización de yum[...] No sé qué pasa si aún no están instalados.

no hace nada

yum instalarrealiza un "upstall"

true, pero el comportamiento predeterminado es solicitar confirmación, que pip no tiene.

los documentos de django que vinculé en el otro hilo

para ser claros, no eran los documentos reales de Django. los documentos de Django dicen pip install Django (https://docs.djangoproject.com/en/1.8/topics/install/)

En realidad, creo que es algo malo, dada la forma en que -U funciona actualmente, hacer que la gente se acostumbre a usar install -U .

en su ejemplo vinculado, fue por redis que no tiene ninguna dependencia, creo, así que está bien en este caso.

va a crear confusión donde la gente comienza a trabajar a través de su tutorial
con una versión anterior [...] Así que definitivamente necesitas un solo comando "upstall"

IDK, no es tan obvio para mí que los tutoriales deban decirle a la gente que se quede atrás en general. Si alguien está haciendo un tutorial para FOO, y ya tiene FOO instalado, entonces tal vez no debería estar ciegamente "upstall" ... tal vez una actualización dañaría el entorno existente.

Creo que los tutoriales deberían decirle a la gente que se "supere" (¡gran término!) Porque un buen número de ellos están escritos por los propios proyectos y cuando las personas van a ver los tutoriales, rara vez miran primero para ver cuál es la versión existente de FOO. han instalado es, más bien tienden a ir a buscar los documentos más recientes.

También estoy de acuerdo en que la forma en que -U funciona actualmente, es un mal hábito hacer que la gente se acostumbre a usarlo indiscriminadamente, pero la clave, creo, es que con el comportamiento propuesto, no creo que sea un mal hábito. , sino algo bueno que hacer. Si necesita asegurarse de que está instalada una versión en particular, ya debería estar usando == y podemos agregar una marca para convertir el "upstall" predeterminado nuevamente en una "instalación" simple para las personas que necesitan asegurarse de que la versión instalada actualmente O la última versión está instalada (aunque todavía no puedo pensar en un escenario en el que esto sea realmente lo que todos quieren).

Creo que los tutoriales deberían decirle a la gente que "supere"

Sin embargo, de nuevo, ¿cuál es este entorno en el que se encuentran, donde obviamente está bien actualizar? Si se trata de un entorno de Python del sistema de distribución, entonces ciertamente no. Si se trata de algún otro entorno, lo hicieron para una aplicación, entonces un upstall podría ser perjudicial. si se trata de un entorno que acaban de crear para el tutorial, no es necesario que lo actualicen.

un punto clave aquí es que PyPI no es un repositorio "curado", como lo son los repositorios de distribución. puede estar bastante seguro de que un "upstall" está a salvo de un repositorio de distribución predeterminado ... eso no lo sabe con PyPI. Cada actualización es un poco arriesgada. "instalar", tal como está, es conservador.

tenga en cuenta que hacer que pip install actúe como un "upstall" sin arreglar # 988 romperá las cosas.

considere dónde están instalados A y B y A requiere B<2 . Ahora voy a ejecutar el nuevo pip install B , que actualiza B a v3 o lo que sea (debido a que no considero las restricciones instaladas), y ahora mi entorno está roto.

para las personas que necesitan asegurarse de que la versión instalada actualmente O la última versión esté instalada (aunque todavía no puedo pensar en un escenario en el que esto sea realmente lo que todos quieren).

Es trivial idear tales escenarios. Ejemplo (desafortunadamente no inventado): actualmente statsmodels está dividido por el último pandas (0.17.0). Soy usuario de ambos. Tengo un montón de versiones de Python instaladas y venvs por ahí. Entonces sé que para cualquier Python / venv me gustaría instalar pandas solo si aún no está allí. Si es así, probablemente también tendré statsmodels y luego "upstall" lo romperá.

@rgommers Hmm, ¿estás absolutamente seguro de que no tienes un pandas 0.17.0 en un entorno virtual en ninguna parte? Supongo que podría suceder, aunque creo que probablemente lo deletrearía haciendo pip install pandas!=0.17.0 o pip install pandas<0.17 pero supongo que no es del todo descabellado confiar en lo que ya tienes instalado.

Hmm, ¿estás absolutamente seguro de que no tienes un pandas 0.17.0 en un entorno virtual en ningún lugar?

Eso no es lo que yo dije. Tengo un venv con pandas 0.17.0, solo uno en el que no tengo modelos de estadísticas. pip install pandas<0.17 hará el trabajo, pero no se me había ocurrido usar eso (principalmente porque no lo necesitaba, el comando actual install funciona para este propósito).

De todos modos, no tengo mucha preferencia a favor o en contra de upstall. Solo quería señalar un escenario realista en el que dijiste que no se te ocurría nada.

+1

Esta discusión parece haberse estancado sin llegar a una conclusión. Cualquier opción sobre la mesa es una mejora importante con respecto al estado actual. Parece que se han considerado todos los pros y contras relevantes; solo hay una diferencia de opinión sobre la importancia relativa de la compatibilidad con versiones anteriores frente a la API óptima. ¿Quizás los desarrolladores de pip puedan intentar finalizar una decisión?

@rgommers probablemente tomaron una decisión? https://pip.pypa.io/en/stable/user_guide/#only -if-necesario-actualización-recursiva

@rgommers probablemente tomaron una decisión? https://pip.pypa.io/en/stable/user_guide/#only -if-necesario-actualización-recursiva

@ Liso77 gracias, pero no, realmente es la discusión sobre este hilo la que necesita finalizar. Esa documentación a la que vinculó solo apunta aquí.

@rgommers del enlace que
Estoy seguro de que estabas pensando más en este tema y ves algo más sutil de lo que hago. Así que, por favor, escribe qué (si crees que hay algo) aún está abierto. Si quiso decir que podría ser bueno que los desarrolladores escriban aquí explícitamente su decisión y eventualmente cierren este problema, estoy de acuerdo.

Por cierto. La situación podría ser mucho menos problemática si tuviéramos algo como

pip freeze > checkpoint.txt
pip checkout checkpoint.txt

lo que podría garantizar la reversión de la instalación a cualquier "punto de control". (pip install -r no es bueno en este momento) Estaba pensando agregar esta propuesta en una nueva edición pero estoy seguro de que tengo que estudiar y analizar más para traer una propuesta realmente útil. Veo que hay muchas salvedades, pero realmente me gusta tener la posibilidad de

pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="12">@bleeding_egde_branch</strong>
#or
pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="13">@stable</strong>

Quiero decir que eso podría resolver (con la ayuda de alguien de confianza (o una comunidad con muchas pruebas unitarias)) algo como el problema de pandas y modelos de estadísticas que describiste anteriormente.

(útil para ver este tema también es: https://pypi.python.org/pypi/peep)

@ Liso77 es simple: la discusión sobre este tema no ha terminado. Hay un PR esperando con el comando upgrade implementado (gh-3194), pero los desarrolladores de pip (al menos qwcode y @dstufft , y probablemente también @xavfernandez y @pfmoore) necesitan decidir si eso es lo que quieren , o quieren cambiar el comportamiento de pip install lugar. Hasta que eso suceda, no se cambiará nada.

+1

Por lo tanto, parece que se acordó la introducción del nuevo comando de actualización y el último debate sin resolver es si debería o no haber un comando "upstall" y, en caso afirmativo, qué comando principal (instalar o actualizar) debería obtenerlo como conmutador o predeterminado .

Agregando mis opiniones personales:

Creo que tener un comando singular a prueba de fallas para el upstalling "vale la pena", _ si solo_ para los casos en los que desea verificar programáticamente que un entorno está actualizado por cualquier motivo. ¿Por qué "programáticamente"? Porque no es interactivo, es decir, no hay ningún usuario que reaccione ante un error, advertencia u otro mensaje que le indique el comando hermano o hermana porque un paquete ya existe o no.
Opcionalmente, se podría agregar un mensaje preguntando al usuario si desea actualizar o instalar en lugar de simplemente quejarse.

Dicho esto, este comando "upstall" no debería ser el predeterminado de ninguno de los comandos (instalar / actualizar) y, por lo tanto, requerir que se invoque una opción. Esto agrega claridad a los verbos "instalar" y "actualizar" semánticamente claramente definidos y, en mi opinión, todos los administradores de paquetes que instalan por defecto uno de estos lo están haciendo mal. Pedir acción (como parece hacer yum ) está bien.

Esto nos deja con upgrade --install (menos de --install-missing ) y install --upgrade . Semánticamente, "actualice a la última [e instálela si no existe]" e "instale la última [o actualice a la más reciente si ya existe]". No hay mucha diferencia aquí, en mi opinión. install --upgrade es la versión ya existente y sería reconocible, pero incompatible con versiones anteriores.
Aquí hay otro para la mezcla: un nuevo comando llamado install-upgrade (o upstall ?), Donde ni la instalación ni la actualización tienen la opción de "también hacer lo otro", pero se introduce un nuevo comando con semántica clara en una posición importante: el nombre del comando en sí. Esta sería mi preferencia.

TL; DR : Introduzca upgrade y upgrade-install , desapruebe install --upgrade . Toda la funcionalidad con semántica clara.
Agregue mensajes u opcionalmente solicitudes para instalar y actualizar comandos si sus operaciones fallan debido a un paquete que ya existe o no.

Hice esto de nuevo manualmente esta mañana. ¿Hay alguna novedad sobre esta solicitud de función?

+1

+1

+1

Todos, usen la reacción del pulgar hacia arriba en el OP y dejen de enviar spam a la bandeja de entrada de todos.

Dado que pip tiene un modelo de control de calidad diferente al de las distribuciones de Linux, estoy bastante seguro de que una actualización aleatoria de todos los comandos es solo una falla en la fabricación.

pypi no tiene una base de datos de versiones de paquetes y compatibilidad que esté realmente verificada y probada,
a diferencia de una distribución con QA, pypi prácticamente no tiene QA propio y depende completamente de los proyectos que se le cargan (que varían en calidad)

Con los actuales conjuntos de limitaciones, estoy convencido de que es más una maldición que una bendición.
y si alguien se pregunta por qué las distribuciones están tan desactualizadas, el control de calidad requiere mucho tiempo y esfuerzo ^^

Todos, usen la reacción del pulgar hacia arriba en el OP y dejen de enviar spam a la bandeja de entrada de todos.

Tenga en cuenta que en realidad no necesitamos _ ningún_ tipo de respuesta "Me gustaría esto" de la gente. Somos conscientes de que la gente quiere esto, lo que falta es alguien que esté dispuesto a desarrollar una solución que satisfaga las diversas preocupaciones y problemas que ya se han planteado, y que inevitablemente surgirán durante una revisión de relaciones públicas.

Así que, personalmente, agradecería que las personas se abstuvieran de hacer ping a este problema a menos que tengan un código de trabajo que al menos ofrezca un punto de partida para la implementación, y estén dispuestos a seguirlo hasta la implementación.

De lo contrario, lo haremos cuando podamos. Personalmente, abordo este problema con regularidad y soy un desarrollador central de pip, por lo que puedo garantizar que si alguna vez tengo suficiente tiempo para trabajar en esto, lo haré. Mientras tanto, "¿algún progreso?" los comentarios tienden a desmotivarme simplemente porque en su mayoría se sienten como personas que exigen el derecho a dictar cómo paso mi tiempo de pasatiempo ...

un punto de partida para la implementación

Pensé que ese era el propósito de https://github.com/pypa/pip/pull/3194? A partir de ahí, la discusión derivó en varias alternativas para la denominación y el comportamiento de los comandos sin un consenso por parte de los desarrolladores principales. ¿Ayudaría implementar múltiples de esas alternativas? ¿O https://github.com/pypa/pip/pull/3194 solo necesita una actualización?

@sfriesel Te perdiste "y estás dispuesto a seguir adelante". Parece que la persona que hizo las relaciones públicas se quedó sin tiempo o sin interés (un problema común). El siguiente paso en ese es probablemente que el OP o alguien más que esté dispuesto a asumir la propiedad del PR, redacte un resumen al estilo PEP de la posición actual, cuáles son los diversos temas pendientes, lo que sugiere como el resolución de estos diversos problemas, y una solicitud de comentarios para reiniciar la discusión. Si el debate es demasiado grande para github, tal vez necesite llevar su documento a distutils-sig para obtener más información. Si no puede decidir sobre una resolución con la que está contento para los diversos problemas, o no puede obtener el consenso del debate, entonces sí, el número 3194 probablemente esté muerto (hasta que alguien más resuelva el problema nuevamente, momento en el que yo Espero que incorporen todo el trabajo realizado en su nuevo RP).

Más del 50% del trabajo en una propuesta como esta es "gestión" (documentar propuestas, gestionar debates, generar consenso). No es necesariamente lo que a la gente le gusta hacer, pero con una base de código tan utilizada como pip, es una parte esencial. (Y sí, eso es un problema; es mucho más agradable decir "escribo código como un pasatiempo" que "me dedico a la gestión de proyectos como un pasatiempo" :-))

@pfmoore Totalmente de acuerdo.

La cantidad de propuestas y la cantidad de discusiones, repartidas en muchos lugares, relacionadas con este tema a lo largo de los años hace que sea extremadamente difícil abordar este tema y obtener una imagen clara en poco tiempo .

@RonnyPfannschmidt

pypi no tiene una base de datos de versiones de paquetes

Es cierto. Esta es información proporcionada por los paquetes en tiempo de ejecución (del setup.py) y agrega un poco más de complejidad al proceso de resolución de las dependencias. Además, debido a cómo se comporta la lógica actual, algunos paquetes (incluso los prominentes como scipy) no enumeran una dependencia (como numpy) si está instalado para evitar volver a compilarlo innecesariamente.

Eso se resolvería con PEP 426 , entre otras cosas, pero no sé cuál es el estado de ese PEP.

@pfmoore

Tenga en cuenta que en realidad no necesitamos ningún tipo de respuesta "Me gustaría esto" de las personas

Es tentador decir +1 o levantar el pulgar para decir que te gustaría que esto suceda. Le permite a la persona sentir que ha agregado algo a este problema, contribuido a ello. No estoy diciendo que los desarrolladores de pip necesiten estar motivados o persuadidos, es solo que todos quieren decir eso. Y...

Agradecería que las personas se abstuvieran de hacer ping a este problema a menos que tengan un código que funcione

Poner un pulgar hacia arriba no le dará a nadie notificaciones / correos electrónicos (molestos) y aún podemos ver la cantidad de personas que han mostrado interés. No creo que a nadie le importe eso, pero podría estar equivocado.

Poner un pulgar hacia arriba no le dará a nadie notificaciones / correos electrónicos (molestos) y aún podemos ver la cantidad de personas que han mostrado interés. No creo que a nadie le importe eso, pero podría estar equivocado.

Ah, no me había dado cuenta de que hacer eso evitaba las notificaciones. Si esa es una buena idea.

El siguiente paso en ese es probablemente que el OP o alguien más que esté dispuesto a asumir la propiedad del PR, redacte un resumen al estilo PEP de la posición actual, cuáles son los diversos temas pendientes, lo que sugiere como el resolución de estos diversos problemas, y una solicitud de comentarios para reiniciar la discusión.

Por si sirve de algo, antes estaba escribiendo un artículo sobre esto y la resolución de dependencias, al estilo PEP. Lo dividiré y lo actualizaré ahora, agregando todas las cosas que se han propuesto en los últimos meses. Publicaré el comando de actualización como Gist una vez que esté hecho (¿~ 2 días?) Y lo vincularé desde aquí.

No estoy dispuesto a asumir la propiedad de las relaciones públicas todavía. Tengo la intención de ayudar a reavivar las discusiones y llegar a un diseño final que se pueda implementar. Si algunas cosas a mi alrededor va según lo previsto, debería ser capaz de seguir esto a través de la aplicación pero no quieren comprometerse con ella después de esto a través todavía.

/ cc @qwcode @dstufft @pfmoore @xavfernandez

Aquí está el enlace a mi artículo: https://gist.github.com/pradyunsg/a5abeac4af90fbdc54bb266c32c0d2d8

Inicialmente, solo me vinculé a varios lugares (~ 30 enlaces) para que el lector pudiera consultarlos e intenté copiar y luego editar para ajustar todos los hilos de comentarios. El documento era bastante extenso y mis opiniones se filtraron. Terminé empezando desde cero. Sin embargo, ahora es más corto y no tiene opiniones. Sin embargo, todavía lo he marcado como WIP.

Si hay algún problema, comente sobre la esencia. Haré las correcciones tan pronto como pueda.

ADVERTENCIA: _LIGERAMENTE_ COMENTARIO LARGO ANTES

Me gusta la idea de arreglar el comportamiento actual de --upgrade . ¿Existe alguna preocupación con respecto a esto que no sea la compatibilidad con versiones anteriores? Agregar un comando upgrade no parece una buena idea, debido a la gran superposición entre la instalación y la actualización.

FWIW, git hizo algo similar a lo que estamos discutiendo sobre --upgrade , cambiando el comportamiento predeterminado de git push en 2014. link

Si hay interés en cambiar el comportamiento de pip install --upgrade , aquí hay una propuesta de inicialización (refiérase a esto como P1) para esa discusión:

• A partir de la próxima versión principal (9.0), pip install --upgrade imprime una advertencia:

''
PipDeprecationWarning: pip dejará de actualizar las dependencias a su última
versión incondicional por defecto a partir de la versión 11.0.

Para mantener el comportamiento actual después de que cambie el comportamiento predeterminado,
el comando de instalación pasa --upgrade-strategy eager .

Para comenzar a usar el nuevo comportamiento de inmediato, con el comando de instalación
pasar --upgrade-strategy non-eager .

Para apagar este mensaje,.

Para más detalles, lea.
''

La página de documentación vinculada proporcionaría una descripción general rápida del cambio y sus efectos. Luego abordaría la pregunta más común: "¿Qué debo hacer?" y "¿Qué estrategia de actualización debo utilizar?" de la manera más directa y razonable.

• El mensaje podría necesitar una limpieza.
• La opción podría ser incluso 2 banderas, --upgrade-eager y --upgrade-non-eager o algo así. Eso es derramamiento de bicicletas, es decir, último paso.
  
  
  
  • A menos que suceda algo drástico, en la versión 11.0, pip install --upgrade cambia el comportamiento para no estar ansioso al actualizar las dependencias.
  
  

Editar: puse un ciclo de 3 versiones principales para el cambio, solo para dar más tiempo a las personas para que se cambien. Puede que sea innecesario. Tal vez, ¿una versión principal imprimiendo advertencias y la siguiente que realiza el cambio es suficiente?

@dstufft había tenido una idea similar (¿la misma?).

Si un comando de actualización es el camino a seguir, aquí hay una propuesta inicial para reiniciar esa discusión (refiérase a esto como P2, si lo desea):

1. pip upgrade copia la mayoría de las opciones y comportamientos de pip install .
2. --dry-run bandera se añadirá a install y upgrade comandos que lo pip impresión intentará si fuera a ejecutar realmente.
3. pip install <out_of_date_pkg> no cambia el comportamiento.
4. pip upgrade <not_installed_pkg> fallaría.
5. pip upgrade <up_to_date_pkg> no haría nada, diría por qué no hizo nada y saldría con un código de salida cero.
6. pip upgrade <out_of_date_pkg> realizaría una actualización recursiva no ansiosa.
   
   
   
   • : white_check_mark: predeterminado para actualización recursiva no ansiosa
   
   
7. pip upgrade --eager package se comportaría como el pip install --upgrade .
   
   
   
   • : white_check_mark: Permitir la participación en el comportamiento actual
   
   
8. pip install --upgrade imprimiría un RemovedInPip10Warning .
   Porque sería eliminado.

Además, ¿cuáles son sus pensamientos sobre:

1. ¿Hacer interactivo el comando de actualización? (algo como lo que hace apt-get)
   
   
   
   • hacer que pip install <pkg> comporte como la instalación ieupstall del administrador de paquetes del sistema operativo?
   
   
2. ¿Tiene --only-binary de forma predeterminada en el nuevo comando de actualización?
   
   
   
   • Si está bien, ¿qué hay de agregar --only-source y --no-source en el comando de actualización?
   
   
3. ¿Agregar una opción para "retener" la actualización de un paquete? En mi opinión, este es un requisito para upgrade-all .
4. ¿Tiene sentido distinguir entre estos casos, es decir, requiere una CLI diferente?
   
   
   
   • instalar: no instalado -> actualizado
   
   
   • actualización: desactualizado -> actualizado
   
   
   • upstall: {no instalado, desactualizado} -> actualizado
   
   

No propuse nada sobre la "instalación como upstall" porque no me siento muy bien de ninguna manera al respecto. Es consistente con los administradores de paquetes a nivel de sistema operativo, pero sería un cambio importante. No estoy seguro de cuán útil sería o cuál sería el comportamiento y la interfaz exactos ...

Quizás dormir sobre esto podría ayudar.

Personalmente, no veo mucho valor en mantener la coherencia con un comportamiento por el que pocas personas, si es que hay alguna, están felices. Me pregunto si tener uno para Python 2 (abrazando la estabilidad) y otro para Python 3 (abrazando el cambio) sería mejor o peor.

@ekevoo

Me pregunto si tener uno para Python 2 (abrazando la estabilidad) y otro para Python 3 (abrazando el cambio) sería mejor o peor.

Uno, eso está fuera de tema. Dos, si lo hace, terminará habiendo divergencia. Eso alejará a las personas que actualmente usan Python 2 porque (con suerte) alcanzará el EOL algún día y tendrán que cambiar a Python 3, teniendo que adaptarse a una herramienta que se comporte de manera diferente. Por lo tanto, pip no debería tener divergencia (y no lo hará, en mi opinión). Entonces, podría mantenerlo junto en una sola herramienta.

OTOH, veo lo que piensa acerca de cuánta compatibilidad con versiones anteriores es aceptable ...

Una advertencia en el pip 9, además de opciones adicionales para modificar el comportamiento de pip install --upgrade , --eager/non-eager (o algún otro nombre) me parece bien.

Protuberancia. Otra notificación para todos.

@pfmoore @dstufft @qwcode No quiero ser entrometido, pero ¿podría dedicar algo de tiempo para esto, durante el fin de semana o la semana que viene?

OK, entonces mis comentarios:

Con respecto a los dos caminos a seguir, no tengo una opinión. Elija la que crea que es la mejor opción, impleméntela y veremos cómo va a partir de ahí.

Respecto a sus preguntas adicionales:

1. Soy -1 en hacer que el comando sea interactivo. A menos que haya un problema específico sobre el que el usuario deba tomar una decisión, como "esta consecuencia de lo que solicitó es algo que claramente no conocía y podría ser un problema, ¿desea continuar?", Entonces es solo ruido inútil. Estoy en contra de los mensajes "¿estás seguro?" En general. Si tiene una propuesta específica para un mensaje que cree que vale la pena agregar, no dude en volver a preguntar con los detalles incluidos.
2. No deberíamos hacer actualizaciones diferentes de las instalaciones, así que no a --only-binary por defecto. Para mi uso personal, probablemente siempre querré pip upgrade --only-binary en primera instancia, pero _quiero_ que sea explícito.
3. No estoy seguro de a qué te refieres con "mantener" las actualizaciones. Por favor aclare. Pero como respuesta general, yo diría que no se moleste en primera instancia, mantengamos el PR inicial libre de "extras opcionales" - se pueden agregar más adelante.
4. ¿No es ese el tema principal de debate en las diversas discusiones de esta característica? Para empezar, ¿no afecta la pregunta básica de install --upgrade vs upgrade ? No recuerdo que haya habido una resolución de esa pregunta, así que estoy un poco sorprendido de que espere una respuesta "simple" a esta. Ciertamente no tengo una buena respuesta.

(Por cierto, no tengo fácil acceso a la esencia, así que si hay algún contenido allí que no esté en su resumen, lo he perdido, lo siento).

Sé que es difícil escribir un PR, y desmotivador que parezca empantanarse en debates y preguntas, pero en última instancia, creo que alguien tendrá que escribir uno y publicarlo como "esta es la solución Propongo - ¿algún comentario? "

No deberíamos hacer actualizaciones diferentes de las instalaciones [snip] Probablemente siempre querré pip upgrade --only-binary en primera instancia, pero quiero que sea explícito.

Si probablemente siempre quieres algo, debería ser el predeterminado ¹ . Pero creo que mantener la coherencia entre install y un posible comando upgrade es una buena idea.

No estoy seguro de a qué te refieres con "mantener" las actualizaciones.

Dejaré esto en reposo hasta que lleguemos al punto de hablar sobre agregar la funcionalidad de actualización completa.

nota para mí mismo: apt-mark conceptos para pip

Soy -1 en hacer que el comando sea interactivo. A menos que haya un problema específico sobre el que el usuario deba tomar una decisión

Ídem.

¿No es ese el tema principal de debate en las diversas discusiones de esta característica?

Exactamente por qué quería saber qué piensan ustedes.

No recuerdo que haya habido una resolución de esa pregunta, así que estoy un poco sorprendido de que espere una respuesta "simple" a esta.

No espero una respuesta "simple" todavía. Espero que lleguemos a una respuesta, preferiblemente simple, a través de la discusión.

Por cierto, no tengo fácil acceso a la esencia, así que si hay algún contenido allí que no esté en su resumen, me lo perdí, lo siento.

Más que un resumen, es un seguimiento del artículo. Léalo tan pronto como pueda.

Elija la que crea que es la mejor opción, impleméntela y veremos cómo va a partir de ahí.
[recorte]
Creo que alguien tendrá que escribir una [PR] y publicarla como "esta es la solución que propongo, ¿algún comentario?".

Estaba pensando en la línea de "averigüemos exactamente qué queremos primero" y luego sigamos adelante e implementemos eso.

^{1 a} menos que rompa el mundo de otra persona

No deberíamos hacer actualizaciones diferentes de las instalaciones [snip] Probablemente siempre querré actualizar pip --only-binary en primera instancia, pero quiero que sea explícito.
Si probablemente siempre quiere algo, debería ser el predeterminado. Pero creo que mantener la coherencia en la instalación y un posible comando de actualización es una buena idea.

Si _todos_ probablemente siempre quieren algo, (tal vez) debería ser un valor predeterminado. Pero solo estaba comentando mis propias preferencias. Honestamente, no tengo idea de si --only-binary es lo que la mayoría de la gente querría (probablemente depende de si estamos hablando a largo o corto plazo).

Existe una gran diferencia entre los binarios (ruedas), las fuentes que se pueden compilar en cualquier lugar (normalmente Python puro) y las fuentes que necesitan un compilador u otros requisitos previos externos. Lamentablemente, pip no puede distinguir los dos últimos, y eso hace que --only-binary menos útil (sobre todo por defecto).

Y valoro la coherencia entre los comandos sobre los valores predeterminados de "haz lo que quiero decir", que nuevamente puede ser mi preferencia personal.

Más que un resumen, es un seguimiento del artículo. Léalo tan pronto como pueda.

Lo leí, no agregó mucho de lo que no estaba al tanto (ya que he seguido los diversos hilos sobre esto), por lo que mis comentarios permanecen. Pero es un buen resumen de la situación, así que gracias por escribirlo.

No deberíamos hacer actualizaciones diferentes de las instalaciones [snip] Probablemente siempre querré actualizar pip --only-binary en primera instancia, pero quiero que sea explícito.

Si probablemente siempre quiere algo, debería ser el predeterminado. Pero creo que mantener la coherencia en la instalación y un posible comando de actualización es una buena idea.

Si _todos_ probablemente siempre quieren algo, (tal vez) debería ser un valor predeterminado. Pero solo estaba comentando mis propias preferencias.

Aclaración: El "usted" en mi comentario se refería a los usuarios finales (uno en plural), siendo @pfmoore uno en ese caso específico. Realmente debería haber usado otra palabra.

Algunas reflexiones sobre las estrategias de actualización. Opinión personal, todo esto, por supuesto :-)

Supongamos que hago pip upgrade foo

1. Si actualmente no tengo foo instalado, espero un error. Para mí, "instalar" y "actualizar" son dos actividades separadas que no quiero fusionar.
2. Si no hay una versión disponible que sea más nueva que la que está instalada actualmente (ver más abajo sobre --only-binary ), espero una notificación de que no hay nada que hacer.
3. De lo contrario, espero que foo se actualice a la última versión. Eso es lo que pedí, así que debería suceder.
   
   
   
   • No estoy convencido de que tenga sentido agregar restricciones. ¿Qué significaría pip upgrade foo>1.0 si tengo 1.1 instalado pero 1.2 está disponible? No es una actualización si deja 1.1 allí, pero si actualiza a 1.2, es lo mismo que pip upgrade foo . Posiblemente podría atribuirle significado a algo como pip upgrade foo<2.0 pero, en mi opinión, sería un caso muy inusual y no valdría la pena la complejidad. Así que supongamos que pip upgrade solo toma una lista de nombres de paquetes (en oposición a los requisitos).
   
   
   • Del mismo modo, no sé cómo interpretar pip upgrade <path_to_archive/wheel> . Supongamos que no está permitido en primera instancia.
   
   
4. Puede que quiera o no permitir que pip intente compilar desde la fuente (esto tiene que ser una decisión del usuario, ya que pip no puede decir si la compilación desde la fuente funcionará y no tiene la capacidad de volver a intentarlo con una versión diferente si un la compilación de la fuente falla). Por tanto, --only-binary debe ser una opción de usuario y, si se especifica, significa que pip debe ignorar la distribución de la fuente al calcular "lo que está disponible". (Por supuesto, podríamos usar solo binarios de forma predeterminada, y tener una opción --allow-source , pero de cualquier manera upgrade debería coincidir con install en este sentido).

De acuerdo, eso se maneja con los paquetes especificados explícitamente. Dudo que haya algo controvertido allí (excepto tal vez por las partes que digo que deberíamos omitir hasta más adelante). Ahora en dependencias.

• La regla principal en mi mente es que nunca debemos hacer nada con las dependencias, a menos que estemos _actualmente_ actualizando el paquete especificado por el usuario. Entonces ese es el punto de partida. Si el objetivo no se actualiza, ni siquiera mires las dependencias. Alguna vez.
• Mi opinión sería que _todas_ las dependencias deben manejarse de la misma manera, ya sea que sean dependencias directas o indirectas del paquete especificado por el usuario, es irrelevante. No creo que esto sea controvertido.
• Una suposición fundamental aquí debería ser que el usuario no sabe cuál es la lista de dependencias. Después de todo, el objetivo de tener dependencias implícitas es que el usuario _no_ tenga que gestionarlas. Entonces, cualquier solución que necesite que el usuario sepa explícitamente sobre una dependencia es defectuosa, en mi opinión (a menos que un comando falle con un mensaje sobre una dependencia en particular, en cuyo caso el usuario podría volver a ejecutar con esa dependencia especificada en una opción, pero deberíamos buscar trabajar por primera vez en la mayor cantidad de casos posible, por lo que esto no debe verse como la norma).
• Yo diría que, de forma predeterminada, el enfoque debería ser solo actualizar las dependencias que _deben_ actualizarse para satisfacer las nuevas restricciones. Hay un problema desagradable al acecho aquí, ya que las restricciones pueden cambiar dependiendo de lo que se actualice. Pero si hacemos una solución completa a ese problema, o simplemente intentamos alguna solución de "mejor esfuerzo" no es tan importante (dudo que los gráficos de dependencia complejos con restricciones en conflicto sean comunes en la vida real). El punto importante es el principio de que no actualizamos nada que el usuario no haya pedido que se actualice, a menos que sea necesario.
• Tener una bandera que diga "actualizar todo a la última versión" puede ser útil (al menos para compatibilidad con versiones anteriores). Aún mejor sería tener herramientas (probablemente externas a pip) que analicen e informen sobre las opciones de actualización. Entonces los usuarios podrían decidir por sí mismos. Pero no sé si alguna vez vería la necesidad de alguna de estas opciones.
• En lugar de una opción de "actualización ansiosa", es mucho más probable que desee un comando upgrade-all (o upgrade --all si queremos mantener un solo comando). Esto debería ser semánticamente idéntico a upgrade con cada paquete instalado listado en la línea de comando. Una vez que estoy haciendo actualizaciones ciegas de paquetes (por lo general, es posible que no sepa o no haya documentado el árbol de dependencias de mis paquetes), probablemente solo quiera "todo". Más aún si utilizo entornos virtuales para aislar cosas.
• La pregunta --only-binary vuelve a aparecer aquí. Ciertamente, si el usuario especifica --only-binary para la actualización principal, se debe suponer que las dependencias implican --only-binary . Pero incluso si el usuario permite la instalación de fuentes al actualizar el paquete principal, la introducción del riesgo de falla involucrada en la actualización de fuentes de una dependencia parece irrazonable. Por lo tanto, sugiero que solo consideremos los binarios para actualizar las dependencias, a menos que el usuario permita explícitamente la fuente. Eso implicaría necesitar una opción --allow-source dep1,dep2,... . Espero que esta propuesta sea controvertida, pero considere un paquete Python puro foo que se distribuye solo en forma fuente, que depende de numpy. Tenemos foo 1.0 dependiendo de numpy> = 1.10, y foo 2.0 dependiendo de numpy> = 1.11. El usuario tiene foo 1.0 y quiere actualizar. No tienen los medios para construir numpy. Tienen que permitir actualizaciones de fuente para foo, pero no quieren perder el tiempo tratando de construir Numpy 1.11 (o peor aún, construirlo podría funcionar pero dar una construcción no optimizada, lo que rompe su sistema). Por supuesto, podrían especificar --only-binary numpy pero es posible que ni siquiera sepan que foo depende de numpy.

Eso es todo. Para mí, los requisitos son bastante claros (y, sinceramente, no creo que sean particularmente controvertidos si ignoramos los problemas de implementación). Sin embargo, la implementación es el asesino aquí (básicamente, lo anterior exige un enfoque de solucionador de SAT completo como se ha discutido anteriormente). Los compromisos que estamos dispuestos a hacer porque implementar un solucionador de SAT es demasiado difícil, es donde probablemente se encuentren los debates.

Hasta donde yo sé, los siguientes serán los desafíos de implementación:

1. Un solucionador de SAT completo es difícil. No sé lo suficiente para entender qué alternativas son más simples y en qué se diferencian de un solucionador de SAT. (Bueno, creo que la actualización ansiosa es bastante simple, por eso es lo que hacemos en este momento). Específicamente, cuando tengamos una situación en la que actualicemos algo que el simple principio de "no actualice nada que no tenga que hacer" dice que no debería haber sido actualizado.
2. He pasado por alto todo menos las restricciones de dependencia más básicas. Una vez que nos involucramos en los límites superiores de las versiones, o en las listas de versiones permitidas, las cosas se ponen feas. Pero, de manera realista, es probable que tales casos sean bastante raros (me encantaría que alguien investigara la información de dependencia real de PyPI; puedo intentar hacerlo, pero dudo que tenga tiempo).
3. Cuando tenemos varios objetivos - pip upgrade a b c - ¿tratamos esto como 3 acciones separadas, "actualizar a", luego "actualizar b" y luego "actualizar c", o fusionamos las 3 en una sola "combinada" acción de alguna manera (tenga en cuenta que debido a que propongo tratar las dependencias de manera diferente a los objetivos, esto _no_ es lo mismo que pip upgrade dummy donde el dummy depende de a, byc y asumimos que el dummy se actualizó).

Si alguien quiere estar en desacuerdo con cualquiera de los comentarios o afirmaciones anteriores, eso es genial. La mayor parte de esto es solo mi opinión y, sinceramente, no trabajo en entornos complejos; es probable que mi uso sea principalmente para mantener una instalación del sistema y algunos entornos virtuales en Windows (por lo tanto, los debates sobre las instalaciones binarias frente a las de origen son importantes para yo, pero los gráficos de dependencia complejos no tanto). Cuantos más casos de uso podamos comparar con nuestras suposiciones, mejor.

Así que actualmente tenemos dos operaciones, pip install y pip install --upgrade , sin embargo, creo que ambas cosas hacen algo que nadie quiere que suceda en la vida real.

Por pip install , obtenemos este tipo de comportamiento extraño en el que puede obtener la última versión (¡o puede que no!) En función de lo que ya está instalado en su sistema. Creo que este tipo de rarezas hace que pip sea más difícil de usar, y no creo que realmente tenga mucho sentido (¿qué situación le importaría no actualizar pero aún desea instalar la última versión si aún no tiene ¿eso?). Creo que el hecho de que este comando tenga este comportamiento extraño quizás-último-quizás-no es la razón por la que vemos a mucha gente buscando pip install ---upgrade como su comando principal en lugar de pip install .

Sin embargo, pip install --upgrade no es mucho mejor, aunque le brinda un comportamiento constante, es demasiado ansioso, se extiende a una actualización completa de _todo_ que el usuario ni siquiera sabe que estará implicado en su pip install --upgrade comando. Veo algún uso para este comportamiento, pero no lo veo como un buen valor predeterminado para un comando de nivel superior.

Lo que creo que deberíamos hacer aquí es encontrar una ruta para hacer que `pip install ... more consistent. In that I mean pip install siempre termine teniendo la última versión aceptable (especificadores dados y marcas modificadoras como - only-binary ``) independientemente de lo que se instaló anteriormente.

Creo que dar a este comando algún tipo de comportamiento --eager o --recursive o --upgrade-all-the-things estaría bien.

No creo que un comando pip upgrade que tome una lista de paquetes sea algo que debamos hacer. Creo que si agregamos un comando de este tipo, entonces debería usarse simplemente para actualizar todo lo instalado a las últimas versiones (teniendo en cuenta la información de la cadena de dependencias, así como modificadores como --only-binary ).

¿Eh? ¿Entonces pip install foo no siempre falla si foo está instalado? Eso me parece incorrecto, esperaría que solo dijera "ya instalado".

No me gusta la idea de que pip install sea ​​"instalar o actualizar". Mejor ser explícito y todo eso.

Ahora mismo pip install foo nunca "falla" basado en si algo está instalado o no, simplemente no hará nada y dirá que X ya está instalado. Mi afirmación es que el comportamiento no es muy útil. "Afirmar que alguna versión, cualquier versión que esté instalada" no me parece un comportamiento útil. Tampoco coincide con otros administradores de paquetes que estoy acostumbrado a gustar apt-get o menos.

Bien, puedo ver que el comportamiento no es útil (aunque personalmente considero que aceptar silenciosamente "ya instalado" es bastante inocuo). Pero preferiría ver fallar la instalación de un paquete ya instalado, en lugar de actualizarlo.

¿Qué esperaría que hiciera pip install foo-1.0-none-any.whl si foo 2.0 ya estuviera instalado? ¿Degradar? ¿Silenciosamente no hacer nada? Prefiero ver un error simple y agradable "ya instalado" que un conjunto complejo de reglas que dudo que la gente recuerde en la práctica.

No tengo mucha experiencia con los administradores de paquetes de Linux, por lo que no puedo comentar sobre las similitudes (o no) con pip. Pero no creo que esperaría que apt-get install foo actualice, así que si dices que sí, solo puedo responder que esto también me parecería extraño.

"Afirmar que alguna versión, cualquier versión que esté instalada" no me parece un comportamiento útil.

Pregunta rápida al margen sobre esto: ¿Qué pasa con "Afirmar que esta versión específica está instalada"?

No importa, hoy tenemos ese comportamiento.

@pfmoore :

¿Qué esperaría que hiciera pip install foo-1.0-none-any.whl si foo 2.0 ya estaba instalado? ¿Degradar? ¿Silenciosamente no hacer nada? Prefiero ver un error simple y agradable "ya instalado" que un conjunto complejo de reglas que dudo que la gente recuerde en la práctica.

Eh, las expectativas son cosas sorprendentes. Yo diría que _obviamente_ en este caso pip debería degradar. El usuario ha dicho explícitamente que quiere que pip instale esta rueda en particular, por lo que pip debería instalar esa rueda en particular. No hay nada de complejo en eso. Pero el caso "la ruta de distribución / archivo se proporciona explícitamente" es el n. ° 536; probablemente deberíamos mantener esta discusión más enfocada en lo que sucede si el usuario dice "pip install foo", que va al índice del paquete y encuentra un foo 2.0, cuando foo 1.0 ya está instalado.

Estoy muy de acuerdo con la posición de Donald aquí. Si partimos de la pregunta "¿qué debería hacer pip install ?", Entonces puedo ver cómo se podría argumentar que, bueno, dice 'instalar' en el nombre, por lo que solo debería instalar cosas, nunca actualizarlas ( bueno, excepto cuando hay alguna restricción). Pero si partimos de la pregunta "¿qué operaciones quieren los usuarios?", Entonces un comando que podría instalar la última versión, o podría dejarlo con una versión anterior, es realmente extraño y contrario a la intuición. Afirmo que en el 99% de los casos en los que los usuarios escriben pip install x , es porque (a) no están seguros de si está instalado o saben que no lo están, Y (b) quieren asegurarse de que lo tienen instalado porque están a punto de comenzar a usarlo por primera vez. (Si no fuera la primera vez, sabrían que está instalado, por lo que no ejecutarían pip install .) En esta situación, darles la última versión es lo correcto.

@nchammas :

¿Qué pasa con "Afirmar que esta versión específica está instalada"? Eso me parece útil, tener un comando de instalación idempotente.

Para la "versión específica" hay pip install x==<version> .

También puedo imaginar que para algunos tipos de uso de scripting / programático podría ser útil tener un comando pip require x que tenga la misma semántica que instalar un paquete con Dist-Requires: x , es decir, se asegura de que algunos La versión está instalada pero sin garantías sobre qué. Pero este sería un comando de nivel inferior no destinado a usuarios finales.

Una forma de pensar en la diferencia entre estos: si x no está instalado, entonces estaría bien que pip require x instale alguna versión antigua aleatoria. (Y diablos, tal vez debería, para obligar a la gente a ser robusta en su contra ). Pero nadie aceptaría nunca pip install x instalar alguna versión antigua aleatoria.

(Este es un experimento mental, en realidad no soy partidario de que Dist-Requires: x o pip require x en un entorno sin x deba elegir una versión antigua aleatoria de x para instalar.)

Bueno, supongo que también hay otro caso en el que los usuarios escriben pip install x , que es cuando ya saben que está instalado, pero están acostumbrados a sistemas con el comportamiento de estilo Debian donde install siempre se actualiza . Obviamente, estos usuarios también quieren que se actualice :-).

Prefiero no agregar un comando pip upgrade .

Los usuarios de pip ya tienen algunas expectativas sobre el comportamiento de pip.
El principal punto de dolor proviene del comportamiento predeterminado pip instal --upgrade , así que centrémonos en eso.

Una advertencia en el pip 9, además de opciones adicionales para modificar el comportamiento de pip install --upgrade , (--eager / non-ansioso) seguido en el pip 10 por un cambio en su comportamiento predeterminado parece bastante simple, debería eliminar el problema principal origen y no rompe el modelo mental de los usuarios de pip.

Sí, definitivamente estoy tratando de abordar esto desde "qué operaciones quiere hacer un usuario" versus "qué operaciones debería hacer el comando X". Luego estoy tomando esta operación de alto nivel que creo que los usuarios quieren hacer, y trato de asignarla a un solo comando con nombre (tan explícito como sería, pip install-the-latest-version`` no es muy fácil de usar) .

Obviamente, todo esto es muy confuso, pero puedo decir que el 99% de las veces lo que hago es pip install -U <whatever> porque eso coincide mejor con lo que espero de un instalador dado lo que está disponible actualmente. También veo en varios scripts de automatización personas que usan pip install -U . También es lo que otros administradores de paquetes populares para idiomas hacen de forma predeterminada, como npm. En los casos en los que veo personas que no usan -U , es por su naturaleza recursiva, no porque no quieran instalar la última versión de las cosas.

Los usuarios de pip ya tienen algunas expectativas sobre el comportamiento de pip.

Sin embargo, TBH, la principal expectativa que tengo sobre pip como usuario es que en aproximadamente el 50% de las invocaciones hará algo sorprendente y obviamente mal. Y no soy el único - véase por ejemplo @glyph charla 's en PyCon la semana pasada donde observó que el PIP es genial, excepto que todos los valores por defecto se rompen y requieren enters me-flags. Esto no es una crítica a los desarrolladores de pip, entiendo que usted / todos estamos trabajando bajo un conjunto complejo de restricciones, y no es un argumento de que deberíamos simplemente romper cosas por el simple hecho de romperlas. ¡pip tiene muchas piezas y muchas de ellas están bien! Pero dado el estado general de los valores predeterminados de pop, _realmente_ no me convencen los argumentos de la forma "pip siempre ha hecho X, por lo tanto, pip siempre debería hacer X". Si desea argumentar a favor de que la instalación de pip se niegue a actualizar, entonces está bien, pero preferiría ver ese argumento basado en los méritos reales, no solo en la inercia.

Sí, ciertamente estoy de acuerdo con @njsmith y @glyph aquí. Tenemos una serie de malos comportamientos predeterminados, y creo que parte del avance debe consistir en descubrir cómo podemos deshacernos de ellos y lidiar con esos cambios importantes para hacer que las cosas avancen hacia mejores valores predeterminados.

Este cambio en particular puede que no sea uno de esos, pero creo que lo es.

Sí, definitivamente estoy tratando de abordar esto desde "qué operaciones quiere hacer un usuario" versus "qué operaciones debería hacer el comando X". Luego estoy tomando esta operación de alto nivel que creo que los usuarios quieren hacer, y trato de asignarla a un solo comando con nombre (tan explícito como sería, pip install-the-latest-version '' no es muy fácil de usar) .

está bien. Supongamos que estoy dispuesto a considerarme convencido (algo) de esto. Sin embargo, si asumimos que esto es lo correcto, ¿qué pasa con las dependencias? Estoy 100% convencido de que "intentar instalar numpy desde la fuente" casi siempre no es lo que se busca. Por lo tanto, solo instalamos numpy desde wheels, a menos que el usuario mencione explícitamente numpy. Tome eso como un hecho por ahora, y luego suponga que tenemos la situación que describí anteriormente.

• El usuario tiene foo 1.0 y numpy 1.10 instalados, foo 1.0 depende de numpy> = 1.10
• PyPI tiene foo 2.0 disponible, depende de numpy> = 1.11. No hay ruedas numpy 1,11.

¿Qué hace pip install foo ? ¿Presumiblemente dejar al usuario en 1.0, ya que es una instalación que funciona? Pero, ¿debería tener éxito (ya que foo está instalado) o fallar (ya que no pudo instalar la última versión)? Si es lo primero, ¿cómo se entera el usuario de que su sistema está desactualizado? Si es lo último, ¿cómo dice el usuario "Solo quiero asegurarme de que foo esté ahí"? OK, el usuario puede hacer pip list --outdated , ver que foo 2.0 existe y hacer pip install foo (Por cierto, eso todavía me parece completamente extraño, tengo foo, pero sé que hay una nueva versión, así que ¿Puedo instalar pip ??? No importa ...) Y obtengo un éxito, pero 1.0 permanece instalado?

Una razón por la que prefiero dos comandos es que la intención del usuario es completamente clara, por lo que los casos extremos como este se pueden manejar correctamente porque conocemos las expectativas del usuario.

Quizás todo esto sea obvio si estás acostumbrado a apt-get. Pero definitivamente puedo decir que no está del todo claro para alguien como yo que no lo es.

Si desea argumentar a favor de que la instalación de pip se niegue a actualizar, entonces está bien, pero preferiría ver ese argumento basado en los méritos reales, no solo en la inercia.

Mi argumento se basa en lo explícito más que en lo implícito. Definitivamente _no_ en "siempre lo hemos hecho de esta manera". No tengo ningún problema con la idea de que tal vez los usuarios aptos estén acostumbrados a "instalar", lo que significa "posiblemente actualizar". Realmente no estoy tan seguro de que otros usuarios lo estén.

Un pensamiento: ¿apt tiene un "paquete ya existente - actualización?" ¿inmediato? Me imagino que instalar-como-actualización es menos sorprendente para mí si fuera "instalar-o-preguntar-si-debo-actualizar" ... Por supuesto, pip no se comporta de manera interactiva así en este momento, aunque obviamente, hacerlo así es una opción.

Esa es una pregunta interesante: otros administradores de paquetes lo resuelven en su mayoría al no tener paquetes binarios en absoluto, por lo que es _siempre_ por fuente, o al tratar prácticamente solo con paquetes binarios, por lo que es _siempre_ binario. Estamos en una especie de extraño intermedio que lo hace más difícil.

Dado eso, creo que, por defecto, por ahora, deberíamos desplegar el paquete fuente numpy 1.11 e intentar instalarlo, pero si han especificado --only-binary , entonces nuestro solucionador hipotético (que necesitamos desesperadamente, SAT o retroceso o lo que sea) vería que foo-2.0 no es una instalación que se pueda resolver y luego recurrirá a la instalación de foo-1.0 . Este no es un gran valor predeterminado, particularmente para los usuarios de Windows donde compilar es _mucho_ más difícil, pero creo que refleja la realidad actual.

Dicho esto, una cosa que realmente quiero hacer es comenzar a intentar impulsar las cosas hacia un mundo en el que podamos cambiar el comportamiento de pip nuevamente para que, de manera predeterminada, podamos ser solo binarios y requerir la suscripción para las versiones de origen, pero yo no crea que estamos en un lugar todavía en el que podemos hacer eso.

@pfmoore : Creo que la cuestión de las instalaciones binarias frente a las de origen es algo ortogonal. Me parece que surgen exactamente las mismas preguntas para un comando pip upgrade dedicado, por lo que, si bien son problemas reales que debemos abordar, ¿dividir la actualización y la instalación simplemente soluciona los problemas en lugar de simplificarlos? Además, en el caso particular de numpy, ahora enviamos ruedas para básicamente todas las plataformas que nos importa admitir :-).

Pero así es como sugeriría manejar estos problemas por pip install foo (específicamente este comando, no estoy hablando de pip install foo==whatever o pip install ./foo-*.whl o pip install bar donde bar tiene Requires-Dist: foo ):

1) Consulte el índice para encontrar la última versión candidata de foo ; llame a esto $LATEST . Si no existen versiones candidatas, entonces saldrá el error.

2) Si $LATEST ya está instalado, finalice correctamente.

3) Compruebe si hay una distribución de $LATEST que se pueda instalar en el entorno actual. (Ejemplos de razones por las que podría no haberlo: solo hay ruedas, pero no sdists, y las ruedas no coinciden con el entorno actual. No hay ninguna rueda que coincida, y hay una sdist, pero el usuario ha pasado --binary-only :all: . No hay ninguna rueda que coincida, y hay una sdist, pero la sdist tiene una bandera que dice "Solo trabajo en python 3" y el usuario está ejecutando python 2; la gente de ipython / jupyter probablemente lo hará propondrán esto como una nueva característica pronto, porque quieren eliminar el soporte de Python 2 para las nuevas versiones en enero y, al mismo tiempo, proporcionar un LTS compatible con Python-2).

4) Si $LATEST _no_ tiene una distribución viable: emita una advertencia para decirle al usuario que hay una versión más nueva disponible pero no para su entorno, idealmente con una pista sobre lo que deben hacer si realmente la tienen. quiere la nueva versión (por ejemplo, "ipython 6.0.1 está disponible pero requiere python> = 3.4, y tiene python 2.7 - considere actualizar python", o "numpy 1.12 está disponible, pero no hay binario para ppc64 y tiene edificio deshabilitado desde la fuente - considere --allow-source numpy ) Luego elimine $LATEST de la lista de versiones candidatas y vaya al paso 1.

5) Si $LATEST _tiene_ una distribución viable, intente instalar esta distribución.

6) Si la instalación falla (por ejemplo, b / c es un sdist y no hay compilador), entonces saldrá el error. De lo contrario, termine con éxito.

@njsmith binary-only es algo ortogonal, de acuerdo, pero en mi opinión, si estamos tratando de diseñar comandos que "hagan lo que el usuario espera", entonces es fundamental hacerlo bien al mismo tiempo.

@dstufft el problema con "instalar numpy a menos que el usuario diga que --binary-only se explicó en el ejemplo de mi publicación épica anterior - (1) dice que foo solo está disponible en forma fuente, y (2) el usuario no puede (y de hecho no debería necesitar) saber que foo depende de numpy. Entonces el usuario no puede decir --only-binary :all: y no tiene idea de que necesita --only-binary numpy hasta _después_ de una compilación fallida (larga). O (posiblemente peor aún) una compilación exitosa que deja al usuario con un numpy no optimizado (en estos días, numpy se compila de fábrica en Windows, pero da una compilación no optimizada).

Estoy completamente de acuerdo en que a largo plazo deberíamos usar de forma predeterminada solo binarios, pero aún no estamos cerca de eso (como mínimo, debería implicar que casi todos los paquetes de python puro están disponibles como una rueda).

@pradyunsg Como puede ver, todavía hay muchos problemas sin resolver aquí. ¿Sigues interesado en llevar esto adelante? Soy reacio a iniciar otro largo debate si simplemente se va a estancar de nuevo ...

@pradyunsg Como puede ver, todavía hay muchos problemas sin resolver aquí. ¿Sigues interesado en llevar esto adelante? Soy reacio a iniciar otro largo debate si simplemente se va a estancar de nuevo ...

Esperaba que lo hubiera. Estoy interesado en llevar esto adelante. ¡Hagámoslo! :sonrisa:

Sugiero recopilar una lista con todo lo que un _usuario_ quiere que haga pip y luego proponer soluciones para cada uno de ellos hasta que todos (o una cantidad suficiente) se resuelvan con un comando pip (con opciones / valores predeterminados) o se puedan manejar con "ninguna acción".

Para empezar, aquí hay una lista que probablemente esté incompleta:

1. Un usuario desea instalar un paquete que aún no está instalado.
2. Un usuario intenta instalar un paquete que ya está instalado.
3. Un usuario desea actualizar un paquete que está instalado.
4. Un usuario intenta actualizar un paquete que no está instalado.
5. Un usuario quiere asegurarse de tener instalada la última versión de un paquete, ya esté instalado o no.
6. Por lo general, un usuario no desea que se actualicen todas las dependencias y, en su lugar, solo desea que se satisfagan.
7. Un usuario quiere actualizar / instalar un paquete pero no quiere construir desde la fuente (ni el paquete ni sus dependencias). Probablemente más probable que:
8. Un usuario está dispuesto a actualizar / instalar desde la fuente.

Mis propuestas personales para esto, como usuario:

1) & 7) pip install foo debe intentar resolver a la última versión disponible (considerando las dependencias) e instalarla. El algoritmo sería de @njsmith .
2) pip install foo → muestre una advertencia de que foo ya está instalado y proponga usar pip upgrade foo
3) & 7) pip upgrade foo intenta instalar la última versión disponible de foo, nuevamente siguiendo el algoritmo de @njsmith . Si no se puede instalar una versión más nueva porque no está disponible para la plataforma y no hay sdist o el usuario no quiere compilar desde la fuente, muéstrelo. Tenga éxito en cualquier caso y solo fallará si la instalación falla.
4) pip upgrade foo falla si el paquete no está instalado.
5) pip install-uprade foo o pip install foo --ensure-latest o pip install foo --upgrade (básicamente lo mismo que actualmente, excepto que no está ansioso).
7) Todas las operaciones deben ser no ansiosas y una bandera --eager estaría disponible para obtener la funcionalidad anterior de install --upgrade . Si una dependencia aún no está instalada, instale la última versión. Si ya está satisfecho, no haga nada. Si no está satisfecho, instale la última versión aún satisfactoria (para requisitos de límite superior).
8) pip upgrade foo --allow-source o pip upgrade foo --allow-source numpy , si foo depende de lanzamientos numpy no binarios. Editar: No sé si esto sería aplicable, vea el comentario a continuación.

No dude en ampliar la lista y publicar sus propias propuestas.

@pfmoore, aunque no estoy seguro de cuál es la alternativa. El estado del mundo actual es que las ruedas están ganando terreno, pero no están cerca de ser omnipresentes, por lo que no estoy seguro de ver una buena opción que no permita las versiones fuente de forma predeterminada en este momento.

@dstufft mi propuesta era permitir la fuente para paquetes con nombres explícitos, pero por defecto solo los binarios para las dependencias. De esa manera, el usuario no recibe pasos de compilación "sorpresa". Es un compromiso, claro, pero refleja lo que (tengo que) hacer manualmente en este momento.

@FichteFoll Por encima de todo, mi caso de uso principal es la capacidad de "actualizar todo". Busque todo lo que esté instalado actualmente y, si hay versiones más nuevas disponibles, actualícelas.

Los paquetes que he instalado normalmente no tienen nada más que dependencias "> =" (y la mayoría ni siquiera las tienen), así que no hay nada complejo aquí. Solo toma la última versión. Mi mayor restricción es que hay algunos paquetes que no puedo construir (numpy, scipy, lxml, pyyaml, matplotlib, pyqt) así que solo quiero binarios para esos. Probablemente pueda poner --only-binary <these> en mi pip.ini (o al menos espero poder ...)

Secundario: Instale el paquete XXX (última versión), más cualquiera de sus dependencias que aún no tengo. No actualice las dependencias que ya tengo si satisfacen las restricciones del nuevo paquete. Siempre sé que actualmente no tengo XXX.

Terciario: Actualice un solo paquete XXX que yo (sé que) he instalado. No modifique ningún otro paquete a menos que sea necesario para mantener las restricciones de dependencia (e incluso eso es teórico; nunca me he encontrado con la situación en la vida real, así que no sé cuál sería la mejor resolución para mí). Mi intención es siempre "actualizar a la última versión". Nunca me he encontrado con una situación en la que esto rompa las dependencias de los paquetes ya instalados. Si lo hizo, creo que me gustaría recibir una advertencia de que no obtuve la última versión (y por qué) además de una actualización a la última versión que es aceptable. En mi opinión, esta situación se traduce actualmente en pip install -U aunque el comportamiento de las dependencias no es lo que quiero. Sin embargo, la razón principal por la que haría esto es debido a la falta actual de un "actualizar todo" adecuado (o para hacer frente a casos en los que un nuevo comando "actualizar todo" no funciona como yo quería).

Toda la discusión sobre dependencias y limitaciones es, en mi experiencia, casi completamente teórica. Actualmente tengo 160 paquetes instalados en mi sistema Python (una combinación de módulos científicos, de análisis de datos, web y de programación general). 100 de ellos no tienen requisitos. Para el resto, ninguno tiene nada más complejo que una lista de paquetes, sin restricciones de versión ni nada más complejo que Requires: six, dask, pillow, networkx . La lista más larga de dependencias tenía 9 elementos.

@pfmoore ¿No va a romper muchas cosas? Una lista rápida de cosas en las que puedo pensar y que sé que son paquetes muy populares depende de:

• SQLAlchemy (opcionalmente requiere un compilador, usará Python puro si no).
• PyYAML (opcionalmente requiere un compilador, usará Python puro si no).
• Markupsafe (opcionalmente requiere un compilador, usará Python puro si no).
• PyCrypto (siempre requiere un compilador)
• pycparser (nunca requiere un compilador)
• httplib2 (nunca requiere un compilador)
• anyjson (nunca requiere un compilador)
• zope.interface (opcionalmente requiere un compilador, usará Pure Python si no).
• docopt (nunca requiere un compilador)
• Mako (nunca requiere un compilador)
• itsdangerous (nunca requiere un compilador)
• amqp (nunca requiere un compilador)
• OrderDict (nunca requiere un compilador)

y así sucesivamente, puede ver una lista larga de los paquetes más populares y si tienen o no ruedas en http://pythonwheels.com/.

@pfmoore

Busque todo lo que esté instalado actualmente y, si hay versiones más nuevas disponibles, actualícelas.

Obtuve este comando de una pregunta SO hace un tiempo que estoy usando actualmente para esto. Es subóptimo, pero funciona para la mayoría de mis paquetes, excepto uno. (Utiliza el lanzador py porque estoy en Windows).

pip list -o | cut -d " " -f 1 | xargs -n1 py -m pip install -U

Ahora, el único problema que tengo con esto es el paquete flake8, que tiene estos requisitos:

Requires-Dist: pyflakes (>=0.8.1,<1.1)
Requires-Dist: pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2)
Requires-Dist: mccabe (>=0.2.1,<0.5)

Específicamente, pyflakes es un problema ya que tiene una versión más nueva disponible y se actualiza con el comando anterior, lo que hace que flake8 no haga nada (ya que verifica la versión).
Entonces, esto es algo que debe tenerse en cuenta y también me gustaría tener la funcionalidad adecuada de actualización completa (¡sin incumplir los requisitos!).

@dstufft ¿

Para nuevas dependencias (o en la instalación donde una dependencia no siempre está presente) debe instalar, por lo que si no hay un binario, tome la fuente. Personalmente, consideraría "elegir la versión anterior con binario en lugar de la versión más nueva con fuente", pero eso se acerca peligrosamente a un valor predeterminado de --binary-only que estoy de acuerdo en que no estamos listos.

Mmm, quizás el problema que tengo es en realidad con la opción --only-binary , que es demasiado burda. Si tuviéramos una opción --prefer-binary , que dijera "solo use binarios, a menos que eso signifique que no hay candidatos, en cuyo caso vuelva a intentar permitir la fuente", sospecho que muchas de mis preocupaciones de que una actualización excesiva resultaría en roturas podría aliviarse. Lo que, como sugirió @njsmith , significa que las distinciones binario / fuente en las que me estoy enfocando pueden ser ortogonales a este boleto (aunque solo cambiaría mi posición a "no hay una solución satisfactoria para mis requisitos sin algo mejor que --only-binary estando disponible "...).

Específicamente pyflakes es un problema

De acuerdo, esa no es una situación que tengo (como digo, no tengo nada con dependencias tan complejas instaladas). No tengo problemas para refinar "actualizar todo" para actualizar las cosas a "la última versión que no da como resultado roturas", sino AIUI que necesita el enfoque de "solucionador SAT" para encontrar la solución correcta. Sin embargo, ese es un problema de implementación: el diseño siempre debería dar resultados correctos.

@pfmoore Creo que una bandera --prefer-binary podría ser una buena opción, independientemente del resultado de este ticket. Probablemente se incluye con una advertencia cuando no se instala la última versión que, de lo contrario, se habría instalado.

@FicheFoll : No creo que tratar de derivar toda la interfaz de usuario desde los primeros principios sea muy productivo. Hay una parte del problema relativamente claramente definida que está en el tema de este problema en particular, y si intentamos expandir el alcance a todo a la vez, simplemente se empantana nuevamente.

Sobre ese tema, parece que el lugar clave en el que nos diferenciamos es este: supongamos que un usuario tiene el modelo mental de que pip install foo es solo para hacer la transición de cosas desinstaladas a instaladas, y que entienden que foo ya está instalado. Afirmo que un usuario con este modelo mental _ nunca escribirá pip install foo _. Por lo tanto, cuando algún usuario _es_ escribe pip install foo cuando foo ya está instalado, podemos concluir que su modelo mental no es como el suyo (2). _O_ la primera parte es incorrecta: saben que foo está instalado y esperan que pip se actualice como otros administradores de paquetes populares, _o_, la segunda parte es incorrecta: no saben que foo está instalado , en cuyo caso esperan que install deje con la versión más reciente (porque eso es lo que hace la instalación cuando los paquetes no están instalados y creen que este paquete no está instalado).

Para que conste, una de las razones por las que no me gusta el pip install ... solo va de desinstalado a instalado y pip upgrade ... solo va de instalado a algo más nuevo instalado es porque encuentro al usuario experiencia bastante mala. El software que sabe lo que quería que hiciera, pero en lugar de hacer eso, le dice que invoque algún comando diferente es increíblemente frustrante.

$ pip install foobar
I'm sorry, but foobar is already installed, you want to run ``pip upgrade foobar``
$ pip upgrade foobar
...

No haría nada por mí excepto molestarme, aunque técnicamente es "correcto".

La otra cara de eso, si dices "ok, si pip install foobar ya tiene foobar instalado, entonces actuaremos como si no estuviera instalado, y si lo haces pip upgrade foobar entonces Actuaré como si ya estuviera instalado, terminamos con dos comandos que hacen básicamente lo mismo, excepto con _maybe_ algunas diferencias menores en exactamente cómo se procesan las cosas, lo que me dice que pertenecen como un comando singular con algunos --options para lidiar con los casos extremos. Creo que esto es mejor porque significa que los usuarios no tienen que intentar elegir entre cuál quieren por adelantado, hay un comando para instalar cosas y para la mayoría de los usuarios que Por lo general, hacen lo correcto. Si algún usuario en un escenario específico requiere algunas opciones de su parte, entonces tiene que pagar el costo de tomar algunas decisiones sobre qué --flags usar.

está bien. Considérame convencido. He investigado un poco, e incluso los instaladores de Windows con los que estoy (supuestamente :-)) familiarizado hacen la instalación como actualización (si instala algo como VirtualBox, dice "ya tiene instalada una versión anterior, ¿quieres actualizar? ") Powershell tiene paquete de instalación, que no dice nada específico, pero no hay paquete de actualización. Etc. Así que supongo que tener el único comando "instalar" es la norma.

Lo que, por supuesto, significa que, a menos que alguien más quiera discutir, técnicamente este RP puede simplemente cerrarse como "no se va a implementar". Pero sigue siendo un lugar tan bueno como cualquier otro para discutir _cómo_ queremos remodelar el comando de instalación, supongo.

OTOH, tal vez cerremos esto como rechazado y alguien abra un nuevo problema, con una propuesta concreta de cómo sugieren que se debe modificar el comando de instalación. Al menos podría proporcionar un punto de partida más claro para las discusiones.

Una pregunta. ¿Alguien piensa que estamos en un punto en el que alguien podría armar una propuesta de comportamiento completa a partir de todas las sugerencias aquí y en otros lugares? Cubriendo cómo se manejan las dependencias, qué sucede con las restricciones (y cuando entran en conflicto), binario vs fuente, cómo apoyamos el escenario de "actualizar todo", etc. Mi sentimiento personal es que necesitamos que alguien tome esa decisión, que le dé a la discusión un punto de referencia, o simplemente podríamos debatir los detalles para siempre. Probablemente podría hacer eso, pero es poco probable que pueda implementar lo que propongo (por ejemplo, propondría un enfoque de "resolución de dependencia óptima", que implica una AIUI de resolución de SAT). Por lo tanto, sería mejor que alguien que esté dispuesto a implementar su propuesta dé un paso al frente (y se enfrente al inevitable debate y al abandono de bicicletas :-)).

Todavía estoy preocupado por algunas de las implicaciones de los puntos aquí expuestos, pero no estoy seguro de tener la energía para debatirlos hasta que haya una posibilidad real de implementación.

Estoy totalmente de acuerdo con @dstufft 's más reciente https://github.com/pypa/pip/issues/59#issuecomment -224341218
Es por eso que (una vez más) abogaría por la solución simple de las opciones --eager / --non-eager .

También estoy de acuerdo con el comentario de @dstufft , como se indicó ( install y ningún comando update ).

Sin embargo, no estoy seguro de lo que implica --eager / --non-eager . Supongo que --non-eager significa que no actualice nada que no tenga que actualizarse (ya sea porque el usuario lo especificó explícitamente o porque es demasiado antiguo para satisfacer el nuevo conjunto de dependencias). ¿ --eager entonces significa actualizar cada dependencia a la última versión posible, sea necesaria o no? ¿Cuál sería el predeterminado? (Yo discutiría por --non-eager )

Y una pregunta: ¿alentaría esto a los paquetes científicos a declarar correctamente sus dependencias? Eso tiene que ser una consideración importante.

Punto de la bici. Los nombres de las opciones --eager y --non-eager son bastante poco intuitivos. Creo que necesitamos mejores condiciones. Quizás algo explícito como --upgrade-dependencies .

Este PR también sugiere un comando upgrade-all , que es el caso de uso clave para mí. ¿Está diciendo que rechazamos ese mandato o simplemente que no tiene una opinión al respecto?

Mi comprensión de lo que significa --eager y -non-eager coincide con lo que acaba de decir @pfmoore (si las dependencias son solo si son necesarias o siempre están instaladas), y estoy de acuerdo en que --non-eager debería ser el valor por defecto. También estoy de acuerdo en que el nombre es un poco horrible, aunque no tengo una solución mejor que no sea un bocado. Quizás --[no-]recursive o algo, no lo sé.

Creo que algo como un comando upgrade-all podría ser una buena adición (siempre que se asegure de no violar los especificadores de versión de nada). Sin embargo, probablemente llamaría a esto upgrade y dejaría que no tome argumentos para restringir en qué opera.

tl; dr
La discusión por un upgrade-all-packages - permanece aquí.
Discusión para prefer-binary - Más al # 3785
Discusión para instalar como actualización - Pasado al n. ° 3786

Si tuviéramos una opción --prefer-binary, que dijera "solo use binarios, a menos que eso signifique que no hay candidatos, en cuyo caso reintente permitiendo la fuente"

Esta es una buena idea. Si bien está relacionado con este problema, creo que merece su propio problema. (El comentario de @dstufft me hace pensar que hay interés en

Mi comprensión de lo que significa --eager y -non-eager coincide con lo que acaba de decir @pfmoore (si las dependencias son solo si son necesarias o siempre están instaladas)

La actualización ansiosa instalaría las últimas versiones permitidas de todas las (sub) dependencias.

Los nombres de las opciones --eager y --non-eager son bastante poco intuitivos.

Estoy de acuerdo. Me gusta la idea de poner el comportamiento detrás de una sola bandera.
--upgrade-strategy=eager/non-eager

También es un bocado, pero transmite la intención de manera más explícita. ¿Es demasiado detallado? Quizás.

Creo que es mejor deshacerse de las bicicletas después de finalizar la semántica.

¿Alguien piensa que estamos en un punto en el que alguien podría armar una propuesta de comportamiento completa a partir de todas las sugerencias aquí y en otros lugares?

Creo que sí. Necesitamos, al menos, establecer algunos hechos básicos en los que estamos de acuerdo. Estoy en esto.

OTOH, tal vez cerremos esto como rechazado y alguien abra un nuevo problema, con una propuesta concreta de cómo sugieren que se debe modificar el comando de instalación. Al menos podría proporcionar un punto de partida más claro para las discusiones.

Creo que deberíamos dejar este tema abierto por ahora, porque propone un upgrade-all . Ya ha notado que la actualización no está sucediendo. Abrí el # 3786 para una discusión más detallada sobre el comando instalar como actualización.

Todavía estoy preocupado por algunas de las implicaciones de los puntos aquí expuestos, pero no estoy seguro de tener la energía para debatirlos hasta que haya una posibilidad real de implementación.

Estoy dispuesto a llevar esto adelante hasta la implementación. Definitivamente no quiero desperdiciar el esfuerzo de todos los demás para llegar a un consenso sobre esto.

Creo que todos están de acuerdo en que sería muy bueno tener un comando de 'actualizar el mundo', pero IIUC está bloqueado mientras esperamos a que el trabajo de resolución aterrice. Mientras tanto, publiqué una propuesta más concreta para actualizaciones de paquete único en el nuevo número dedicado de @pradyunsg para esa discusión.

Creo que todos están de acuerdo en que sería muy bueno tener un comando de 'actualizar el mundo', pero IIUC está bloqueado mientras esperamos a que el trabajo de resolución aterrice.

De hecho, este problema ahora está correctamente bloqueado por # 988. Mencionar el número de emisión para vincular las dos cuestiones.

Casi lo olvido...

No estoy seguro de a qué te refieres con "mantener" las actualizaciones. Por favor aclare.

Ahora que este problema es exclusivamente para actualizar todos, debo aclarar.

Puede haber algunas situaciones en las que podría ser útil evitar una actualización de un determinado paquete cuando ejecutamos upgrade-all. El específico que tengo en mente es ... Si pkg está instalado y no quiero molestarme en volver a configurar una posible versión más nueva, entonces, quiero evitar que pip actualice ese paquete específico cuando ejecute 'actualizar el mundo'. Básicamente, estoy retrasando la actualización de pkg.

Una bandera que tome una lista de paquetes separados por comas para evitar una actualización estaría bien.

Agregar esto una vez que aparezca un solucionador de SAT debería ser fácil. Son solo algunas cláusulas adicionales IIUC. (Sí, también estoy repasando los solucionadores de SAT)

No sé si esto es algo común o algo que alguien quiera. Sin embargo, no creo que esto se haya originado en mi cabeza. Alguien debe haberlo mencionado en algún hilo en alguna parte.

Ah, ya veo. Eso tiene sentido y parece razonable desearlo.

Solicitud rápida: ¿Podría alguien agregar a la descripción una pequeña nota que indique que el comando de actualización no sucederá? Posiblemente, si lo desea, también escriba un pequeño resumen de por qué es así.

_{_Va a dormir_}

Dos buenas características que tiene apt (y creo que otros administradores de paquetes de sistemas maduros como dnf tienen características similares):

• Marcar un paquete como "retenido", que es un indicador persistente adjunto al paquete y hace que los comandos de actualización del mundo lo omitan. A menudo se configura en paquetes que tuvo que degradar o parchear localmente.
• Seguimiento de qué paquetes fueron solicitados explícitamente por el usuario, versus cuáles solo se instalaron implícitamente para cumplir con las restricciones de dependencia. Estos últimos pueden eliminarse mediante una actualización del mundo si dejan de depender de ellos.

Ambos pueden verse como casos especiales de lo que hacen los administradores de paquetes de entorno de proyecto más recientes como npm y cargo, donde distinguen entre algún tipo de archivo de "requisitos" orientado a humanos frente a un archivo de "bloqueo" completamente especificado. Un paquete contenido explícitamente es como un paquete que tiene una restricción de versión especificada por humanos, y un paquete instalado explícitamente es uno que está listado en el archivo editable por humanos.

Ídem. Si estamos agregando 'actualizar el mundo', necesitamos agregar la capacidad de marcar paquetes (como held / user-installed y tal vez más) para agregar información y determinar mejor un curso de acción para las actualizaciones. Veo esto como un requisito, no como algo agradable.

De hecho, me gusta la técnica que usa Cargo y me gusta. El uso de archivos y no alguna forma de metadatos escondidos detrás de un comando cli hace que sea mucho más fácil de captar, administrar y también posible crear un entorno reproducible.

De hecho, estaría feliz si veo alguna forma de pyproject.lock ...

200º comentario. Guau. : smiley:

Añadiendo referencia a # 654 para "marcar" los paquetes de los que hablamos.

¿Puede explicar qué hace la carga? ¿Dónde vería que el archivo pyproject.lock se almacena en la máquina del usuario?

El archivo de bloqueo de Rust's Cargo se almacena en la raíz del proyecto para registrar la versión de las dependencias instaladas actualmente. Confirmar este archivo en git le permite compartir un conjunto consistente de versiones de dependencia con otros desarrolladores y CI. Composer de PHP tiene un archivo de bloqueo similar, Composer.lock.

Siempre asumí que 'pip freeze' y 'pip install -r' de pip estaban destinados a hacer algo similar, y fue una lástima que los humanos pudieran leer / escribir fácilmente el formato de archivo de bloqueo y que la gente optara por editarlo directamente. ¿Requirements.txt no se concibió originalmente como un archivo de bloqueo?

@triplepoint Gracias por la explicación. De hecho, eso suena más a un archivo de requisitos. Pero los archivos de requisitos son opcionales, basados ​​en versiones y por proyecto. El marcado (según tengo entendido) debe ser por entorno (virtualenv o instalación del sistema) y simplemente debe decir "no actualizar automáticamente el paquete X" (pero permitir la actualización manual si el usuario solicita explícitamente una actualización de ese paquete por su nombre).

Para ayudar a desenredar las discusiones sobre upgrade-all y el "comportamiento de actualización", aquí hay comentarios de @rbtcollins y @ncoghlan en la discusión de la lista sobre este último acerca de que no se requiere un solucionador SAT para una primera implementación de upgrade-all :

Robert:

Me doy cuenta de que el consenso sobre el ticket es que está bloqueado, pero no
de acuerdo.

Sí, no puede hacerlo _correctamente_ sin un solucionador completo, pero puede hacerlo
una aproximación que sería mucho mejor que nada (solo estrecho
los especificadores dados en todos los requisitos). Eso es en realidad
razonable cuando se trata de un conjunto de versiones supuestamente bueno
(de la que no se ocupa la instalación).

Mella:

"yum upgrade" ha funcionado bastante bien durante años sin un solucionador de SAT adecuado, y el paquete configurado en una instalación típica de Linux es mucho más grande que en un entorno virtual típico (aunque la distribución de distribución reduce la probabilidad de que surjan requisitos conflictivos en la primera lugar).

Dicho esto, volver a ejecutar pip-compile y luego hacer un pip-sync ya es un equivalente funcional de una operación de actualización total (al igual que destruir y recrear un venv), por lo que estoy de acuerdo en que no hay necesidad de emparejar la cuestión de admitir actualizaciones masivas en pip de línea de base con el cambio del comportamiento de actualización de componentes con nombre.

En mi opinión, pip upgrade-all es, con mucho, la propuesta más importante sobre la mesa de todas las diversas discusiones sobre "funcionalidad de actualización". Tener "actualizar todo" daría una forma obvia de mantener su sistema actualizado, haciendo que las preguntas sobre actualizaciones que no estén ansiosas por dejar las cosas en niveles anteriores sean mucho menos urgentes, además de llenar un vacío que existe actualmente.

Si bien un solucionador completo sería bueno, no veo ninguna razón por la cual el punto de partida para pip upgrade-all no debería ser que hace lo que hace pip install -U <list every package that's installed here> . Eso es lo que esperaría como usuario y, en la mayoría de los casos, hace exactamente lo que se necesita. Los complejos casos de esquina en torno a requisitos en conflicto se pueden manejar en primera instancia haciendo referencia a lo anterior. Si eso no es suficiente, entonces podemos considerar modificar el comportamiento de install -U para abordarlo, o aplicar una mayúscula especial al comando update-all , o incluso implementar un solucionador completo en ese punto.

¿Va a implementar esto en los próximos 10 años?

FWIW, volveré a visitar esto, este fin de semana.

@magicgoose dijo:
¿Va a implementar esto en los próximos 10 años?

@pfmoore lo dijo mejor que yo:

Somos conscientes de que la gente quiere esto, lo que falta es alguien que esté dispuesto a desarrollar una solución que satisfaga las diversas preocupaciones y problemas que ya se han planteado, y que inevitablemente surgirán durante una revisión de relaciones públicas.

Así que, personalmente, agradecería que las personas se abstuvieran de hacer ping a este problema a menos que tengan un código de trabajo que al menos ofrezca un punto de partida para la implementación, y estén dispuestos a seguirlo hasta la implementación.

opinión totalmente personal

Creo que por la propia naturaleza de pip (que es instalar paquetes desde un repositorio que no tiene control de calidad global como debian, redhat o ubuntu)
Creo que es necesario y / o aceptable abstenerse por completo de implementar y actualizar todas las funciones.

ya que pip siempre garantizamos un estado obtenido conocido de un conjunto de paquetes de Python instalable

@RonnyPfannschmidt En mi opinión , es perfectamente razonable que los usuarios de pip

@pfmoore, mi experiencia personal con solo actualizar todos los paquetes en un entorno es que rompe las cosas con mucha regularidad ^^

los usuarios que necesitan una actualización relajada suenan como si se refiriera a usuarios finales normales (que deberían usar una distribución normal de Linux, por ejemplo)

Si actualizar todo es problemático o no, depende en gran medida de la cantidad de dependencias que tenga y de lo disciplinados que sean con respecto al mantenimiento de la API. También se puede usar junto con un repositorio privado seleccionado para controlar qué actualizaciones ocurren realmente, en lugar de tener que configurar cuidadosamente qué comandos de actualización se ejecutan en cada entorno virtual.

@RonnyPfannschmidt Los usuarios de Windows aún superan en número a los usuarios de Linux ~ 18 a 1, y no tienen nada comparable a una comunidad de administración de paquetes de distribución a la que recurrir en este momento (mientras que la tecnología central está ahí en las versiones recientes, las comunidades de empaque y curación no lo son). Eso significa que dependen mucho más de herramientas de nivel de usuario como pip y conda para tomar el relevo.

Somos conscientes de que la gente quiere esto, lo que falta es alguien que esté dispuesto a desarrollar una solución que satisfaga las diversas preocupaciones y problemas que ya se han planteado, y que inevitablemente surgirán durante una revisión de relaciones públicas.

@pfmoore, ¿está consciente de que estos comentarios pueden denigrar los esfuerzos de los colaboradores? Eso es lo que me parece. No estoy seguro de si siguió toda la historia de este problema, pero en este caso particular está muy fuera de lugar. El problema es mucho más con el equipo de desarrollo de pip que con cualquier contribuyente.

Resumen aproximado de solo una parte (PR gh-3194):

1. Existe una decisión documentada de que un comando upgrade es bienvenido (en la lista de correo de pip, así como en los documentos y GitHub).
2. Luego, un desarrollador destacado ( @njsmith en este caso) realiza una llamada de que implementar esta función sería muy valioso.
3. Aparece un nuevo colaborador, implementa todo, aborda todos los comentarios de las revisiones rápidamente. PR listo para fusionarse.
4. El contribuyente principal cambia de opinión acerca de querer upgrade .
5. Siguen discusiones muy largas, sin conclusión.
6. El colaborador se rinde y desaparece (la mayoría de la gente lo haría, esas cosas son frustrantes).

Y eso fue incluso antes de que apareciera @pradyunsg , quien está mostrando una notable persistencia.

En un proyecto que funciona bien, los desarrolladores centrales que realmente se preocupan por el tema organizarían un hangout rápido y tomarían algún tipo de decisión. O delegue a una o dos personas para que trabajen lo suficiente como para llegar a esa conclusión. O al menos disculparse y agradecer al remitente de relaciones públicas, en lugar de culparlo por "no cumplir".

Sé que tienes las mejores intenciones, pero ten un poco más de cuidado con este tipo de comentarios.

Creo que es perfectamente razonable que los requisitos y las opiniones cambien a través de la discusión, particularmente para un tema espinoso como este, donde no hay una respuesta correcta. Parte de lograr que un parche aterrice en cualquier base de código es mantenerse al día con los cambios que se eliminan como parte de la revisión y discusión sobre cualquier cambio. Algunos cambios son bastante mínimos y tienen menos, otros tienen más. No hay nada de malo en que una persona decida que no quiere lidiar con eso y se retire (cada barra para agregar un cambio provocará una cierta caída, incluidas las pruebas, la documentación, etc.).

Este cambio en particular es particularmente desagradable porque está cambiando el comportamiento predeterminado del uso principal de pip. Eso es difícil y aterrador y sería un flaco favor para nuestros usuarios si nos apresuramos y no elimináramos por completo las cosas antes de comprometernos en una dirección u otra. Este comando se usa de 10 a 100 millones de veces al mes. Este no es un cambio pequeño y fácil y no serán las personas que hacen ping a este problema las que tengan que lidiar con la reacción violenta que proviene de hacer cualquier cambio.

La persona que implementó las relaciones públicas antes, se agradece su tiempo, pero es un hecho que no siguieron hasta el final. Como desarrolladores principales aquí, nuestro tiempo es limitado, o somos voluntarios o estamos dispersos entre muchos proyectos y entramos y salimos de la participación. Hay un montón de problemas diferentes que requieren atención y este es solo uno de ellos. Paul simplemente declaró que hacer ping a este problema no es útil (que no lo es) y que si alguien lo quiere, tendrá que esperar a que alguien (incluido uno de los desarrolladores principales) decida hacer un esfuerzo considerable para cambiar el comportamiento predeterminado de millones o hacerlo ellos mismos.

Somos conscientes de que la gente quiere esto, lo que falta es alguien que esté dispuesto a desarrollar una solución que satisfaga las diversas preocupaciones y problemas que ya se han planteado, y que inevitablemente surgirán durante una revisión de relaciones públicas.

@pfmoore, ¿está consciente de que estos comentarios pueden denigrar los esfuerzos de los colaboradores? Eso es lo que me parece. No estoy seguro de si siguió toda la historia de este problema, pero en este caso particular está muy fuera de lugar.

@rgommers ¿En serio? Ese comentario fue de hace meses y fue citado fuera de contexto aquí (pero, francamente, no tengo ningún problema con que @pradyunsg lo

Si yo estaba tan "fuera de base", entonces podría haberlo dicho en mayo en el momento en que lo dije, en lugar de meterse con eso ahora, fuera de contexto.

Si ofendí a alguien, me disculpo, esa no era mi intención. Honestamente, estoy tan frustrado como cualquier otra persona de que este problema esté resultando tan difícil de lograr un diseño que sea aceptable para todos. En mis comentarios, trato de lograr un equilibrio; por un lado, realmente aprecio las contribuciones que hacen las personas, pero por otro lado, creo que es importante dejar en claro a las personas que en un tema como este, el la codificación es, francamente, el menor trabajo necesario. Muy a menudo, los colaboradores no aprecian este hecho, y ahí es donde obtenemos relaciones públicas incompletas, donde las personas se frustran con el trabajo necesario para persuadir a las personas de que su diseño está bien y / o reelaborar el cambio, posiblemente de la manera en que no lo hacen '. Realmente me gusta tener en cuenta las opiniones de otras personas (¡a menudo contradictorias e inconsistentes!). Prefiero que lleguen al proceso con una comprensión de lo que está involucrado, en lugar de hacerlo con expectativas poco realistas y, como resultado, tener una mala experiencia.

Todos los involucrados en las discusiones sobre este tema han dedicado mucho tiempo a debatir los pros y los contras de varios enfoques. No creo que haya nadie que esté contento con el tiempo que está tardando. Personalmente, la falta de un comando upgrade-all (solo una parte del cambio, y no es probable que sea el que se implemente primero) me afecta de manera regular. Ocasionalmente (sinceramente, es mucho más que "ocasionalmente") las personas (generalmente personas que en realidad no han contribuido a la discusión o al código) comentan "esto es importante, ¿por qué no lo ha implementado todavía?" Francamente, es difícil mantener la calma y _no_ insultar a esas personas.

En un proyecto que funciona bien, los desarrolladores principales que realmente se preocupan por el problema

¿Se da cuenta de que este comentario está abierto a ser interpretado como diciendo que a los desarrolladores de pip no les importa arreglar esto (y por implicación de pip)? Todos corremos el riesgo de redactar las cosas de una manera que pueda ofender a las personas. Estoy seguro de que no quiso decir esto como una crítica a los desarrolladores de pip, por favor asuma que tampoco estoy tratando de ofender a nadie.

organizaría un Hangout rápido y tomaría algún tipo de decisión.

Me sorprendería que algo así funcionara aquí, pero estoy dispuesto a intentarlo. No estoy seguro de quién se involucraría o cómo lo manejaríamos, pero seguro, si ayuda y alguien quiere probar ese enfoque. Yo diría que, dado que este cambio tiene un gran potencial para afectar a los usuarios de pip, cualquier decisión tomada en un canal privado como este probablemente debería redactarse como una propuesta y publicarse para comentarios generales, y sospecho que hacerlo simplemente desencadenaría otra ronda más de los mismos debates que hemos tenido.

O delegue a una o dos personas para que trabajen lo suficiente como para llegar a esa conclusión.

¿Estás diciendo que una decisión tan importante debería ser tomada unilateralmente por un par de personas? Tal vez esa sea la única forma en que obtendremos una resolución, pero no es realmente la forma en que se toman las decisiones en pip (a diferencia de Python, no tenemos un BDFL con autoridad ejecutiva para tomar decisiones). Puede afirmar que eso no nos convierte en un "proyecto que funciona bien" si lo desea, ese no es mi punto de vista, pero podemos no estar de acuerdo con eso si lo desea.

O al menos disculparse y agradecer al remitente de relaciones públicas,

No estoy seguro de por qué deberíamos disculparnos, pero si ayuda, me disculparé felizmente, por el hecho de que nadie le dio una comprensión clara de lo difícil que sería completar esta propuesta. o le ayudó a gestionar el debate y guiar a los participantes hacia un consenso. Pero para ser justos, no creo que nadie _más_ involucrado supiera en ese momento que este sería el caso, por lo que creo que aquí se habla principalmente en retrospectiva.

Ciertamente tiene mi agradecimiento. Es bastante fácil decir "eso es evidente", pero no debería: los proyectos de código abierto no agradecen lo suficiente a los contribuyentes, y eso es un problema. Mientras hablo del tema, me gustaría agradecer a todos los que han contribuido a este debate, y lo digo en serio, ya que sé por experiencia lo agotador que puede ser. Pero especialmente a @pradyunsg por ser la víctima actual de todas las interminables discusiones y cambios de rumbo. ¡Gracias por no rendirte! (¡¡Aún!!)

en lugar de culparlo por "no seguir adelante".

Bueno, no creo que haya ninguna culpa (aunque es difícil saber si se sintió culpable, ya que ya no está). Pero es cierto que su PR original no se logró hasta el final. Sin embargo, eso es solo un hecho. Espero que nadie esté sugiriendo que los contribuyentes tengan derecho a que se acepten sus RP, simplemente porque los enviaron. No todos los RP son aceptables cuando se envían por primera vez, necesitan ser revisados ​​y actualizados y, a veces, incluso después de todo el trabajo, todavía no son aceptables. Lo siento, pero así es la vida.

[Si parezco duro en la declaración anterior, me disculpo (¡de nuevo!). Pero gran parte de mi tiempo libre lo paso leyendo y lidiando con las quejas que yo (o proyectos en los que estoy involucrado) de alguna manera no he hecho lo suficiente. Y es un círculo vicioso: pierdo la motivación para trabajar en código abierto en mi tiempo libre debido a las molestias, lo que, por supuesto, significa que se hace aún menos. Aunque trato de ser educado, a veces no es fácil]

No planeo decir nada más en esta meta-discusión sobre cómo se gestionan las relaciones públicas. Pasé una hora esta noche trabajando en esta respuesta, para tratar de evitar decir algo que pudiera ofender a alguien (y apuesto a que fallé :-(). Y podría haber pasado mucho mejor ese tiempo: con mi familia, relajándome, o hacer algo más productivo.

Entonces, ¿puedo sugerir que volvamos a tratar de ayudar a @pradyunsg a crear un RP con el que todos podamos estar contentos y dejar de lado las meta-discusiones infructuosas?

Entonces, ¿puedo sugerir que volvamos a tratar de ayudar a @pradyunsg a crear un RP con el que todos podamos estar contentos y dejar de lado las meta-discusiones infructuosas?

Sí, por favor. :inocente:

Oh, lo olvidé.

@rgommers dijo:
Y eso fue incluso antes de que apareciera @pradyunsg , quien está mostrando una notable persistencia.

Tomaré esto como complemento ... Gracias.

@pfmoore dijo:
especialmente a @pradyunsg por ser la víctima actual de todas las interminables discusiones y cambios de dirección. ¡Gracias por no rendirte!

Eres bienvenido.

(¡¡Aún!!)

Realmente espero que no llegue a ese estado. Sería una situación realmente mala si lo hiciera, en mi opinión. (Soy arrogante de esa manera)

Escribí lo siguiente mientras revisaba la historia y pensé que bien podría ponerlo aquí, para referencia futura y dejar que otros me corrijan por si acaso.

• Decidí trabajar en esto después de darme cuenta de cómo sería la gran relación no técnica: técnica (es mucho más grande de lo que _realmente_ pensé de manera conservadora) y dándome cuenta de que ya ha habido un intento fallido en esto.
• Escribí sobre el estado de las cosas, porque estaba aburrido y necesitaba saber qué sucedió de todos modos.
  
  
  
  • Probablemente dediqué más tiempo (¿y espacio aquí?) Del que necesitaba, pero al menos obtuve una buena descripción general del problema para mí (¿y para todos los demás?).
  
  
• Me emocioné demasiado después de escribirlo. : smiley: ¡Se lo mostró al mundo!
• Se inició una discusión (¡larga!) Sobre la implementación de un comando de actualización.
  
  
  
  • Algunas ideas útiles surgieron en las discusiones. Se crearon nuevos problemas para el mismo.
  
  
• La discusión lleva a la idea de cambiar el comportamiento de instalación a upstall, lo que haría actualizaciones no ansiosas de forma predeterminada y eliminaría una parte de la funcionalidad proporcionada por la opción --target - 3 cosas.
  
  
  
  • Aquí es donde cometimos un error: agrupar los 3 cambios (bastante) independientes y que se implementarían como uno solo, porque nadie se dio cuenta de esta parte.
  
  
• Implementé lo mismo. Dado que los 3 cambios se agruparon, todos se atascaron cuando no hubo consenso sobre cambiar el comportamiento de instalación a upstall, el cambio potencialmente controvertido.
• La falta de consenso inició una larga discusión que llegó al punto en que la gente se retiró de la discusión y supongo que casi la empujó al agotamiento.
  
  
  
  • Algunas de las suposiciones anteriores se rompieron y se decidió que primero haríamos un cambio de interrupción mínimo.
  
  
• Me quedé sin tiempo libre para trabajar en esto, así que creé algunos problemas nuevos para que alguien más pueda trabajar en ellos de forma independiente y, idealmente, no cometa el mismo error que nosotros aquí.
• Atascado.
• ¡Ya estoy de vuelta! Intentaré hacer el cambio a actualizaciones no ansiosas de forma predeterminada antes del 25 de septiembre.

Sí, concentrémonos en arreglar pip install --upgrade y dejemos todo lo demás por ahora. De todos modos, ese es un requisito para cualquier otro trabajo.

@pfmoore @dstufft gracias por las

No responderé a todo, porque nadie busca aquí una discusión larga.

podría haberlo dicho en mayo en el momento en que lo dije,

Entonces estuve lejos de Github durante 2 meses, pero me molestó cuando vi ese comentario por primera vez.

¿Estás diciendo que una decisión tan importante debería ser tomada unilateralmente por un par de personas?

Todas las opciones sobre la mesa son mucho mejores que el status quo. Y después de 5,5 años y muchos cientos de comentarios repartidos en varios problemas / relaciones públicas aquí y en la lista de correo, no estoy seguro de que más comentarios vayan a resolverlo. Espero que se resuelva, pero si esto se estanca nuevamente, definitivamente sí, nomine a una o un par de personas y simplemente tome una decisión.

No estoy seguro de por qué deberíamos disculparnos, pero si ayuda, me disculparé felizmente, por el hecho de que nadie le dio una comprensión clara de lo difícil que sería completar esta propuesta. o le ayudó a gestionar el debate y guiar a los participantes hacia un consenso.

Me refiero a lo último. A veces cambio de opinión sobre una decisión para uno de mis proyectos, eso sucede. Entonces me siento responsable de dejar clara la nueva dirección. Y disculparme si no tengo tiempo para lidiar con las consecuencias de ese cambio (solo toma 30 segundos ...).

Pero es cierto que su PR original no se logró hasta el final. Sin embargo, eso es solo un hecho.

Eso es una vista, no un hecho. En mi opinión, el RP estaba completo, todo lo que quedaba por hacer era presionar el botón verde o rechazarlo. Hizo todo lo que esperaría de un colaborador.

Después de su respuesta, me di cuenta de que las expectativas que los desarrolladores de pip tienen de los contribuyentes y los desarrolladores centrales son muy diferentes de prácticamente cualquier otro proyecto con el que estoy familiarizado. Espero que los desarrolladores principales guíen a los nuevos colaboradores, los animen, les den retroalimentación cuando sea necesario y los ayuden a resolver problemas polémicos (para los que la mayoría de los colaboradores no tienen las habilidades ni el interés en ellos, y aquellos que las tienen a menudo terminan convirtiéndose en desarrolladores centrales) si necesario. Les está diciendo a los nuevos colaboradores: _ "tienen que administrarnos. Podemos cambiar de opinión, no estar de acuerdo entre nosotros o perder el interés; es su trabajo administrar eso" _. Quizás esa es la naturaleza de este proyecto y tiene que ser así, no lo sé.

Mientras hablo del tema, me gustaría agradecer a todos los que contribuyeron a este debate.

Acordado. Gracias a todos los que contribuyeron.

• y lo digo completamente en serio, ya que sé por experiencia lo agotador que puede ser.

Está drenando. Personalmente, me quedo aquí y en distutils-sig porque es importante para el ecosistema de Python y los usuarios de mis paquetes, pero ambos lugares no me dan exactamente energía positiva.

En caso de que pasara desapercibido - # 3972: smile:

Les está diciendo a los nuevos colaboradores: "tienen que administrarnos. Podemos cambiar de opinión, no estar de acuerdo entre nosotros o perder el interés; es su trabajo administrar eso". Quizás esa es la naturaleza de este proyecto y tiene que ser así, no lo sé.

Dije que no continuaría con esto, pero este punto me llamó la atención. No es así como me siento con respecto a nuestro enfoque, pero ahora que lo expresas de esa manera, veo que puede resultar de esa manera. Para ser honesto, "podemos cambiar de opinión, no estar de acuerdo entre nosotros o perder el interés" es cierto; después de todo, todos somos solo personas con otros compromisos también, pero no lo considero como algo que un nuevo contribuyente deba "gestionar". Por el contrario, es solo una realidad de tratar con la gente, pero si hacer demasiado de ello parece arrojar el problema a los nuevos contribuyentes, está mal.

Gracias por señalar esto. Intentaré tenerlo en cuenta y evitar dar esa impresión en el futuro.

Creo que gran parte del problema realmente se reduce al hecho de que estamos muy faltos de personal, lo que hace que sea difícil mantenerse al día y hacer un seguimiento de todo. Hay más contribuyentes potenciales que nosotros, por lo que es fácil sentirse abrumado cuando hay varias personas que intentan hacer cambios a la vez. Los cambios más grandes, o los cambios donde no hay un consenso claro, tienden a ser los más difíciles de manejar, por lo que son los que tienden a sufrir más :(

La triste situación es que, si bien creo que a todos nos gustaría estar aquí para ayudar a guiar a todos los colaboradores a lo largo del proceso, simplemente no tenemos la mano de obra. Esto también tiende a tener un ciclo un poco viscoso, porque no tenemos la mano de obra para hacer eso, no encontramos fácilmente personas nuevas que parezcan haber comenzado a asimilar la mentalidad detrás de cómo opera pip y que hayan aprendido suficiente (porque no estamos allí para enseñarles) para darles los derechos de compromiso de pip. Esto significa que estamos constantemente sin personal y luchando solo para mantener la cabeza fuera del agua (al menos, así es como me siento. Semanas constantes de 70 a 90 horas es muy difícil para una persona: /).

@pradyunsg Reviewing # 3972 está en mi lista de TODO, pero aún no lo he hecho.

@pradyunsg Reviewing # 3972 está en mi lista de TODO, pero aún no lo he hecho.

¡Gracias!

Esto significa que estamos constantemente sin personal y luchando solo para mantener la cabeza fuera del agua (al menos, así es como me siento. Semanas constantes de 70 a 90 horas es muy difícil para una persona: /).

Eso es dificil. Numpy y Scipy estaban en esa situación cuando comencé a trabajar en eso. No es divertido. Aprecio todo lo que estás haciendo.

Este problema ahora es muy largo y muy antiguo, se han discutido muchas cosas, han sucedido demasiadas cosas y este problema casi ha alcanzado una señal / ruido bajo. Es difícil ver lo que ha sucedido.

FWIW, la razón por la que upgrade estaba en las tarjetas fue por el hecho de que install --upgrade tiene un valor predeterminado roto. Dado que ahora estamos un paso más cerca de solucionarlo, creo que es mejor que tengamos un nuevo problema para eso.

Sugiero que se cierre este problema debido a lo anterior y que se creen nuevos problemas para lo que aquí se considere no resuelto. Puedo ver 2 cosas:

• Cambie la estrategia de actualización predeterminada a only-if-needed .
• Agregue la funcionalidad "actualizar el mundo" que depende de # 988.

El 15/9/16, Nick Coghlan [email protected] escribió:

@RonnyPfannschmidt Los usuarios de Windows todavía superan en número a los usuarios de Linux ~ 18 a 1, y
no tienen nada comparable a una comunidad de administración de paquetes de distribución
recurrir en este punto (mientras que la tecnología central está allí en los últimos
versiones, las comunidades de empaquetado y curación no lo son). Eso significa que son
mucho más dependiente de herramientas de nivel de usuario como pip y conda para recoger el
flojo.

No es entonces
actualización de conda --todos
¿suficientemente bueno?

@ Liso77
Bueno, no, no lo es.

Conda y pip son herramientas con diferentes objetivos. Esta es una gran lectura sobre este tema. El tercer punto es el más relevante.

Si la discusión para actualizar todas las superficies nuevamente (con suerte en un nuevo número), mi voto es para deletrearlo de la siguiente manera:

pip install --upgrade :all:

pip install --upgrade :all: es extremadamente extraño. Sigamos con la semántica POSIX, que básicamente todo el mundo está haciendo hoy en día: pip install --upgrade --all

¿Qué pasa con pip install --upgrade sin ningún nombre de paquete o especificadores? ¿Demasiado fácil de ejecutar accidentalmente?

pip-tools lo hace así por pip-compile -P .

Tal vez deberíamos poner la bicicleta en un cobertizo una vez que tengamos algún tipo de trabajo
implementación ... :)

El domingo, 12 de febrero de 2017, 20:55 FichteFoll [email protected] escribió:

¿Qué tal simplemente instalar pip - actualizar sin ningún nombre de paquete o
especificadores? ¿Demasiado fácil de ejecutar accidentalmente?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pypa/pip/issues/59#issuecomment-279225595 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ADH7SfnSBflH8rK3nFLw1hvYBaovjbcGks5rbyRUgaJpZM4AJ4Py
.

¿Qué tal una versión de pip list --outdated que produce su lista en un formato que puede ser ingerido directamente (es decir, sin sed , cut , etc.) por pip install --upgrade (por ejemplo, pip list --outdated --format install | xargs pip install --upgrade o algo similar con comillas invertidas)?

Cualquiera que sea la sintaxis que se utilizará, lo más importante es introducir este comando, es increíble que todavía falte

mientras tanto te sugiero que pruebes
https://github.com/jgonggrijp/pip-review
con pip-review --local --interactive pregunto paquete por paquete si desea actualizar, no muy bien pero mejor que nada

@ SMH17 Es totalmente creíble que todavía esté ausente, ya que no hay exactamente ningún proveedor comercial de Python que proporcione formalmente tiempo de desarrollo financiado para trabajar en las mejoras de usabilidad del empaquetado de Python en nombre de sus clientes.

Entonces, si desea que la situación mejore, es probable que lo más útil que pueda hacer personalmente sea alentar a su proveedor de soporte de Python a invertir tiempo de desarrollador en mejorar las herramientas que usa, o si no tiene un proveedor de soporte aún, anime a su empleador a pagar uno.

Como contexto adicional con respecto a la falta de urgencia en torno a este tema, vale la pena tener en cuenta que las recomendaciones generales son para

• mantenga las definiciones de su entorno de trabajo bajo control de fuente para mejorar la reproducibilidad en otros sistemas (usando algo como https://github.com/jazzband/pip-tools o https://github.com/kennethreitz/pipenv para mantener esas definiciones actualizadas )
• Apuntar a actualizar rutinariamente a nuevas versiones de dependencias para minimizar las ventanas de exposición a vulnerabilidades de seguridad desconocidas o no reveladas.

Eso no significa que los comandos propuestos aquí no sean útiles, solo son notablemente menos valiosos si el entorno de trabajo actual ya se mantiene a través de pip-compile + pip-sync , o pipenv lock + pipenv install .

Sería valioso actualizar la descripción original, ya que supongo que se han realizado algunos cambios en pip install desde la actualización realizada por @qwcode.

Hola a todos.

Rompí algunas de las dependencias de mi paquete de Python debido al siguiente comando:

pip install --upgrade packageName ha actualizado paquetes de forma recursiva.

¿Por qué no cambiar el comportamiento predeterminado de la opción --upgrade , es decir, desinstalar y reinstalar SOLO el paquete dado desde la línea de comandos?

Qué tal esto ?

@sebma Creo que el comportamiento predeterminado no debería cambiarse. Quizás podrías intentar usar la bandera -no-dependencies la próxima vez. Debería funcionar: +1:

@sebma , @aaossa , les haré saber a ambos que prácticamente ya se ha decidido que la estrategia de actualización predeterminada cambiará en el futuro (ref: https://github.com/pypa/pip/issues/3871# número comentario-247789343). La característica necesaria (es decir, el argumento --upgrade-strategy ) se ha agregado en https://github.com/pypa/pip/pull/3972.

Como @pradyunsg mencionó anteriormente , este problema es una especie de sobra. La primera parte ya está manejada (vea mi primer párrafo) y la segunda parte es la única razón por la que este paquete todavía está abierto, al parecer. No sé si se ha creado un problema de "actualizar todo" desde entonces.

Lancé un buen mejorador interactivo para el archivo de requisitos: https://github.com/simion/pip-upgrader

Cambie la estrategia de actualización predeterminada a solo si es necesario.

4500 hicieron esto.

Agregue la funcionalidad "actualizar el mundo" que depende de # 988.

4551 para una discusión sobre esto.

Abordar los puntos señalados en la publicación superior actual:

La actualización de pip sería como la instalación de pip --upgrade, excepto que no sería recursiva por defecto (y ofrecería una opción --recursive). Su comportamiento predeterminado recursivo actual ha causado dolor a muchos (# 304). En cuanto a cómo realizar actualizaciones no recursivas ahora, consulte aquí.

Se ha decidido no agregar un comando de actualización o hacer que pip install actualice los paquetes ya instalados. pip ahora tiene actualizaciones no recursivas por defecto, con el comportamiento recursivo disponible detrás de --upgrade-strategy eager .

pip upgrade-all actualizaría todos los paquetes instalados.

4551 existe y sería bueno tener una nueva discusión sobre esto; cuando el # 988 esté listo.

@dstufft @xavfernandez @pfmoore ¿

_{Editar (18/05/2017): puntuación + texto menor agregado}

Parece razonable.

Hola a todos,
Hice un guión / esencia simple que hace el trabajo.

https://gist.github.com/serafeimgr/b4ca5d0de63950cc5349d4802d22f3f0

¿Por qué no simplemente hacer esto?

pip install --upgrade $(pip list --outdated | awk '{print $1}' | tr '\n' ' ')

Porque no es tan fácil en realidad, ya que puede instalar versiones que no satisfacen algunas de las dependencias de sus otros paquetes.

Basado en y gracias a la esencia de @serafeimgr , he escrito una herramienta de línea de comandos posiblemente útil, pip_upgrade_outdated ; fuente en github . Comentarios bienvenidos.

(Consulte también este problema : Sí, la ejecución en paralelo es particularmente peligrosa y, sí, esto puede romper cosas. No obstante, muchas personas ejecutan algo como esto a mano todo el tiempo, por lo que puede resultarle útil).

Gracias por tomarse el tiempo para crear una solución completa.
Aunque mi recomendación sería encontrar una manera de impulsar esta función a pip.

Creo que pipenv & pipfile reemplazarán pip / requirements.txt de todos modos.
Tal vez @kennethreitz sepa más sobre la hoja de ruta y la función --upgrade all.

@qoheniac | tr ... es redundante.

Este hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para errores relacionados.