Acordado. O comportamento atual do pip para links de dependência é realmente uma droga.

4295

3610

[Escreveu no # 3939, movendo meu comentário aqui]

Então, aqui está o problema principal: se eu não quiser usar um arquivo requirements.txt (porque, digamos, quero dependências declarativas todas especificadas em setup.cfg ), como devo especificar um URL como dependência?

Isso não funciona:

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

Eu também acho que os links de dependência são estranhos e fáceis de descartar, mas canonicamente como esse caso de uso é atendido se não com eles?

Outro problema é que dependency_links aparentemente não pode ser especificado em setup.cfg, apenas como argumentos setup.py. Se eles não forem reprovados, isso deve ser consertado.

Existe alguma notícia sobre isso? Existe alguma alternativa em andamento? dependency_links_ parece ser a única opção para distribuição interna / privada de bibliotecas.

Em vez de descontinuá-lo, deveria ser consertado, muitas pessoas esquecem ou ficam confusas porque se esquecem de colocar a versão do nome da biblioteca em install_requires e no link de dependência que contém o tarbal junto com o ovo. Como alternativa, adoraria ver que @jleclanche sugeriu um link simples para o tarball em install_requires (especificar o ovo pode ser opcional).

Não acho que estamos sozinhos: https://stackoverflow.com/questions/3472430/how-can-i-make-setuptools-install-a-package-thats-not-on-pypi

Ferramentas @robertour como devpi suportam uma abordagem mais clara há anos

@dstufft btw - gostaria de argumentar que a existência de devpi demonstra uma solução mais limpa para o problema, tornando os links de dependência desnecessários

Herança do índice IMHO + lista branca / lista negra é mais consistente e mais compreensível no nível de operações

@RonnyPfannschmidt , obrigado pela sugestão, parece que estou perdendo algo importante (as discussões sobre essa suspensão de uso estão acontecendo há muito tempo), mas de modo geral, não posso concordar mais com este comentário do reddit :

O devpi pode ser uma solução, mas trazer outro serviço para o jogo que precisa de manutenção e ter que esperar a configuração de algum administrador não vai me fazer trabalhar tão cedo. Além disso, ainda teríamos a necessidade de construir pacotes e, em seguida, colocá-los no devip (ou tem devpi um recurso para rastrear repositórios git ??)

O ideal é uma alternativa que não leve mais do que adicionar um arquivo à minha biblioteca ou algumas linhas no setup.py.

Basicamente, não entendo a decisão subjacente de removê-lo, posso ver como isso pode levar a práticas inadequadas e inseguranças, mas desde que seja mantido para uso interno, não deve ser um grande problema.

4175 significa que o suporte de URL PEP 508 estará lá no pip 10. Acho que isso pode ser fechado.

Pensamentos @pfmoore @dstufft?

Achei que https://github.com/pypa/pip/pull/4175/commits/86b07792e7ae762beeaeb471ab9db87e31bc285d significava que a sintaxe @ não pode ser usada para dependências, então isso significa que # 4175 não é uma solução para esse problema . Os comentários ali eram que não deveríamos implementar o suporte @ para dependências até que o PyPI fosse capaz de bloquear os uploads que o usavam (porque não queremos instalar algo do PyPI para poder pegar coisas de URLs arbitrários , presumivelmente).

Não deve ser descontinuado até que haja uma alternativa em vigor, ou seja, suporte PEP 508. Até então, muitas pessoas estão usando.

Qual é o fluxo de trabalho adequado para isso?

Digamos que haja uma biblioteca à qual preciso adicionar um recurso. Eu garfo no Github. O recurso não será mesclado tão cedo, então tenho uma ferramenta que configurei para usar meu fork do Github em vez do PyPi.

Agora, todos os meus usuários precisam adicionar --process-dependency-links ao instalar minha ferramenta com pip, que é um sinalizador obsoleto e até mesmo uma vez removido?

Existe alguma opção em setup.py que estou perdendo ou realmente não há maneira de contornar isso? Parece que a única maneira viável de fazer isso é empurrar um pacote pypi bifurcado. De qualquer forma, isso só aumentará a confusão do usuário quando sua solicitação pull for mesclada.

Vamos resolver isso.

--process-dependency-links realmente não tem uma alternativa hoje. Portanto, vou sugerir que prossigamos e retiremos seu uso.

No entanto, o sinalizador significa que o pip alcançará URLs arbitrários - ele deve ter um aviso anexado sobre isso.

@pradyunsg, a menos que haja um plano real para

eu não acho que as pessoas que realmente precisam têm qualquer incentivo para consertar a situação, a menos que pip diga "NÃO, eu não assumo sua dívida"

Como mantenedor do pip, minha preocupação é não permitir que o pip seja um vetor para exploits. Pip assume PyPI como o índice padrão, portanto, há confiança implícita no PyPI aí. Então, minhas primeiras perguntas são:

1. Existem pacotes no PyPI que têm dependency_links metadados?
2. O PyPI poderia ser modificado para recusar o upload de projetos com dependency_links (ou já faz isso)?
3. Alternativamente, o pip poderia simplesmente se recusar a processar links de dependência (independentemente de a opção estar definida) para pacotes baixados do PyPI?

Se pudéssemos ter certeza de que não há como os usuários do pip serem picados por pacotes no PyPI com dependency_links maliciosos, eu ficaria menos preocupado. Os usuários que optam por usar um índice personalizado precisam decidir por si próprios se devem confiar nele. (Eu ainda preferiria manter o sinalizador mesmo assim - isso é potencialmente um exploit remoto e deve sempre ser explicitamente opt-in).

Portanto, com as seguintes alterações:

1. Pip nunca processará links de dependência de PyPI (explicitamente ou apenas porque sabemos que eles não estão lá)
2. O sinalizador --process-dependency-links não está obsoleto, mas só funciona para índices personalizados.

Eu ficaria bem em aceitar isso como o status quo. Pessoas que precisam de um recurso de estilo de link de dependência podem então debater entre si como (se é que desejam) seguir em frente.

Se alguém quisesse, poderíamos colocar tudo isso em um padrão de metadados de vínculo de dependência, e a depreciação atual se tornaria "o comportamento atual será abandonado em favor do comportamento especificado no padrão". Mas de um ponto de vista centrado no pip, eu prefiro apenas fazer isso - deixar as pessoas que precisam de links de dependência assumir o trabalho de padronização (é para seu benefício, afinal, já que eles têm um caminho - obter uma mudança padrão - para modificar o comportamento de pip com total consenso da comunidade).

Basicamente, temos um recurso que visa substituir os links de dependência, mas o pip não começou a respeitá-lo ainda, porque ainda não temos uma maneira de bloquear uploads para o PyPI que o utilizam.

Você quer dizer # 4175? Qual está bloqueado por causa de 86b0779? Talvez pudéssemos modificar https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167 para dar o erro apenas se comes_from for PyPI?

Então, poderíamos alterar o aviso de suspensão de uso de --process-dependency-links para dizer que os usuários deveriam mudar para a sintaxe @ e abandonar --process-dependency-links após um período de suspensão de uso razoável (teríamos que começar o relógio correndo a partir do ponto em que a sintaxe @ torna-se disponível).

@pfmoore Sim, é exatamente isso, e parece um caminho possível a seguir.

OK. Se ninguém mais descobrir primeiro, vou providenciar para que você escreva um PR.

Pelo que percebi, o problema do usuário aqui é que eles precisam passar uma opção que diz explicitamente "ei, estou obsoleto" quando você a passa para uma funcionalidade que não tem uma alternativa.

Sou a favor de descartar o suporte dependency_links inteiramente durante um período de depreciação. E, nesse meio tempo, adicionando suporte de dependência de URL PEP 508, que eu acho que pip ainda deve ser barulhento quando usado e que eles ainda devem ser opt-in.

Isso significaria:

• colocar a capacidade de processar PEP 508 url-deps atrás de uma bandeira
  
  
  
  • à parte: deve nomear o sinalizador de forma que um usuário preocupado com a segurança verifique os documentos
  
  
• comece a recusar-se a instalar url-deps PEP 508 quando eles vierem de um pacote PyPI
• links de dependência continuam obsoletos, mas temos uma data para descartá-los
  
  
  
  • honestamente, não quero dar a isso mais um período de suspensão de uso do que um único lançamento com a alternativa.
  
  

Eu digitei isso ontem, mas não enviei. Agora percebo que é basicamente a mesma coisa que o último comentário de @pfmoore .

_yay!

Os departamentos de URL devem exigir um sinalizador de aceitação? O PEP 508 não diz isso, e a implementação atual não faz isso. Posso ver a lógica, mas não confio em meu julgamento sobre questões de segurança versus facilidade de uso.

Além disso, gostaria de ver uma documentação clara sobre como os projetos devem mudar de links de dependência para a sintaxe @ antes de começarmos a fazer a mudança. Já é difícil o suficiente para alcançar pessoas que serão afetadas por depreciações, e avisos de que eles não conseguem descobrir como resolver não vão ajudar. Idealmente, o aviso deve incluir uma indicação para um documento "como mudar", IMO.

Não confio no meu julgamento sobre questões de segurança versus facilidade de uso.

Estou inclinado a: "ser seguro por padrão" e optar por um comportamento menos seguro.

documentação clara sobre como os projetos devem mudar de links de dependência para @ sintaxe antes de começarmos a empurrar a mudança

Parece bom para mim.

Estou inclinado a: "ser seguro por padrão" e optar por um comportamento menos seguro.

Como alguém que fica muito atrás para lidar com restrições de firewall e segurança em meu trabalho, estou bem ciente de que não temos muito conhecimento do tipo de ambiente em que esse recurso é provavelmente mais útil (desenvolvimento interno, código fechado , fluxos de trabalho e layouts de rede rigidamente controlados, etc.). Portanto, minha inclinação é estar seguro para o fluxo de trabalho padrão (PyPI), mas não colocar obstáculos adicionais no caminho das pessoas com casos de uso que são claramente importantes para seu fluxo de trabalho, mas onde não entendemos adequadamente as compensações que eles devem faça.

Em minha opinião, "se o pacote vier de um servidor que você explicitamente optou por usar" é uma opção suficiente para permitir links de URL.

Ver? Não é que eu não tenha opiniões, só que não tenho certeza se meus preconceitos não estão aparecendo: sorria:

não colocar obstáculos adicionais no caminho das pessoas com casos de uso que são claramente importantes para seu fluxo de trabalho, mas onde não entendemos adequadamente as compensações que eles precisam fazer.

É justo. Se alguns usuários pudessem fornecer informações sobre seu fluxo de trabalho, isso seria ótimo.

"se o pacote vier de um servidor que você explicitamente optou por usar" é uma opção suficiente para permitir links de URL.

Não tenho certeza aqui. : /

Ver? Não é que eu não tenha opiniões, só não tenho certeza se meus preconceitos não estão aparecendo 😄

Ele Ele.

É justo. Se alguns usuários pudessem fornecer informações sobre seu fluxo de trabalho, isso seria ótimo.

Em minha opinião, "se o pacote vier de um servidor que você explicitamente optou por usar" é uma opção suficiente para permitir links de URL.

Permitir apenas as fontes do GitHub resolveria 99% do problema para mim. Os pacotes upstream têm bugs ou recursos ausentes. Eu os bifurco e corrijo, emito um PR e, em seguida, espero por um tempo possivelmente muito longo para que sejam mesclados e, em seguida, lançados no PyPI. Nesse ínterim, meus pacotes contam com as correções desses pacotes.

Isso pode ser opt-in, desde que possa ser feito em uma linha.

Não é realmente um problema de segurança usar links diretos (assumindo HTTPS / etc), é apenas um problema de disponibilidade. Uma vez que não os estamos permitindo do PyPI, eu diria que isso é bom o suficiente e não precisamos de outro sinalizador.

No meu trabalho cairíamos em alguns dos casos de uso
Embora, eu também veja o possível caso de uso de alguém se referindo a um local do sistema de arquivos ...
Faria sentido fornecer uma lista de hosts / locais permitidos? O nome do flag deve IMO, como @pradyunsg sugeriu, ser descritivo o suficiente para alertar o usuário dos riscos envolvidos. Talvez --whitelisted-host ?

@masdeseiscaracteres Acho que você pode ter entendido mal - eu estava sugerindo que se um pacote fosse recuperado do PyPI, falharíamos se qualquer uma de suas dependências fosse especificada por meio de uma referência @ . Mas não deveria haver nenhum desses casos no PyPI (esperamos rejeitá-los em algum momento, mas ainda não conseguimos configurar isso). Todos os outros usos de referências de @ seriam adequados.

Parece que vamos prosseguir com um PR que faz o que é descrito por @pfmoore em https://github.com/pypa/pip/issues/4187#issuecomment -389846189.

PRs bem-vindos. :)

Observe que não tive tempo para chegar a isso - não porque a mudança seja difícil (como observado, parece ser simplesmente um cheque contra comes_from ), mas sim porque não sei como provocar o me engano (e mais importante, não sei escrever um teste que o faça). Se alguém puder fornecer um exemplo de tal caso de teste, isso seria extremamente útil.

Se alguém puder fornecer um exemplo de tal caso de teste, isso seria extremamente útil.

Existe um teste existente test_install_pep508_with_url_in_install_requires que demonstra isso.

Quanto a erros ao instalar a partir do PyPI, não vejo uma opção melhor do que realmente fazer o upload de algo no PyPI que tem um requisito de URL. 😞 Fiz upload de um pacote no PyPI para essa finalidade. https://pypi.org/project/pep-508-url-deps/

Outra coisa é - comes_from não é um URL ou caminho, é uma string ao longo das linhas de 'box==0.1.0 from file:///private/tmp/box' . Quem está procurando consertar esse problema, agora tem que descobrir uma maneira melhor de errar, para que tenhamos informações sobre a origem de um pacote. :)

@pfmoore, este problema é muito caro ao meu coração 😄 O upload de @pradyunsg fornece o que você precisa, e você ainda planeja resolver isso? Se não, eu poderia tentar.

@bstrdsmkr Não, e como @pradyunsg diz, não é tão simples quanto eu pensava, já que comes_from não é o URL de origem. Portanto, não sei quando terei tempo agora (não tenho uso pessoal para esse recurso, então não está no topo da minha lista de prioridades).

Conforme observado acima, os PRs dão as boas-vindas :-)

Acrescentarei que o pacote carregado não ajuda em nada para a implementação, só é útil para testar a funcionalidade.

Meu entendimento é que a correção desejada é algo como:

if req.url and is_like(req.url, PYPI.url):
    raise

em https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172
onde is_like() retorna True se os urls forem enraizados no mesmo domínio. Isso é correto?

Sim. Eu penso que sim. Essa será a mudança de código.

E, precisaremos adicionar / atualizar testes e uma entrada NEWS.

Também acho que essa mudança é importante o suficiente para garantir a chance de a mensagem de descontinuação fornecer um link para documentos + uma seção adicional no guia do usuário informando às pessoas como mudar para a alternativa.

Como mantenedor do pip, minha preocupação é não permitir que o pip seja um vetor para exploits. Pip assume PyPI como o índice padrão, portanto, há confiança implícita no PyPI aí.

Não, existe confiança explícita. E adicionar salvaguardas contra o uso de fontes externas em dependências IMHO não vai melhorar a situação: é mais conveniente ocultar malware em pypi do que em um VCS disponível publicamente.

IMHO, uma abordagem melhor seria usar os VCSs do desenvolvedor como fontes primárias e manter o pypy como um registro apontando para eles e um proxy de cache com alguma prova criptográfica forte de que o conteúdo do VCS é idêntico ao obtido do pypy. Quero dizer

0 registro

dev -- public key --> pypa

1 enviando

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2 ocioso:

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2 recuperando

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1 as fontes instaladas correspondem às do VCS por causa da assinatura
2 o autor combina também
3 pypa pode trapacear com novos usuários, mas trapacear pode ser detectado por usuários antigos
4 autor pode trapacear exibindo um branch de interface da web diferente do fornecido para pypy e enviar para pypy outro branch. Não funcionará bem se fizermos do branch uma parte obrigatória do URI.

@KOLANICH Acho que você quer dizer PyPI (Python Packaging Index) quando diz pypy / pypa. PyPy é uma implementação alternativa de Python. PyPA (Autoridade de Empacotamento Python) é um grupo de voluntários que mantêm projetos importantes no espaço de Empacotamento Python. Por favor, corrija os acrônimos ou evite usá-los.

Você está sugerindo alterar fundamentalmente o design de um serviço bem estabelecido existente. Se você deseja ter essas mudanças importantes, pode fornecer pelo menos um plano de transição (viável) e uma implementação POC, para gerenciar / alterar a arquitetura para permitir a transição / minimizar a interrupção dos fluxos de trabalho existentes. Observe que depender da hospedagem externa é algo que foi explicitamente removido do PyPI no passado no PEP 470 ; no entanto, esse foi um caso bem diferente do que você está sugerindo.

O PyPI é mantido por voluntários, funcionando em infraestrutura doada / patrocinada. Você está sugerindo que ele se conecte por meio do Tor, outro serviço mantido / executado por voluntários. Ambos são projetos principais e têm um custo associado para mantê-los em execução, mesmo que não sejam diretamente gerenciados / visíveis para seus usuários.

No entanto, este não é o lugar certo para esta discussão. Se você deseja propor um redesenho do PyPI, sugiro que reinicie a discussão em https://github.com/pypa/warehouse.

Obrigado pelas sugestões.

Consulte # 5571 - o PR para saber por que foi enviado para uma versão posterior.

O aviso no log de instalação do PIP fornece este URL, mas não há solução para o problema nem aqui nem nos outros tickets mencionados.

Além disso, isso é ainda mais confuso: o que você quer dizer quando diz PyPI? Você quer dizer qualquer servidor que implemente a interface PyPI (por exemplo, Artifactory) ou, especificamente, pypi.org?

Agora, obviamente, alguém que deseja apoiar a instalação de um pacote através de setuptools (também conhecido setup.py install ) e usando pip install ficará em apuros. Especificar links de dependência é a única maneira de alguém nesta situação lidar com vários pacotes interdependentes.

Agora, corrija-me se eu estiver errado, mas até agora parece que se você remover isso com base em qualquer decisão que o PyPA tenha feito sobre uploads para seus servidores, você, basicamente, tornará pip inúteis para usuários do Artifactory / empresas que possuem repositórios privados com pacotes interdependentes.

Por favor, me diga que estou errado e perdi algo em toda esta história (eu estava acompanhando isso intermitentemente por um tempo). Eu tinto o PEP 508, mas não faz muita diferença nesse aspecto, pelo menos não vejo como isso melhoraria ou pioraria as coisas.

@ wvxvw-traiana Acho que você perdeu o PR # 5571
Antes desse PR (e na versão atual - 18.0), o pip se recusará a instalar qualquer dependência especificada por meio da sintaxe PEP508.

Depois disso, o PR (já mesclado, deve estar no 18.1+), o pip só recusará tais dependências se o pacote que depende delas vier de pypi.org.

Se você instalar um pacote de seu repositório privado que depende de coisas do pypi, obviamente está tudo bem.
Se você instalar um pacote de pypi.org que depende de coisas do seu repositório privado, isso falhará.
Se você instalar um pacote de seu repo privado que depende de coisas em seu repo privado, tudo bem.

Espero que ajude a esclarecer as coisas

@bstrdsmkr É a mesma origem ou pypi é um caso especial? Ou seja

Se você instalar um pacote de seu repo privado, que depende de coisas de um repo privado diferente.

Para adicionar mais contexto sobre as razões por trás disso:

1. Os links de URL diretos permitem que um pacote acione o download e a execução de um código arbitrário de qualquer lugar na Internet. Tudo bem se você estiver assumindo a responsabilidade pelo pacote fazendo isso, então permitimos links de URL diretos com base nesse entendimento.
2. As pessoas esperam instalar a partir do PyPI (especificamente do PyPI, não dos índices de pacote em geral) e confiam nos pacotes que baixam de lá. Para evitar o comprometimento de um pacote PyPI expondo um grande número de usuários Python, não permitimos que pacotes vindos de PyPI dependam de links de URL diretos (porque impõe uma carga muito grande para nossos usuários insistirem que eles têm que auditar tudo do PyPI que eles usam para links para código externo).
3. Os links de dependência são um mecanismo específico do setuptools e são processados ​​pelo maquinário interno do setuptools, não pelo pip. Portanto, ao contrário dos links de URL diretos, não temos nenhum controle sobre o que eles fazem. É por isso que os substituímos em favor do formulário de URL direto padrão, que nós mesmos administramos.

alguém que deseja oferecer suporte tanto à instalação de um pacote por meio de setuptools (também conhecido como execução de setup.py install) quanto ao uso de pip install, ficará em apuros.

Se verdadeiro, é porque o setuptools não implementou suporte para links diretos de URL, que é um padrão acordado. Sinta-se à vontade para falar sobre isso com eles.

Se você instalar um pacote de seu repo privado, que depende de coisas de um repo privado diferente.

Isso funciona bem. PyPI não está envolvido.

OK, então, por um lado, estou feliz que isso não me afete.

Por outro lado, essa "correção" parece, como eu diria ... muito fácil de contornar.

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

Não é da minha conta, realmente, mas parece uma abordagem muito superficial. (O outro vetor de ataque foi mencionado em outros comentários, onde você pode simplesmente baixar o que quiser em setup.py).

Não é projetado para ser difícil para os usuários a resolver pelos usuários. É um meio de oferecer uma solução (limitada) para o fato de que o PyPI ainda não tem uma maneira de bloquear as pessoas de fazer upload de pacotes com dependências de URL diretas. Consulte https://github.com/pypa/pip/pull/4175#issuecomment -266305694 para algum contexto.

@dpwrussell pypi.org é um caso especial. Qualquer repo privado para qualquer repo privado funciona bem após a alteração.

@ wvxvw-traiana não foi feito para impedi-lo de fazer isso sozinho. Destina-se a impedir que outra pessoa faça isso quando você pensa que está apenas instalando um pacote de pypi.org

Não relacionado à discussão atual, estou reabrindo isso, pois não atualizamos o aviso de suspensão de uso para isso.

5726 adiciona linguagem sugerindo o uso de URLs PEP 508, que IMO é o último bit necessário para isso.

Está bem então. Deixe-me resumir:

• os links de dependência ainda estão obsoletos e agora estão programados para remoção no pip 19.0.
• a substituição padrão para ele é as dependências de URL PEP 508
• Ao instalar a partir do PyPI, se um pacote tiver dependências de URL PEP 508, isso fará com que o pip aborte a instalação.

@pfmoore elaborou as razões para essas decisões aqui: https://github.com/pypa/pip/issues/4187#issuecomment -415067034

@pradyunsg Quando as dependências de URL PEP 508 serão permitidas em install_requires no setup.py? Existe uma data definida?

No próximo lançamento do pip - que é 18.1, agendado para outubro. Você pode ler mais sobre o ciclo de lançamento de 3 meses do pip em https://pip.pypa.io/en/latest/development/release-process/. :)

https://github.com/pypa/wheel/issues/249 precisa ser resolvido antes que as dependências de URL PEP 508 se tornem uma alternativa viável.

O pypa / wheel # 249 precisa ser tratado antes que as dependências de URL do PEP 508 se tornem uma alternativa viável.

Isso foi resolvido.

Nas notas de versão 18.1 do pip, diz

Permitir que os requisitos de URL PEP 508 sejam usados ​​como dependências.

Como medida de segurança, o pip levantará uma exceção ao instalar pacotes do PyPI se esses pacotes dependerem de pacotes não hospedados também no PyPI. No futuro, o PyPI bloqueará o upload de pacotes com essas dependências de URL externas diretamente. (# 4187)

Então, isso basicamente significa que as dependências podem ser especificadas usando URLs, mas se essas não forem URLs PyPI, o pacote não pode ser instalado usando pip? Talvez eu esteja entendendo tudo errado, mas como as dependências de URL devem ser usadas então?

Os pacotes

Os pacotes que NÃO são hospedados no PyPI podem ter dependências de url. Se você instalar o pacote diretamente do github (por exemplo), as dependências do url serão resolvidas e instaladas. Um exemplo de tal instalação:

pip install git+https://github.com/bstrdsmkr/some_package.git

Essencialmente, se você instalar a partir de um url, pode depender dos urls, caso contrário, não. E apenas para maior clareza, ele também pode ter dependências url e não url

Uma pequena adição:

... se você instalar a partir de um url, pode depender dos urls

... se você instalar a partir de um URL (VCS ou outro) ou de um arquivo local ou índice de pacote que não seja PyPI, ele pode ...

Então, há uma versão do pip que processa install_requires de acordo com as descrições acima? Não consigo descobrir nas tags acima qual era o estado final e a documentação do pip atual aponta para a documentação install_requires em ferramentas de configuração que ainda diz para usar dependency_links .

Não posso falar com os documentos sozinho, mas este "relaxamento" para permitir que pacotes não-PyPI instalem dependências de urls foi lançado no pip 18.0

AFAIK, as dependências de URL em install_requires são suportadas desde o pip 18.1:

Permitir que os requisitos de URL PEP 508 sejam usados ​​como dependências.

Fonte: notas de lançamento

Ugh, erro de digitação da minha parte - @pietrodn está obviamente correto

Eu quero deixar um pequeno, mas bem sucedido exemplo aqui para aqueles que primeiro se depararam com este problema apavorados (como eu) sobre o que fazer com nossos --process-dependency-links. Usando este fluxo de trabalho, meus usuários agora podem instalar pip a partir do GitHub ou de fontes locais (não PyPI), ou pip install requirements.txt ou python setup.py install e trabalhar no Travis-CI, com pip versão 18+, então acho que cobre muitas bases. Espero que seja útil para alguém, e minhas desculpas se isso parecer fora do assunto para os outros:

Em seu arquivo requirements.txt, supondo que você deseja que as pessoas possam depender do branch dev do GitHub do pacote "foo", por exemplo:

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

Em seu arquivo setup.py:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

Alguns diriam que confundir install_requires e requirements.txt é imprudente, e para uma versão lançada, eu concordo, mas acho que isso funciona bem para o desenvolvimento.

Ah, legal. Portanto, se digamos que os pacotes "A" e "B" usam esse método e o pacote "A" lista "B" como uma dependência, quando você instala "A", ele acaba processando o arquivo requirements.txt para "B" (o que normalmente não acontece) - certo?

Também li esta manhã que o próprio install_requires era meio ruim porque essas instalações foram feitas por setuptools, o que significa que qualquer opção de pip foi ignorada, mas não sei se essa informação está desatualizada ...

Também li esta manhã que o próprio install_requires era meio ruim porque essas instalações foram feitas por setuptools, o que significa que qualquer opção de pip foi ignorada, mas não sei se essa informação está desatualizada ...

Você está confundindo install_requires com setup_requires .

Ah, legal. Portanto, se digamos que os pacotes "A" e "B" usam esse método e o pacote "A" lista "B" como uma dependência, quando você instala "A", ele acaba processando o arquivo requirements.txt para "B" (o que normalmente não acontece) - certo?

@stevebrasier Sim, acho que sim, o que pode ser um problema se você fixou versões diferentes de outros pacotes necessários em A e em B.

Olá pessoal, só gosto de observar que o caminho da suspensão de uso, nesse caso, foi muito curto. Eu sei que os links de dependência foram marcados como obsoletos por um bom tempo, mas PEP 508 URLs, que podem ser usados ​​para substituí-los, não foram implementados até 18.1. Como resultado, havia apenas uma janela de 3 meses para mudar de links de dependência para requisitos de URL, que é um tempo muito curto para projetos grandes.

@rgerkin Olá, estou tentando seguir suas instruções sem sucesso,

Procurando PACKAGE @ git + ssh: //[email protected] : PROPRIETÁRIO / PACKAGE. git @ BRANCH
Lendo https://pypi.org/simple/PACKAGE/
Não foi possível encontrar a página de índice para 'PACKAGE' (talvez com erros ortográficos?)
Verificando índice de todos os pacotes (isso pode demorar um pouco)
Lendo https://pypi.org/simple/

PACOTE @ git + ssh: //[email protected] : PROPRIETÁRIO / PACOTE. git @ BRANCH , isso está em install_requires.

Você teria uma ideia de por que estou recebendo o acima?

@KevinMars Existem algumas diferenças entre meu exemplo e o que você tem, incluindo o uso de git_ssh, bitbucket, sufixo a.git, um branch nomeado e nenhuma tag de versão. Talvez uma ou mais dessas coisas estejam levando o pip a pesquisar no PyPI em vez de em sua URL. Qual versão do pip você está usando?

Para comentar algo que descobri: Usar setup.py para instalar o pacote com python setup.py install ainda requer declarações de dependências externas em dependency_links .

Em seu arquivo setup.py:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

@rgerkin Obrigado por compartilhar esta solução. Mas e se eu estiver usando o pbr para configurar meu pacote Python? Como adaptar isso para caber no pbr?

@KevinMars Tenho exatamente o mesmo problema. Você já descobriu a solução? Estou tentando exigir um branch específico de um repositório bitbucket privado sobre SSH.

Acabei de perceber --process-dependency-links não existiam mais. Sou grato por todo o trabalho que a comunidade realiza. Tentar justificar a decisão em discussões intermináveis ​​e um labirinto de fechamento e redirecionamento de questões foi a solução escolhida, mas ainda acho que deixar essa opção não teria prejudicado ninguém.