Hmm, talvez precisemos de um comando para listar todas as versões de pacotes disponíveis no PyPI.
O que você acha?

Como:

$ pip list Django

1.2.4

1.2.3

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

$

Original Comment By: Hugo Lopes Tavares

Eu gosto daquela ideia.

Original Comment By: CarlFK

Acabei de implementar no meu fork. quero as opiniões de carljm, jezdez e ianb
antes de fundir.

Confira aqui: https://bitbucket.org/hltbra/pip-list-
comando/changeset/e5c135a46204

Original Comment By: Hugo Lopes Tavares

Eu não pensei sobre isso profundamente, mas parece-me melhor melhorar o
comando "search" para também listar versões (talvez listar todas as versões com um sinalizador -v
ou algo assim), em vez de adicionar um novo comando separado. Esta funcionalidade
parece ser logicamente uma parte da pesquisa.

Original Comment By: Carl Meyer

Eu ficaria bem em adicionar isso à pesquisa, desde que meu outro ER seja implementado
também para que eu não obtenha 3000 linhas (realmente) quando procuro as versões do django.
(há mais de 1000 acessos para "pip search django" por causa de todos os django-foo
pacotes. )

Original Comment By: CarlFK

Acho desnecessário mostrar qual versão seria instalada desde que
existe uma lista de versões disponíveis, porque é fácil determinar qual
estes são os mais recentes. Além disso, não há razão para usar um novo sinalizador para
habilitar a saída desta lista, porque a sobrecarga tende a zero. Isso é
apenas uma pequena mudança:
https://bitbucket.org/jumpa/pip/changeset/62076643cf33

Original Comment By: jumpa

Oi Carl, pensei em adicionar uma opção ao comando de pesquisa, mas meu medo
aconteceu o que aconteceu ao comando de instalação: se você quiser "atualizar" um
pacote, você precisa usar a opção "instalar" - isso é estranho, e nós sabemos disso.

E se a maioria das pessoas acha que adicionar uma opção de pesquisa é melhor, eu também não vejo
muito problema em usar search --versions ou search -v.

Original Comment By: Hugo Lopes Tavares

Acho que listar todas as versões disponíveis por padrão é muito detalhado. Algum
os pacotes têm muitas versões disponíveis no pypi - dez ou vinte não é incomum
em absoluto. Listando a versão mais recente por padrão e todas as versões com um sinalizador
parece razoável.

E eu concordo com o CarlFK que também precisamos de melhorias para tornar a busca
mais fácil de estreitar. O problema é que dependemos do que a API do PyPI nos dá,
o que não é muito: não vamos baixar todo o PyPI e fazer um regex
procure localmente! Eu seria a favor de algo como --exact flag para pesquisar como
parte desta mudança, então você pode procurar por exemplo "--exact django" e só obter
django em seu resultado.

Original Comment By: Carl Meyer

Oi jumpa, Ótima ideia para mostrar as versões usando a obtida do xmlrpc
conexão!

Eu tenho o seguinte recorte procurando por pip:

pip                       - pip installs packages.  Python packages.  An

substituição easy_install (versões: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1,
0,6, 0,6,1, 0,6,2, 0,6,3, 0,7, 0,7,1, 0,7,2, 0,8, 0,8,1, 0,8,2)

Esta será uma lista tão grande de pacotes, usando muitas versões -
porque nossa busca se preocupa com nomes e resumos. Devemos nos importar com isso?

Original Comment By: Hugo Lopes Tavares

Como usuário final, gosto da ideia de ter um comando de lista separado*. Como o tempo
vai em um comando separado talvez mais fácil de modificar e aprimorar isoladamente. Para
tornar um comando de lista separado mais útil você pode indicar qual versão, se
qualquer, está atualmente instalado.

pip list Django


1.2.4

1.2.3 installed

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

Nota: Muitos gerenciadores de pacotes populares como YUM(RedHat), pkglist(BSD),
dpkg(Debain) fornece um sinalizador ou comando de lista separado.

Original Comment By: Kelsey Hightower

Carl, eu estava pensando outro dia sobre esse assunto, e tenho que concordar com
Kelsey: outro comando não é ruim.

Pense em usar um sinalizador para indicar que eu quero apenas esse nome de pacote e
outro sinalizador para indicar que quero recuperar todas as versões disponíveis.

É um pouco estranho.

Vamos tentar ilustrar:

$ pip search -v --exact Django

contra

$ pip list Django

A ideia de Kelsey de mostrar qual versão está instalada apenas melhora a lista
comando.

Original Comment By: Hugo Lopes Tavares

Eu fiz as alterações no comando de pesquisa.

Como o comando search já mostra a versão instalada e mais recente disponível, provavelmente faz mais sentido aumentar o comando search para listar também todas as versões disponíveis.

Aqui está meu conjunto de alterações: https://github.com/phuihock/pip/commit/46bad23b5bf31850a02803ea1ca18be5deca9db3

Qual é o status disso? Pode-se ver a versão mais recente disponível no PyPI usando pip?

Isso já está implementado? Isso tem me incomodado por cerca de dois anos, e eu adoraria ver isso resolvido.
A pesquisa limitada combinada com um sinalizador de versões parece uma solução muito útil.

Só queria acrescentar aqui que acabei de encontrar este tópico enquanto pesquisava como mostrar versões ... Tentei pip search -v package - de alguma forma isso faria sentido intuitivo para mim: uma descrição detalhada do pacote para ser instalado, incluindo informações de versão...

Eu _apenas_ percebi que essa funcionalidade ainda não foi implementada depois que um colega meu me perguntou sobre isso. Existem planos de que ele estará disponível nas próximas versões do pip ?

Acredito que este PR pode ser relevante, que está sendo trabalhado no momento?

Você também pode estar interessado na palestra do Linuxconf 2014 "Python Packaging 2.0: Playing Well With Others" sobre a situação atual, bem como o futuro, do empacotamento python. O palestrante disse (se entendi corretamente) que algumas das limitações nos metadados no pip são consequência do design do PyPI, que foi originalmente baseado no CPAN, e que retrabalha o backend do PyPI (enquanto permanece compatível com o atual usando testes) deve melhorar a situação. Ele estava falando principalmente sobre "integradores de sistema", ou seja, empacotadores downstream, mas acho que isso afetaria coisas como esse problema, tornando-as mais fáceis de resolver.

+1.000.000

e como está agora?

Agora, existe alguma maneira de mostrar qual versão é a mais recente sem instalá-la?
Este problema está aberto desde 2011 e o patch que vi acima é apenas uma linha. :(

Este parece ser um recurso menor para habilitar, como não há uma opção equivalente a dizer apt-cache madison neste momento?

Eu realmente gostaria de ver a versão mais recente do pacote PyPi ao pesquisar também. Ter uma correspondência exata funciona, mas eu uso o awk como solução alternativa.

Isso também me frustrou e, vendo que há pouca ou nenhuma esperança nisso, decidi que criar uma alternativa pode valer a pena. Juntamente com esse problema, implementei alguns outros recursos solicitados (como pesquisa de regex e saída colorida, etc.). Se tiver interesse pode conferir aqui

wget -qO- https://pypi.python.org/pypi/uWSGI | egrep -o "uwsgi-[0-9].[0-9].[0-9][0-9].tar.gz" | classificar -u

wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep '"version"'

@andreif Isso nem sempre encontrará a versão correta (pip ignora alfas, betas, candidatos a lançamento, etc., a menos que --pre seja fornecido). Isso é mais próximo (mas também não há garantias):
wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep -E ' {8}"[0-9."]*": \[' | sort -V | tail -n 1 | tr -d ' ":['

Ok, então a resposta JSON deve incluir algo como "pre-version": "1.2.3a4" , então pode-se grep ambos com uma expressão simples.

Eu realmente não entendo essa questão... O que é isso?

• Adicionando uma nova opção em pip install que faria o pip rodar somente até a resolução dos pacotes e imprimir os pacotes selecionados e sair (pulando a instalação)?
• Mostrando a versão mais recente ao lado dos nomes dos pacotes ao usar pip search ?
  
  
  
  • Poder ver a versão mais recente de um pacote no PyPI?
  
  

O último parece ter sido resolvido para mim e o primeiro provavelmente deve receber um novo problema dedicado.

@pradyunsg Bem, se bem me lembro, eu precisava de uma maneira simples de verificar qual versão está disponível atualmente (versão e pré-lançamento). Esta versão será instalada por pip install -U [--pre] .

Eu precisava disso para um script configurando um virtualenv. Quando havia uma versão mais recente de um pacote, ele perguntava se era para atualizar ou manter a versão atual. Portanto, este caso de uso é coberto pela nova pesquisa de pip.

pkg="foo"; pip install --download /dev/null --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Postar --download -versão de depreciação...

pkg="foo"; tmp="$(mktemp -d)"; pip download -d "$tmp" --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | tr A-Z a-z | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Usando algo como:

pip install foo==

fornece uma lista de todas as versões disponíveis (para um pacote pypi válido disponível, molécula neste caso):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

mas seria bom poder obter a versão que seria instalada usando pip sem realmente fazer o download e/ou instalá-la em dev/null :-)

Acordado. Um gerenciador de pacotes sem essa funcionalidade é meio que uma piada. Mesmo o seu exemplo de obter uma lista de versões é um hack completo para compensar outro recurso que este gerenciador de pacotes não possui. Não digo isso para ser mau, mas essas são coisas que deveriam estar disponíveis bem antes de oito anos atrás, quando esse bug que é totalmente ignorado foi criado. Eu suponho que o pip será substituído por algo que de fato tem mais recursos, mas também é abominável, grotesco, monstruosamente grande e complicado demais. Oh bem, podemos sempre escrever o nosso próprio.

pip-tools é uma ferramenta baseada em pip que acredito que pode ajudar com algumas das coisas que as pessoas neste tópico estão perguntando: https://github.com/jazzband/pip-tools

Se você fornecer uma lista de dependências abstratas (ou seja, sem versões especificadas), ele informará as versões específicas de cada requisito e dependência a ser instalada.

pkg="django"; echo "$pkg" | pip-compile - --output-file - | egrep -i '^'"$pkg"'=' | cut -d '=' -f 3- é tão bobo quanto (mais bobo se você contar que é outra coisa que você precisa instalar [mais bobo se você precisar de suporte a python2])

Além disso, todo o ponto de pip-tools (& pipenv) pode ser realizado com pip simples e um arquivo de restrições. ( pip install -r reqs -c constraints; pip freeze > constraints ).

Adicionando uma nova opção em pip install que faria o pip rodar somente até a resolução dos pacotes e imprimir os pacotes selecionados e sair (pulando a instalação)?

Acabei de realizar algumas tarefas domésticas significativas aqui, e esse problema agora é para rastrear/discutir esse caso de uso + se/como o pip mudaria para acomodar essa solicitação de nova funcionalidade.

Eu escondi um monte de comentários, desde comentários realmente antigos que não têm mais o contexto relevante anexado, até aqueles que incluíam "potenciais hacks / pepitas de script" para fazer 90% do trabalho para isso. Para o último grupo, evite postar mais aqui -- há outros fóruns de suporte ao usuário onde essas sugestões seriam mais apropriadas, não no fórum para discutir como implementar a correção na própria ferramenta. :)

Desculpas a qualquer um cujo comentário ainda-relevante e útil foi escondido; Eu realmente não consegui descobrir o contexto de muitos comentários e o seu pode ter ficado escondido em danos colaterais.

Como este ticket está bloqueado pelo desenvolvimento do resolvedor de dependências (#988), pensei em mencionar aqui que a equipe está procurando ajuda da comunidade para avançar nesse assunto.

Precisamos entender melhor as circunstâncias em que o novo resolvedor falha, então estamos solicitando que usuários pip com dependências complexas:

1. Experimente o novo resolvedor (use a versão 20.1, execute --unstable-feature=resolver )
2. Quebra :P
3. Registrar um problema

Você pode encontrar mais informações e instruções mais detalhadas aqui

Um caso de uso que gostaria de destacar que surgiu da experimentação em # 7819 que ainda não vi mencionado neste tópico é especificamente gravar URLs para download e instalação de pacotes posteriores , que é uma funcionalidade ligeiramente ortogonal aos arquivos de bloqueio discutidos acima e é especificamente útil para consumir os resultados de uma resolução de pip sem precisar baixar nenhum arquivo grande.

Estamos desenvolvendo um método de empacotamento para grandes aplicativos de aprendizado de máquina no Twitter, que estamos chamando de "ipex", que podem ser enviados sem conter código de terceiros até que sejam executados pela primeira vez (o que reduz bastante seu tamanho). No caso de pantsbuild/pants#8793, geramos um arquivo pex executável que chama a biblioteca de tempo de execução pex para resolver os requisitos (o pex executa o pip nos bastidores). Atualmente, estou trabalhando em um protótipo que substitui a etapa de resolução completa do pex/pip em tempo de execução por uma substituição que registra apenas os URLs para baixar as dists (o req.link ). Isso é extremamente rápido na prática (e pode ser armazenado em cache de forma muito granular), pois o download e a cópia do arquivo para criar o arquivo pex "hidratado" podem ser realizados inteiramente em paralelo.

Essa capacidade (de baixar e instalar toneladas de rodas/não rodas em paralelo) depende adicionalmente apenas da exposição da URL de qualquer roda ou não roda que colocaríamos em um arquivo de bloqueio, que ainda não vejo mencionado aqui. Isso permite que pants invoquem pip exatamente uma vez (para resolver URLs de download) quando um arquivo ipex desidratado é criado e, em seguida, o resultado dessa etapa de "resolver" com URLs pode ser consumido para requisitos de download quando o arquivo ipex é invocado pela primeira vez em um arquivo completamente máquina diferente sem ter que invocar o pip novamente.

Foi necessário muito esforço em #7819 para propagar as URLs das entranhas do resolvedor v1 para a saída. Foi muito menos esforço quando tentei fazê-lo funcionar com o resolvedor v2. No momento, provavelmente estamos planejando enviar alguma versão experimental de um comando --dry-run ou resolve internamente que exibe URLs de download - se fizermos isso com sucesso, esperamos ajudar a aumentar qualquer problemas restantes com --unstable-feature=resolver enquanto isso! :D :D

Como você mencionou, o design do formato do arquivo de bloqueio é ortogonal à implementação do resolvedor. No entanto, isso também significa que está fora do escopo do projeto pip atual. Houve discussões sobre o tópico (aviso: tópico muito longo), mas considerando a falta de tempo disponível para o desenvolvedor, isso significa que uma discussão séria provavelmente não acontecerá antes que o resolvedor seja pelo menos estabilizado.

Obrigado pelo link!!

No domingo, 24 de maio de 2020 às 19:34 Tzu-ping Chung [email protected]
escrevi:

Como você mencionou, o design do formato do arquivo de bloqueio é ortogonal ao
implementação do resolvedor. No entanto, isso também significa que está fora do escopo para o
projeto pip atual. Houve discussões sobre o tema
https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/1
(aviso: thread muito longo), mas considerando a falta de tempo do desenvolvedor
disponíveis, isso, por sua vez, significa que uma discussão séria provavelmente não
acontecer antes que o resolvedor seja pelo menos estabilizado.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pypa/pip/issues/53#issuecomment-633346918 ou
Cancelar subscrição
https://github.com/notifications/unsubscribe-auth/AAJ6UT3IK65CUQGUIOGBNVDRTHKMVANCNFSM4AIQRXLA
.

@cosmicexplorer Você já enviou internamente aquela versão experimental de um comando --dry-run ou resolve ? Se sim, como vai?

Você deve ter notado que estou extremamente interessado nesse recurso 😄

Usando algo como:

pip install foo==

fornece uma lista de todas as versões disponíveis (para um pacote pypi válido disponível, molécula neste caso):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

mas seria bom poder obter a versão que seria instalada usando pip sem realmente fazer o download e/ou instalá-la em dev/null :-)

Belo truque!! Útil e conveniente !! Realmente impressionante !!

possíveis hacks/pepitas de script ... por favor, evite postar mais do último aqui -- há outros fóruns de suporte ao usuário onde essas sugestões seriam mais apropriadas, não no fórum para discutir como implementar a correção na própria ferramenta. :)

Não é à toa, de verdade, mas esse é o tipo de coisa que acontece quando você deixa um bug durar muito tempo (7,56 anos no caso do meu "pepita" mais recente, embora esse bug ainda aberto tenha agora 9,25 anos velho). As pessoas compartilham suas soluções alternativas.

Também duvido que ocultar comentários, incluindo soluções alternativas, ajude as pessoas a perceber que a solução alternativa que estão prestes a postar em um comentário é desnecessária (em parte porque ninguém vai clicar em todos esses comentários ocultos para ver o que já foi dito). Quando alguém chega a um bug de uma década e não encontra algum tipo de progresso ou direção dos mantenedores, ou uma solução alternativa, ouso dizer que eles considerarão necessário compartilhar uma solução alternativa, porque fazer outras pessoas sofrerem com o trabalho que você já fez-se é desnecessário.

E sim, esse mesmo comentário também é o que acontece quando acontece o que você fez em resposta a esse bug ainda aberto.

Não se preocupe, eu, pelo menos, não adicionarei mais comentários não provocados, a menos que pip quebre meu script novamente e esse bug ainda esteja aberto.

Obrigado pelo que você faz. :)

@brainwane @ei8fdb Quero sinalizar esse problema como importante do ponto de vista do UX - relacionado ao #8377

Resumo de alto nível com base no meu entendimento:

• com o novo resolvedor, o pip será menos permissivo e se recusará a instalar dependências conflitantes ( ResolutionImpossible )
• conflitos de dependência podem existir em qualquer lugar na árvore de dependência
• ferramentas existentes (pipdeptree pip-conflict-checker) mostram apenas pacotes que já estão instalados, não aqueles que foram solicitados, mas falharam
• Atualmente, não há como os usuários descobrirem onde o conflito de dependência é _antes_ de um pacote ser instalado ou quando ocorre um erro ResolutionImpossible (além de inspecionar manualmente as dependências de cada projeto)

Resumindo, precisamos de uma maneira para os usuários detectarem possíveis conflitos de dependência com base em seus requisitos de nível superior (ou seja, os pacotes especificados em requirements.txt ou inseridos diretamente na linha de comando).

Se decidirmos fazer isso, o nome do sinalizador proposto ( --dry-run ) deve ser pesquisado/discutido.

@uranusjr @pfmoore - corrija-me se tiver algo errado ou perdido algo com base em nossa discussão. THX

@nlhkabu Concordo com todos os seus comentários acima. No entanto, apenas para ficar claro, um estilo de comando --dry-run permitirá que os usuários verifiquem se haverá um conflito de dependência. Mas, conforme descrito, ele não oferecerá nenhuma ajuda adicional para diagnosticar por que o conflito existe. Portanto, é basicamente um comando de instalação "olhar antes de pular", em contraste com a abordagem normal "pedir perdão", onde instalamos se pudermos, mas não fazemos nada e relatamos o erro se não.

O que isso não fornece e que é algo que o IMO seria muito útil (como um subcomando pip ou tão útil quanto uma ferramenta de terceiros) é uma maneira de listar como é a árvore de dependência da qual o pip está trabalhando . (Isso não requer um resolvedor ou uma etapa de instalação real, é "simplesmente" listando de forma transitiva os metadados de dependência das fontes do pacote).

Isso também pode assumir a forma de um comando pip resolve .

pip resolve é o que a maioria esperaria, por favor, chame assim 😄 Também permitiria suas próprias bandeiras eventualmente.

Obrigado pelo esclarecimento @pfmoore. Do ponto de vista do usuário, não tenho certeza de quanto uso --dry-run é sem resolve ?

IMO, não é suficiente dizer aos usuários que eles receberão um erro - também precisamos fornecer informações suficientes para descobrir onde está e fazer algo a respeito.

Então, imagine que um usuário execute --dry-run ... poderíamos incluir algo assim na resposta:

Conflito de dependência detectado. pip não poderá instalar d 1.0 e c 1.0.
O conflito é causado por:
d 1,0 depende de E==2,0
c 1,0 depende de E==1,0
Execute pip resolve para inspecionar a árvore de dependências.

Também poderíamos reutilizar pip resolve na mensagem de erro ResolutionImpossible (veja #8377), o que seria uma grande vitória.

@pradyunsg temos um ingresso separado por pip resolve ?

@nlhkabu https://github.com/pypa/pip/issues/7819

Além disso, só para ficar claro, acredito que o caso de uso pretendido para pip resolve seja (assumindo sucesso):

1. redirecionar a saída para um arquivo (que geralmente será confirmado) ou
2. outras ferramentas usarão/analisarão a saída

Para o twitter, usando a ferramenta "ipex" conforme descrito em #7819, estamos criando arquivos pex executáveis ​​usando um comando pip resolve que produzirá URLs de download para todas as distribuições resolvidas em vez de baixar qualquer coisa (não sendo usado em produção ainda ). Isso, juntamente com várias outras otimizações, por exemplo, #8448, permite criar esses arquivos ipex em segundos. Esses arquivos ipex fazem o download de todas as distribuições de saída do comando pip resolve na primeira vez em que são executados, a partir do mesmo datacenter - isso permite que os próprios arquivos ipex sejam megabytes em vez de gigabytes, o que melhora o tempo de upload de muitas regiões.

Então basicamente incorporamos uma versão json da saída pip resolve como um arquivo no arquivo pex, e temos um script bootstrap que lê isso para baixar as distribuições em paralelo.

alguma atualização disso?

Alguém precisa descobrir como apresentar o resultado da resolução primeiro. Os mantenedores de pip do AFAIK envolvidos no trabalho do resolvedor estão atualmente se esforçando para melhorar o próprio resolvedor no momento, portanto, isso precisaria de ajuda externa para avançar.

Por favor, corrija-me se estiver errado, mas o seguinte parece ser verdade:

• A instalação de um pacote Python envolve a execução de seu setup.py.
• Sem uma opção --dry-run , não há uma maneira fácil e confiável de saber quais pacotes o resolvedor do pip escolherá instalar.

Portanto, parece-me que executar pip install significa consentir em executar código de uma seleção bastante arbitrária de pacotes PyPI em uma máquina sem uma maneira fácil e confiável de auditá-lo. Essa seleção depende recursivamente das escolhas de dependência e práticas de segurança de autores de pacotes individuais.

Depende se o projeto e a versão a ser instalada possuem apenas uma distribuição fonte (sdist, contém setup.py) ou também rodas (distribuição construída, contém um arquivo de texto de metadados, é instalado por cópias de arquivos sem que seja executado código arbitrário)

Mesmo com --dry-run, é provável que o pip precise executar backends de compilação para os pacotes (que para setuptools envolve executar o setup.py) que não possuem rodas.