Pip: Descontinuar pip, pipX e pipX.Y

eu gosto da mudança de pip para _pip,
dessa forma a implementação do pip vai para um namespace mais "privado"
a despesa é quebrar ferramentas que entram em pips internals

A outra despesa é que, se quisermos fazer uma API pública, estamos limitados a ter um único namespace (o que estiver em pip.py ) ou precisamos alterá-lo de volta para um pacote (e possivelmente quebrar o Python 2.6 novamente, a menos que tenhamos descontinuado até então).

Claro, podemos nunca fazer uma API pública, nesse caso, o ponto é discutível.

Não posso deixar de pensar que @warsaw e @ncoghlan provavelmente também têm algumas opiniões sobre isso.

Talvez @bkabrda também! e @tdsmith

Não subestime o poder desse primeiro ponto. A intertia é _alta_: muitas ferramentas assumirão pip e _lots_ de documentação estarão errados. Ter um longo ciclo de depreciação é basicamente obrigatório aqui. Caso contrário, acho que é uma boa ideia: +1.

-1 ao remover o pip, eu teria que alterar todos os meus scripts de implantação.
+1 na remoção de pipX e pipX.Y

Em terça-feira, 6 de outubro de 2015, às 08h16, Cory Benfield escreveu:

Não subestime o poder desse primeiro ponto. A intertia é
_high_: muitas ferramentas assumirão pip e _lots_ de documentação
estará errado. Ter um longo ciclo de depreciação é basicamente obrigatório
aqui. Caso contrário, acho que é uma boa ideia: +1.

— Responda a este e-mail diretamente ou visualize-o no GitHub[1].

Links:

1. https://github.com/pypa/pip/issues/3164#issuecomment -145839321

Não subestime o poder desse primeiro ponto. A intertia é _alta_: muitas ferramentas assumirão pip e _lots_ de documentação estarão errados. Ter um longo ciclo de depreciação é basicamente obrigatório aqui.

Sim, concordo plenamente. Eu essencialmente assumo que não devemos ter uma data de remoção definida (e possivelmente nunca) e apenas fazer com que ele registre uma mensagem para stderr.

Eu essencialmente assumo que não devemos ter uma data de remoção definida (e possivelmente nunca) e apenas fazer com que ele registre uma mensagem para stderr.

Eu não acho que isso vai funcionar. Apenas imprimir avisos irritantes sem uma data definida "sua merda vai quebrar até X" não ajuda muito: as pessoas simplesmente ignorarão os avisos. Eu acho que se você quiser fazer isso, você deve decidir uma data (possivelmente uma _longe_, mas ainda assim). Uma data possível para iniciar a discussão: quando a última versão do RHEL LTS com Python 2.6 deixar de ser suportada (isso ainda está muito longe, mas vale a pena discutir).

-1 ao remover o pip, eu teria que alterar todos os meus scripts de implantação.
+1 na remoção de pipX e pipX.Y

Eu não acho que faça sentido depreciar (não falando sobre remoção tão cedo) pipX e pipX.Y sem também fazer isso por pip já que esse é sem dúvida o pior infrator de todos eles.

Uma data possível para iniciar a discussão: quando a última versão do RHEL LTS com Python 2.6 deixar de ser suportada (isso ainda está muito longe, mas vale a pena discutir).

Esta é uma boa ideia.

Uma data possível para iniciar a discussão: quando a última versão do RHEL LTS com Python 2.6 deixar de ser suportada (isso ainda está muito longe, mas vale a pena discutir).

Isso é 30 de novembro de 2020 para o final da fase de produção 3 do RHEL 6. Eles têm um ciclo de vida estendido super especial além disso, mas talvez possamos apenas mirar em 2020 e se chegarmos a 2020 e o Python 2.6 ainda estiver de alguma forma com amplo suporte, nós o adiaremos ainda mais.

Outra alternativa seria parar de exigir que o pip seja executado no mesmo ambiente Python em que está instalando as coisas ...

Para ser honesto, não tenho certeza de como pip install -p python2.7 é melhor que python2.7 -m pip install . Temos que inspecionar o Python em que estamos instalando para obter informações dele, então ou vamos subshell nesse Python para embaralhar os dados para frente e para trás (como minha reescrita virtualenv pela metade faz) ou precisaremos continuar para ser executado pelo mesmo ambiente Python. Parece arrastar cadeiras de convés mais do que qualquer outra coisa.

Para essa ideia em particular, o principal benefício seria que você só teria que atualizar o pip uma vez.

Isso é verdade, o outro lado disso é que torna (um pouco) mais difícil suportar versões do pip mais antigas do que as que o próprio pip suporta, já que as instalações não são mais independentes (ou você precisará manter uma cópia mais antiga instalada Em outro lugar). Por outro lado, o pip poderia descartar mais facilmente o suporte para executar o comando binário principal pip em um Python específico, mantendo a compatibilidade para instalar _na_ essa versão do Python. Seria (continuaria) habilitar o agrupamento de todo o pip em um único arquivo zip que pode ser executado um pouco independentemente de realmente tê-lo instalado.

Ele não aborda o fato de que pip install --upgrade pip no Windows explode porque o sistema operacional tem um identificador aberto para pip.exe , o que eu acho que não pode ser resolvido sem usar python -m , pelo menos se eu entendi @pfmoore corretamente.

Acho que o @sYnfo quer comentar sobre isso mais do que eu, já que não mantenho mais o Python no Fedora/RHEL.

Ah, isso mesmo, eu esqueci. Desculpe!

(Mas, pessoalmente, acho que mesmo que eles sejam removidos, ainda os forneceremos no nível de distribuição na forma que for melhor para o conjunto de interpretadores Python que enviamos; pelo menos essa foi minha primeira ideia quando li a proposta. . Temos uma política geral para executáveis ​​Python que exige isso no Fedora.)

• +1 para descontinuação - mas eu ficaria feliz o suficiente simplesmente em descontinuar na documentação, não fazer os próprios scripts reclamarem do usuário.
• São apenas mais 6 letras no Windows - py -m pip :-)
• Para o 2.6, estou bem em deixar as pessoas continuarem a usar pip ou aconselhar python2.6 -m pip.__main__ . Eu não acho que vale a pena fazer alterações no pip para dar a eles qualquer outra solução.

A questão da inércia é enorme e não acho que devemos combatê-la diretamente. Em vez disso, devemos mudar a documentação para usar o formulário "python -m pip" e tornar esse formulário oficial da política PyPA (com o que quero dizer que nos esforçamos para usar esse formulário de forma consistente em tudo o que publicamos etc.). Talvez ofereça PRs para a documentação de instalação de projetos conhecidos para alterá-los para o novo formulário. Podemos nos preocupar em descontinuar formalmente e/ou remover os scripts assim que o formulário python -m pip começar a ganhar um pouco de tração no uso comum.

Acho que meu critério de sucesso é fazer disso o encantamento que as pessoas recebem do StackOverflow. Atire para a lua, etc etc.

Acho que publicar uma mensagem de intenção de descontinuação vinculável com uma justificativa pode ajudar a convencer mantenedores de terceiros a aceitar PRs de documentação.

A mensagem aqui é complicada, porque depreciar pip não significa depreciar _pip_...

Acho que a única alternativa real é a sugestão de Daniel. Acho que a situação atual é péssima e não consigo pensar em uma maneira de salvar a tentativa de gerenciar versões de pip usando um sufixo ou prefixo ou qualquer coisa que não acabe realmente especificando em qual interpretador você deseja executar.

Estou com +1 por descontinuação - parece fazer muito sentido do ponto de vista upstream e não vejo nenhum problema que isso possa causar downstream.

No Fedora isso significaria enviar todos os binários durante o período de descontinuação, como fazemos agora; e não enviá-los depois. Sincronização perfeita com upstream, espero. :) Vou garantir que todos os documentos do Fedora sejam atualizados, quando isso for oficializado.

( @bkabrda Se eu entendi as diretrizes corretamente, elas apenas obrigam o envio de todos os executáveis ​​MAJOR.MINOR _iff_ existem executáveis ​​em primeiro lugar, esse problema parece ser sobre a remoção completa dos executáveis ​​pip, certo?)

Também +1 para manter o pip ou usar python -m pip.__main__ com python 2.6.

Alguns pontos que não apareceram:

• Isso não apenas move o problema para python ? Por que python (de várias versões e em vários virtualenvs) é mais fácil de acompanhar do que pip ?
• Se você estiver usando um virtualenv (o que a maioria das pessoas deveria usar), pip refere-se inequivocamente ao ativo. Uma solução alternativa seria encorajar as pessoas a sempre usarem venvs, o que também resolve outros problemas, por exemplo, conflitos de dependência de deixar tudo em um ambiente global.

Não gosto muito da ideia, mas acho que nunca executei pip fora do virtualenv, que geralmente é ativado no meu shell atual, então a digitação extra não me ganha nada (sou egoísta! ). Claro, se não estiver ativado, provavelmente terei que digitar muito mais do que isso de qualquer maneira ...

Como as pessoas se sentiriam ao abrir uma exceção para virtualenvs? Não há mistério para qual python ele está usando, mas, novamente, pode ser muito confuso fazê-lo funcionar de maneira diferente entre virtualenv e a instalação do sistema, então estou me sentindo bastante humilde sobre sua qualidade como sugestão. Também não tenho certeza se há uma boa solução para verificar isso.

Também,

pip3.4 não é específico o suficiente, você pode ter 3.4.0 e 3.4.1 instalados.

Isso realmente acontece com frequência? Estou curioso para saber como você está distinguindo entre eles, se assim for, já que eu não achava que o python normalmente se instalaria mais específico do que pelo nome pythonX.Y (e a menos que eles tenham prefixos diferentes, parece que ele também tentaria compartilhar pacotes de sites de qualquer maneira).

Ah, acho que isso também se aplica a várias instalações 3.4.0, mas parece que você definitivamente usaria caminhos completos para distinguir se está usando "pip" ou "python -m pip", mas desde que você Ao usar caminhos completos de qualquer maneira, o argumento contra ter palavrões extras desaparece.

Posso estar um pouco desconectado aqui, mas por que não substituir pip por um alias que fosse efetivamente algo como:

alias pip=/usr/bin/env python -m pip

Ou um script semelhante a este para ser instalado em /usr/local/bin/pip .

Dessa forma, não perdemos pip , e funciona universalmente em qualquer lugar.

Também não tenho certeza se isso resolve os problemas que você está enfrentando, apenas meus $ 0,02. :raiva3:

@erikrose
Isso meio que muda o problema para python , mas normalmente a confusão que vi surgir decorre de quando python e pip discordam. Como você pode ter /usr/bin/python e /usr/local/bin/python e se python aponta para /usr/local/bin/python e pip aponta para /usr/bin/python é um receita para a confusão. Assim, eliminamos completamente a confusão causada por ter os dois discordando, mas removendo qualquer capacidade de discordar. Você ainda está confuso sobre o que python significa, mas não acho que haja nada que possa ser feito sobre isso, e particularmente não por nós.

Um ambiente virtual torna o problema _mais difícil_ de acertar, mas acho que ainda é possível. Meu instinto me diz que novos usuários (os mais propensos a serem enganados por isso) provavelmente não usarão ambientes virtuais religiosamente (se eles os estiverem usando).

@rschoon
Nós poderíamos fazer isso, seria necessário um caso especial permanente dentro do pip quando o pip se instalasse (porque não há setup.py em um ambiente virtual), mas certamente é uma possibilidade. Meu principal medo com isso é que parece que seria sempre melhor usar python -m pip qualquer maneira, porque funciona dentro e fora de um ambiente virtual, em vez de ter que se lembrar de alternar comandos com base no fato de você estar em um ou não.

Não sei exatamente com que frequência a coisa 3.4.0 e 3.4.3 aparece. Eu sei que não é super incomum no OSX, já que você forneceu o sistema Python em /usr/bin/python e também pode instalar o instalador do Python.org ou Homebrew ou Macports ou pyenv (ou alguma combinação dos acima).

@mattrobenolt

Basicamente, porque é super confuso se você estiver fazendo algo como executar myvenv/bin/pip sem ativar o ambiente virtual primeiro ou se tiver uma cópia do Python instalada em um local não padrão /opt/my-app e executar /opt/my-app/bin/pip e espere gerenciar /opt/my-app/bin/python .

parece uma perda para ambientes virtuais perder um script básico pip quando eles não sofrem desse problema.

quanto a pythons reais, acho que não me importaria de ver um script de console do tipo pip-<python binary path> mais exato e deixar os empacotadores de distribuição aplicarem scripts mais simples para pips gerenciados pelo sistema.

-1 na depreciação de pip , +1 nos outros.
Quero expandir alguns pensamentos de enquadramento que tenho, que podem ajudar a discutir o que é um problema tão grande. Pule para o intervalo se você quiser apenas ler meus pensamentos sobre soluções.

Para começar, você quer ver _por que_ temos esse problema, e é análogo a qualquer outra pessoa? Ele vem de ter e permitir vários pythons em um sistema em execução. Portanto, os gerenciadores de pacotes do sistema não têm esse problema, porque, por exemplo, você não pode (não pode) executar o debian jessie e o debian wheezy live ao mesmo tempo em um sistema; então não precisa gerenciar um libreoffice3.5 e libreoffice4.3 por exemplo. No entanto, muitos outros gerenciadores de pacotes de idiomas começam a ter que lidar com o mesmo problema que os pip's quando também têm várias versões instaladas. Como @erikrose menciona, até o próprio python já se depara com esse problema ao decidir o que python agora é quando mais de um está instalado.

Eu também quero olhar para o problema do POV da maioria dos usuários de python. Observe que isso se tornou um verdadeiro ponto de dor principalmente (ou mais) para pessoas com mais de 2 pythons instalados. Caso contrário pip funcionaria, ou simplesmente pip2 e pip3 (e provavelmente não haveria inércia suficiente para todos começarem a discutir). Além disso, começa a ficar muito complicado. Mas eu acredito que a maioria dos usuários de python está feliz usando apenas um python. Mesmo que o sistema deles de alguma forma dê a eles 2 em algum momento, ou eles consigam instalar vários, em vez de atualizar / (removendo o anterior e instalando um novo) - se eles acertassem, ficariam bem com apenas um python funcionando, e por extensão, pip desse python. Para todos esses usuários, de repente, tirar pip não faz absolutamente nenhum sentido e é apenas doloroso.

A outra grande fonte de dor é quando alguém simplesmente tenta instalar um novo python sobre um existente anterior, mas a história de todo o ambiente sendo migrado para o novo (ou "assumindo o antigo") não está lá. Nesse caso, quero fazer a distinção de que isso é culpa da história de instalação, não da existência de vários pythons. Por exemplo, alguém esperando "instalar um novo python!" mas não conseguir isso em seu caminho. Mesmo desinstalar o python antigo, pode não fazer nada para fornecer o ambiente que eles desejam (o novo python em seu caminho).

Observe também que, embora o número de usuários que coletam problemas com o gerenciamento de pip s possa ser pequeno, suas reclamações são as únicas ouvidas. Eu arriscaria que suas opiniões são provavelmente a maioria nesta discussão também (porque eles são os únicos com o problema). A maioria silenciosa não se importa até que as coisas mudem para eles, mas ainda devemos procurar representar seu caso de uso de forma justa. Não é claro, que essas queixas, portanto, não possam ser válidas.

Agora, com isso em mente, aqui estão as soluções que eu gosto:

• claramente pip<versionstuff> não escala bem como uma solução. Então, estou de acordo em removê-lo. Na maioria das vezes, é melhor esperar por uma solução decente (se existir) do que tentar continuar com uma que cria tantos problemas quanto resolve.
• Pare de substituir pip (ou outros pip2 s ou pip3 s, mesmo) sem perguntar. Até os gerenciadores de pacotes do sistema fazem isso. Eles perguntam antes. Nós também devemos. Dessa forma, no mínimo, o usuário vê imediatamente que há um problema e talvez possa decidir por si mesmo o que deseja que pip seja. Pode-se fazer muito com isso - veja de quem é a instalação do python do pip existente - é o mesmo que o atual pip tentando se instalar, então isso pode ser bom. Caso contrário, faça o usuário dizer --yes ou --replace ou responda Y a um prompt. Observe que isso pode ajudar com o mesmo problema com outros programas de usuário que vêm de pypi. Certifique-se de que o usuário deseja que o script executável seja substituído. Mesmo que isso signifique que temos que esperar muito tempo para dizer às pessoas que elas podem ter que interagir depois de chamar pip install por padrão (para usos de script de pip), e dar-lhes tempo para adicionar --replace-scripts (ou w/e) aos seus textos explicativos, que assim seja.
• Comece a produzir algumas informações sobre de onde as coisas vêm em uma instalação! Isso pode resolver muitos problemas imediatamente. Se eu instalar um pacote com pip, o pip não fala sobre
  
  
  
  • de que python está
  
  
  • qual é a versão, onde está instalado
  
  
  • onde está instalando o(s) novo(s) pacote(s)
  
  

Isso tudo seria uma informação super útil para saber. Ele me mostrará imediatamente se o pip que estou chamando na linha de comando não é o pip real que eu quero, que é o que engana MUITOS usuários. Ele também me mostrará que estou instalando para o python correto e para o site-packages correto.

Acredito especialmente que implementar os dois últimos pontos acima removeria muitos problemas médios de usuários em relação a esse problema. Em muitos casos, eles teriam o poder de conhecer o problema e a solução por si mesmos.

Uma opção que acabei de pensar, uma vez que realmente removemos os scripts (se é isso que fazemos), podemos apenas criar um pacote pip-cli que os restaura. Isso tornaria trivial para as pessoas recuperarem o comportamento antigo (basta instalar o pip-cli) e facilitaria a manutenção dos scripts dentro de ambientes virtuais (basta instalar o pip-cli também).

Enviado do meu iPhone

Em 6 de outubro de 2015, às 13h16, Marcus Smith [email protected] escreveu:

parece uma perda para os ambientes virtuais perder um script pip básico quando eles não sofrem desse problema.

quanto a pythons reais, acho que não me importaria de ver um pip mais exatodigite console script e deixe os empacotadores de distro aplicarem scripts mais simples para pips gerenciados pelo sistema.

—
Responda a este e-mail diretamente ou visualize-o no GitHub.

Isso tornaria trivial para as pessoas recuperarem o comportamento antigo (basta instalar o pip-cli) e facilitaria a manutenção dos scripts dentro de ambientes virtuais (basta instalar o pip-cli também).

Como ponto de referência, se você não estiver ciente, é assim que grunt funciona no mundo do nó. Não tenho certeza se é o melhor exemplo, mas é uma coisa.

O tl;dr é você $ npm install grunt em seu projeto para uma instalação local, então $ npm install -g grunt-cli para obter um $ grunt global, que acaba usando apenas o pacote de instalação local .

Do meu entendimento, isso soa semelhante ao que você está propondo?

@mattrobenolt , de certa forma, não é útil, porque ainda está falando apenas de uma instalação de / uma versão do nodejs em seu sistema. Se você tiver duas instalações de nós, a qual delas o script global grunt pertence?

O Node também tem a "vantagem" nesse sentido, pois suas instalações de pacotes são locais por padrão, o que é o oposto do python. Mesmo em um virtualenv, você está instalando pacotes "globalmente", mas dentro de um ambiente isolado (em vez de seu sistema).

Se você tiver duas instalações de nó, a qual pertence o script grunt global?

Tecnicamente não deveria importar, já que é apenas um calço no real pip que está instalado em seu virtualenv ou o que você está fazendo.

No nosso caso, ele pode ser instalado no sistema python , seja qual for o python, é um detalhe de implementação. Só precisa desembolsar.

porque isso ainda está falando apenas de uma instalação de / uma versão do nodejs em seu sistema

Você está assumindo que as pessoas não usam nvm ou qualquer outra virtualenv -como ferramentas? Mesma ideia.

Mas, novamente, meu contexto é principalmente limitado a ser um usuário, então tenho certeza de que há muitos contextos que não estou levando em consideração. Não alegando ter a solução, apenas citando exemplos de outras coisas na natureza que fazem coisas semelhantes.

Mesmo que o código grunt-cli seja bastante estável, de fato "não deveria importar muito" quem o colocou lá, o ponto de discórdia é qual grunhido ele chama. Como eu disse em node-land 99% do tempo, isso será um grunhido local de caminho, e tudo é decidido por você. Você já sabe qual versão do nodejs seu projeto em seu caminho atual está usando. No entanto, infelizmente, esse não é o caso do python.

Se eu tiver python 2 e python 3 instalados e chamar pip , mesmo que este pip tenha sido fornecido por um pip-cli (equivalente a install -g crunt-cli ) de um dos dois pythons, qual pip do python o script global pip deve chamar? Aqui não temos mais um sistema path-local para nos guiar.

+1 para a opinião de Ivoz, mas em particular:

Comece a produzir algumas informações sobre de onde as coisas vêm em uma instalação! Isso pode resolver muitos problemas imediatamente.

Isso seria muito útil (tanto para usuários iniciantes quanto para usuários experientes de outras plataformas), independentemente da decisão sobre a sintaxe de invocação.

+1 em depreciar pip.+ sem depreciar pip , mas também não deve ser muito trabalhoso corrigir scripts de automação e, na verdade, acho que a automação se beneficiaria mais de saber exatamente qual versão do python executar pipa de. Ainda não li todos os argumentos mas provavelmente vou ler e depois voltar para dar mais opiniões

Meu primeiro GitHub +1. Eu acho que é justo considerar os documentos que _não_ recomendam python -m pip falhos, já que essa invocação é muito menos propensa a falhas em uma instalação do Python manual como o laptop do desenvolvedor iniciante típico.

Do meu ponto de vista: estou de acordo sobre as motivações para esta mudança. O Django tem muitos problemas análogos com pessoas usando a versão errada do python para executar django-admin ; mudar para a abordagem python -m para pip e django-admin seria uma maneira elegante de resolver esse problema.

Minha única preocupação é o ponto 2: mais 10 caracteres para escrever. De uma perspectiva de UX, estou preocupado em introduzir o clichê que precisa ser digitado para executar _qualquer coisa_. Especialmente ao lidar com novos usuários, ter um formato de encantamento mágico "Apenas confie em mim" não é o ideal.

Uma sugestão (embora exija uma mudança para Python, em vez de PyPA): Faça py (ou alguma outra abreviação) um atalho para python -m . Sim, isso significa ter 2 maneiras de invocar o python, mas você pode defendê-lo como "py executa módulos, python executa código". A outra desvantagem disso seria que só beneficiaria novas versões do python, a menos que fosse retroportado para 2.7/3.[345].

@freakboy3742 sim, quero dizer, isso também significaria que flake8, pep8, etc. também deveriam se mover para essa convenção (o que, dado o fato de pyflakes ser muito dependente da versão do Python, faz um pouco mais de sentido). py também pode ser distribuído como um pacote para pessoas que desejam se inscrever antecipadamente, mas também entra em conflito com o módulo py py.test se bem me lembro.

+1 na defesa de python -m pip como padrão e preferencial, em vez de apenas pip .

Venho ensinando iniciantes (até crianças) e introduzindo novatos em Python há um bom tempo. Além dos pontos de @dstufft , tudo fica complicado quando você chega ao território virtualenv porque o Python que está sendo usado não é o Python padrão no caminho do sistema. _Em particular_, essas complexidades pioram se forem usadas outras distribuições do Python; por exemplo, com o Anaconda Python, você pode criar um env conda sem pip (por exemplo, você esquece de conda install pip ) e, em seguida, o pip no caminho continua a instalar no env raiz e não no seu env conda. No espaço científico, muitas pessoas estão usando o Anaconda Python como seu primeiro Python padrão.

Nesse cenário, usar python -m pip ... informará se o pip não está presente no _active_ python.

Quanto às percepções de desconforto, também espelha exatamente outras invocações muito comuns, por exemplo, python -m pdb , python -m ipdb , python -m cProfile , python -m timeit , python -m pstats , python -m SimpleHTTPServer , python -m json.tool , python -m gzip , python -m filecmp , python -m zipfile , python -m encodings.* , python -m mimetypes , python -m tabnanny , python -m pydoc , python -m unittest , python -m calendar , e provavelmente um monte de outros que eu não conheço.

Tenho certeza de que fazer essa mudança tornaria o pip mais fácil de explicar para iniciantes. Eu tenho que explicar a mudança -m de qualquer maneira para pdb e cProfile então essa mudança seria uma simplificação líquida para meus alunos. (Venv se tornaria muito mais fácil de ensinar também se tudo que você tivesse que fazer fosse chamar o executável correto do python e não mexer com caminhos e "ativação", mas isso é um resmungo para outra hora)

Seria útil pelo menos manter o comando pip para o caso em que ele é intuitivo e (principalmente?) inequívoco: dentro de um virtualenv.

Fazer isso também ajudaria com a inércia da documentação.

Eu gosto bastante de 'Mova pip/ para _pip/ e faça pip.py.' como opção. Parece viável e, embora seja perturbador para o pessoal que está bisbilhotando no pip/ hoje, vale a pena melhorar a experiência do usuário - principalmente porque não oferecemos uma API pública hoje.

Eu sou um +0 em depreciação, pois não é um caso de uso que eu já encontrei. Usar python -m seria muita digitação extra para usuários não familiarizados com aliases.

Como estamos analisando um caminho de depreciação significativamente longo, é necessário criar um hack para o Python 2.6? Assumindo um caminho de depreciação longo o suficiente, não poderíamos supor que o Python 2.6 será de uso tão baixo que um hack não é necessário?

Acho que concordo com @audreyr - em um virtualenv, é inequívoco, sem adornos (sem pip2 / pip3 /etc) e a camada de ferramentas do Python ( activate , et .al.) faz com que você obtenha o binário "certo" sem recorrer a dizer aos usuários para configurar seus shells.

Mas eu tenho uma proposta ainda mais radical: e se você nem rodasse pip como instalador? Cada vez mais, o que eu quero é virtualenv --requirement project/requirements.txt project ; se eu quiser "instalar" uma coisa nova, é hora de um novo virtualenv. É claro que eu quebro essa regra o tempo todo, atualizando venvs existentes, removendo dependências e tal, mas isso é principalmente um mau hábito do qual acho que devo me livrar, especialmente agora que as rodas tornam a criação de novo virtualenv bastante rápida.

pip como linha de comando é muito bom ter. Ninguém conhece virtualenv ainda, e existem alguns utilitários que você deseja usar fora de um virtualenv. E se eu quiser instalar o Mercurial ou Stackless Python mais recente com pip , posso fazer isso agora mesmo.

Eu nunca consigo acertar os encantamentos npm/bower na primeira tentativa. Mesmo se você remover o executável, alguém ainda olhará para alguns documentos antigos espalhados pela rede e usará o sistema operacional python-pip e/ou python3-pip, e ele falhará. Então esse alguém ainda vai tentar sudo pip install -U someoldpackageyoudontwanttoupgrade e oops, lá vai o sistema operacional gritando com você. Sim, eu fiz isso. Apenas substituir isso por sudo python -m pip não evitará essa situação.

Não seria mais fácil se concentrar em tornar o comportamento do pip sobre os pacotes (e ele mesmo) --user instalável por padrão e, em seguida, se livrar/substituir pip2/pip3/whatever por links para o pip mais recente, para que seja encontrado primeiro no caminho do usuário (eu já tenho o meu em ~/.local/bin/ ), trabalhando a partir de sua própria roda, e com segurança escondido de qualquer coisa que o sistema operacional "acha ser melhor". Enviei uma solução alternativa para permitir que o pip funcione com virtualenv quando estiver definido para instalações do usuário por padrão (https://github.com/pypa/virtualenv/issues/802) que também funciona com pyenv.

Isso é para pessoas que realmente não se importam com qual versão do python estão trabalhando e querem algo que "simplesmente funcione". Então algum administrador ainda vai querer usar "sudo pip install para todos" e simplesmente funciona. O usuário apenas tenta "instalar pip para mim" e simplesmente funciona.

Prefiro não ter que me preocupar com "/ whereismypython/python -m pip install -g --userDev --Ireallymeanit --pleaselistentome blah". E voltar para "python setup.py install blah" me parece um passo atrás.

-1 de mim ao descartar pip e seus links simbólicos específicos da versão, pois o bastão de depreciação precisa ser _muito_ levemente empunhado.

Já temos um problema contínuo significativo com a fadiga de mudanças no ecossistema Python, pois existem três grandes transições de tecnologia de baixo nível (Python 2 -> Python 3, easy_install/eggs -> pip/wheels, unsafe por padrão -> seguro por padrão) ainda em andamento, e um _muito_ trabalho restante para propagar isso através dos canais redistribuidores (os consumidores diretos de upstream que realmente vêm falar conosco online são a ponta do iceberg quando se trata da base de usuários do Python). Adicionar uma transição "pip" -> "python -m pip" em cima disso não vale a pena agora (como uma estimativa aproximada, eu diria que minha opinião sobre isso pode mudar até 2017).

No entanto, acho que vale a pena emitir uma mensagem sempre que o pip for executado globalmente informando:

1. Para qual versão do Python está instalando
2. Sugere "-m pip" para direcionar uma instalação específica

Por exemplo:

"RuntimeWarning: nenhum venv detectado, instalando em '/usr/lib/python2.7/site-packages'. Passe '--user' para instalação específica do usuário ou execute '<other_python> -m pip' para direcionar um tempo de execução".

Também vejo uma oportunidade de vincular a transição python -> py na migração Python 2->3, mas esse é um tópico para python-ideas e não aqui.

@cjrh +1 por defender python -m pip especialmente na documentação de uma instalação preferida do PyPA para novas implantações (especialmente ciência e ciência de dados, bem como educação). conda e brew complicam as coisas como Caleb menciona.

Concordo com @audreyr em um virtualenv.

A transição pode inicialmente ser documentação. @ncoghlan Acho que já existe uma quantidade significativa de solução de problemas de pip/conda/brew sendo feita por mantenedores de projetos de terceiros em ciência/ciência de dados para orientar os usuários finais pelas muitas permutações. Concordo que emitir avisos melhores também seria útil.

python -m pip install ...
pip install em um ambiente virtual

Eu também gosto muito do virtualenv --requirement project/requirements.txt project sugerido pelo @glyph

Na verdade, todas as três abordagens não enfatizam os números de versão na execução. Isso pode realmente ser um benefício inesperado para mover alguns projetos para o Python 3.

-1 ao remover o pip, eu teria que alterar todos os meus scripts de implantação.
+1 na remoção de pipX e pipX.Y

Minhas razões são que eu tenho basicamente 2 casos de uso para usar pip (que já foram mencionados por @audreyr e outros aqui, mas vou repetir):

1. Estou dentro de um virtualenv e sei qual python quero executar (e estarei executando): o python do virtualenv que escolhi no momento da criação desse dito virtualenv
2. Eu quero instalar um pacote que não é fornecido pela minha distribuição e usará o pip para fazer isso, nesse caso eu realmente não me importo com qual python estou usando, estou usando o python padrão em todo o sistema.

Sei que esses são apenas meus casos de uso pessoais, mas acredito que sejam bastante comuns entre as pessoas que usam pip.
Eu só usei pip3 algumas vezes para instalar alguns pacotes somente python3 em todo o sistema, que é um caso de uso que deve lentamente (provavelmente mais rápido que o aviso de depreciação proposto) desaparecer, pois as distribuições estão se movendo lentamente para python3 por padrão.

E para fechar este comentário, não sou a favor de usar uma sintaxe diferente dentro e fora do virtualenv's, isso será confuso para muitas pessoas (cf. @Samureus comentário sobre como o npm é confuso)

Que tal fornecer pip por meio de um novo comando que adia apenas python -m pip

Se o caso do problema for quando o pip e a versão atual do python forem diferentes, que tal depreciar o uso do script apenas nesse caso? Ou seja, ele começa a emitir avisos de descontinuação se você estiver fazendo isso agora e depois o proíbe completamente.

Sugestão para verificação específica.

1. Se o pip estiver sendo executado por meio de um caminho direto, ignore esta verificação completamente. por exemplo, venv/bin/pip não acionará esta verificação.
2. Para cada nome de pip, defina um "nome python equivalente". Se o nome do pip começa com 'pip' este é pipname.replace("pip", "python", 1). ou seja, apenas transferimos o sufixo para python, então pip2 -> python2, pip3.4 -> python3.4, etc. Se o nome do pip não começar com 'pip', o padrão será apenas 'python'.
3. Se o python correspondente não for igual a sys.executable depois de pesquisar e canonizar caminhos, acione o aviso. Isso deve dizer algo como "Aviso: pip está instalando em um python diferente do que está no caminho. Você provavelmente deseja executar {pythonname} -m pip.{__main__ se for 2.6}" apenas melhor pensado do que isso. :-)

+1 pelos comentários de @ncoghlan e @DRMacIver

Como o problema aqui parece ser "às vezes as pessoas ficam confusas", podemos começar com algumas mensagens/avisos de log úteis em vez de tentar alterar basicamente o README de cada projeto Python como o primeiro passo?

Existe uma "prática recomendada" para usar o pip em algum lugar? Tipo, "no Debian, instale apenas python-virtualenv e python-dev e sempre use virtualenv para obter o pip" (ou qualquer que seja a prática recomendada).

Além disso, se o problema principal for "quando 'python' é diferente do que 'pip' aponta, coisas ruins acontecem", não é possível detectar e emitir algum tipo de aviso assustador? Ou até mesmo se recusar a trabalhar sem --do-the-bad-things ou algo assim?

Além de pressionamentos de tecla adicionais para digitar python -m pip install ... , há algum motivo técnico para não recomendar que os usuários finais (cientistas e cientistas de dados) usem essa abordagem?

@willingc afaik este comando funciona em todos os lugares .... exceto no Ubuntu

@nanuxbe Obrigado. Qual é a restrição do Ubuntu?

@willingc Não funciona no Python 2.6. Espero que não seja um problema, mas pode ser para algumas pessoas.

@willingc não tem certeza de qual é a restrição, mas eles também fazem isso com virtualenv.
$ python -m pip install --upgrade pip
/usr/bin/python: cannot import name defaultdict; 'pip' is a package and cannot be directly executed

+1 ao que @ncoghlan disse acima.

Parece que tudo no ecossistema python está em transição. Não vamos adicionar outra coisa lá, se possível.

@willingc No Ubuntu 14.04 (o LTS atual), o pip foi transformado em um pacote Ubuntu separado que deve ser instalado com o gerenciador de pacotes do sistema operacional. AFAICR é o mesmo para python2 e python3. Para python3, venv também foi retirado pelo sistema operacional e transformado em um pacote do sistema operacional. Como @nanuxbe aponta, os comandos esperados não funcionam, por exemplo, também python3 -m venv . E então, se você atualizar o pip (eu _acho_ apenas no py2), você receberá a mensagem InsecurePlatformWarning . Todos esses são problemas conhecidos e complexos que devem tornar muito difícil e frustrante trabalhar no projeto pip, e agradeço a eles por todo o trabalho duro. Todo mundo reclama quando o menor imprevisto acontece, enquanto ninguém aplaude quando as coisas "simplesmente funcionam". Não posso fingir que sei quais são todos os problemas, e os que conheço também não entendo completamente. Estes são Problemas Difíceis e tenho admiração e gratidão por aqueles que escolhem lidar com eles.

wrt python -m pip versus pip : Estou mudando meu voto para "deixar as coisas como estão".

Verifiquei para ter certeza e parece que agora conda adicionará automaticamente pip a qualquer novo env, 2.6 até 3.5 (espero que faça isso em todas as plataformas). Portanto, o caso que mencionei anteriormente sobre esquecer de instalar pip em um conda env não pode mais ocorrer (então você não pode ter a situação de executar um pip no conda env errado).

O único problema do Windows restante é que atualmente você não pode atualizar pip com pip , mas esse é um problema menor porque conda upgrade pip funciona bem. Se quiséssemos ser super generosos com usuários não-conda no Windows, poderíamos detectar por pip install -U pip e apenas dar uma mensagem que diz. "Por causa de como o Windows funciona, o próprio pip é bloqueado durante a execução para que você não possa atualizar o pip assim. Faça assim: python -m pip install -U pip ", e isso será perfeitamente adequado.

Não acho que toda a dor de mais uma mudança altamente visível valha o que provavelmente terá benefícios marginais a longo prazo.

wrt pipX.Y : Eu nunca usei, nem confiei no uso deles devido a todos os problemas dados no post principal. Não tenho opinião aqui, pois isso não me afeta. Eu gostaria de dizer "livre-se deles", mas não tenho ideia de quem é afetado.

Pessoalmente, estou achando o argumento da fadiga da mudança um tanto convincente, e isso parece algo que deve ser adiado por um tempo. Dito isto, não é _realmente_ possível desacelerar a mudança geral, tudo o que podemos fazer é tapar a barragem até que ela se rompa, se houver problemas reais. Então, acho que a causa raiz aqui é que precisamos de uma maneira melhor de _gerenciar_ a mudança na comunidade mais ampla, para que possamos continuar melhorando no ritmo, sem fazer com que todos se sintam exaustos com as coisas para acompanhar.

Pessoalmente, estou achando o argumento da fadiga da mudança um tanto convincente

Eu concordo. Eu não percebi que outras pessoas estavam cansadas com isso (acho que desde que presto atenção não me cansa).

isso parece algo que deve ser adiado por um tempo

Bem, o período de tempo para a depreciação, conforme escrito na edição original, foi "da ordem de anos". Eu acho que começar a mover as pessoas para python -m pip suavemente nesse meio tempo não vai doer. pip , pipX.Y , etc não irão desaparecer imediatamente.

No contexto de "isso vai mudar em vários anos", eu me pergunto se isso ainda afetará a fadiga da mudança.

Alguém, talvez eu, deveria propor como PEP que "python install" seja um alias para "python -m pip"?

Começando com o PEP 453 no Python 3.4, se bem entendi, a instalação do python inclui a instalação do pip. Portanto, parece uma etapa viável para o próprio executável python invocar o pip se iniciado como "python install ...".

Se isso faz alguém se sentir melhor, também não é como se tudo fosse perenemente perene na terra do conda, conda no meu mac está atualmente em mangueira porque um dos scripts de infraestrutura usados ​​na construção de um env parece ter perdido um bit executável em uma atualização recente ;)

Obrigado a todos por seus insights. Depois de ler a excelente explicação do @cjrh para o ubuntu, estou tranquilo em me recuperar do cansaço. FWIW, instalações mais antigas do conda podem atrapalhar links e caminhos para pacotes, como encontramos no DjangoCon DjangoGirls. Nós essencialmente precisávamos desinstalar completamente o anaconda e o python e reinstalar o python e pip instalar os pacotes DjangoGirls.

Eu estou querendo saber se existe uma matriz por versão do Python que explica qual comando para cada versão e os para pip e virtualenv. Uma folha de dicas ou um pequeno script. Peço desculpas se já estiver nos documentos.

@ajdavis

Começando com o PEP 453 no Python 3.4, se bem entendi, a instalação do python inclui a instalação do pip.

A menos que você esteja usando uma distribuição linux comum python :D

btw python -m pip é 1 caractere a menos para digitar que python install . Não tenho certeza de nenhuma vantagem disso, além de ser semanticamente confuso - python install uninstall ... , python install -U pip ?

@willingc sim, infelizmente, MUITOS instaladores de python ao longo dos anos jogaram muito sujo com o processo de instalação, não se importaram em limpar depois de si mesmos, apenas se preocuparam consigo mesmos, deixaram-se por todo o caminho, etc., o que torna extremamente frustrante para alguns mais novos Comercial. Eu diria que isso é principalmente culpa dos próprios instaladores.

Tão longe quanto

Eu estou querendo saber se existe uma matriz por versão do Python que explica qual comando para cada versão e os para pip e virtualenv. Uma folha de dicas ou um pequeno script. Peço desculpas se já estiver nos documentos.

Eu não estou ciente de quaisquer diferenças importantes? Além disso, o Windows sempre precisa atualizar o pip com python -m como apontado anteriormente. Isso é principalmente um amontoado de janelas, no entanto.

Também vale a pena notar que acredito que muitas outras complexidades atuais realmente se relacionam à transição Python 2->3, em vez de serem inerentes à maneira como o próprio pip funciona. Especificamente, uma pilha do sistema Python 3 no Linux e outros sistemas *nix requer comandos diferentes (python3, pip3) de qualquer outro ambiente Python (seja uma instalação do Windows, um ambiente virtual ou um ambiente conda).

Como essa é apenas uma das muitas complexidades que afetam a experiência do usuário do Python no Linux (as políticas de empacotamento de distribuição historicamente foram projetadas em torno de "supor que cada máquina está executando serviços de produção de missão crítica, mesmo que seja realmente o laptop de um indivíduo"), vários de nós envolvidos no A migração do Python 3 iniciou recentemente um SIG Linux para coordenar melhor os esforços entre distros.

Uma ideia que estou sugerindo agora é a introdução de um atalho "py" configurável pelo usuário para corresponder ao comportamento do Python Launcher para Windows: https://mail.python.org/pipermail/linux-sig/2015- Outubro/000000.html

@lvoz Pois é, muita poluição do passado. FWIW, o problema de instalação do Django Girls levou a mim, @honzakral e @jambonrose uns bons 30-45 minutos para solucionar e resolver. Estava longe de ser óbvio para 3 desenvolvedores experientes o que estava acontecendo.

Obrigado a todos vocês por ajudarem a levar as coisas adiante. Você está fazendo um excelente trabalho.

Consulte https://mail.python.org/pipermail/distutils-sig/2015-November/027536.html para uma discussão.

-1 para soltar pip +1 para derrubar outros

Como o pip 10.0 descarta o suporte para o Py2.6, quero apenas abordar esse problema uma vez.

Eu diria que minha opinião sobre isso pode mudar até 2017 ou mais

Ping @coghlan? :)

Move pip/ para _pip/

Isso foi feito, embora como pip._internal . #4700

Podemos oferecer uma receita nos documentos para restaurar pip, pipX e pipX.Y por meio de aliases de shell.

O aviso provavelmente deve estar vinculado a uma seção na documentação que contém esse trecho e uma boa explicação detalhada sobre por que isso foi feito.

Outra alternativa seria parar de exigir que o pip seja executado no mesmo ambiente Python em que está instalando as coisas ...

Também gosto dessa ideia do @dholth . Isso provavelmente também deve ter algo como # 4145 no lugar para ser um pouco seguro.

Várias distribuições Linux não enviam mais um pip não qualificado por padrão, pois não enviam python2 por padrão. Então minha preferência neste momento:

Dentro de um ambiente virtual ativado, acho que pelo menos um pip não qualificado deve continuar funcionando e afetar o ambiente virtual ativo. É inequívoco nessa situação, portanto, quebrá-lo não evita qualquer dor do usuário existente. Sou mais ambivalente em pipX e pipX.Y (com X.Y correspondendo à versão do Python no venv), já que confiar nisso faz a atualização para uma versão diferente do Python mais difícil do que precisa ser e é completamente redundante dentro de um ambiente virtual.

Fora de um ambiente virtual ativado, acho que faria sentido começar a desencorajá-los mais ativamente e recomendar o python -m pip . Isso enfatiza a posição do pip como sendo essencialmente um gerenciador de plug-ins para tempos de execução do Python e se alinha com o que temos nos documentos da biblioteca padrão há algum tempo (https://docs.python.org/3/installing/#basic-usage) .

Edit: notei minha ambivalência sobre os nomes qualificados da versão Python quando dentro de um ambiente virtual ativo.

Acho que recomendar comandos diferentes para dentro de um ambiente virtual e fora de um ambiente virtual é confuso (e uma dor, como fazemos isso em pypi.org?). O que quer que façamos aqui, deve haver um único conjunto de comandos como o mecanismo oficialmente recomendado.

Estou bem com as recomendações sendo consistentemente a favor do uso de python -m pip , a única coisa com a qual não estou bem é realmente quebrar pip install dentro de um virtualenv ativado - não é ambíguo e funciona multiplataforma (exceto talvez ao atualizar o próprio pip no Windows).

Quer dizer, não temos um mecanismo para ter comandos que só existem dentro de um ambiente virtual. Se funcionar lá, funcionará em todos os lugares.

Certo, eu estava pensando em termos de um ponto de entrada de script que sempre estava instalado, mas também sempre falhava se você tentasse executá-lo fora de um ambiente virtual (ou seja, seria uma verificação de tempo de execução, em vez de um cenário "sem arquivo aqui")

-1 ao soltar pip. A maioria dos usuários que eu vi normalmente tem uma única instalação (conda tem Python 3.6), e isso não faz sentido dessa perspectiva. O único problema é o problema do Python 2 e isso começará a desaparecer em breve.

Portanto, estamos agora em uma situação em que não oferecemos suporte ao Python 2.6. Portanto python -m pip funciona em todos os lugares e eu seria a favor de usá-lo como a maneira canônica de executar o pip nos documentos (e sim, há python2/python3 no Unix e py no Windows, mas provavelmente podemos contar com os usuários para resolver essa parte).

Para o caso de ambientes virtuais, provavelmente poderíamos apenas instalar o executável pip ao instalar em um virtualenv (sem --user ou --target ) e não de outra forma, deixando isso para o sistema pacotes (ou garantapip) para instalar um executável pip conforme necessário nessa situação. As pessoas que desejam continuar usando pip podem, por conveniência - não abandonaríamos essa opção, basta parar de mencioná-la nos documentos.

Uma opção poderia ser mover o wrapper de script para seu próprio pacote pip-cli ou algo parecido, e apenas incluí-lo na lista de pacotes que os ambientes virtuais instalam por padrão.

Como lidaríamos com casos como pip 10, onde diferentes versões de pip-cli são necessárias para suportar pip 9 e pip 10 (porque pip.main mudou)? Se o usuário atualizar o pip, não temos meios de forçar a atualização do pip-cli. Assim, acabaríamos com as mesmas falhas que vemos atualmente com os wrappers do sistema operacional.

A opção de ter pip-cli chamar pip em um subprocesso não é razoável, IMO. Eu sei que é o que recomendamos para ferramentas externas, mas não acho que adicionar a sobrecarga de um processo adicional no que certamente continuará sendo a maneira mais comum de invocar o pip por muito tempo seja realmente aceitável. Você está efetivamente dobrando o custo de inicialização do Python, que já é alto. Prefiro ver algumas medições concretas em vez de intuições, mas na ausência de medições, estou preocupado com o custo de um subprocesso extra.

Se quisermos seguir a rota pip-cli e não pudermos justificar a abordagem do subprocesso, precisamos dar ao pip-cli uma dispensa para usar os componentes internos do pip ou precisamos expor formalmente pip.main como uma API suportada (com as ressalvas que julgarmos apropriadas).

Ter pip-cli usando pip.__main__.main deve ser bom.

Ou apenas use runpy: https://docs.python.org/2/library/runpy.html , é o que -m usa de qualquer maneira.

+1 ao usar runpy.

+1 ao usar runpy.

Idem. :)

ATÉ cerca de runpy .

Você quer dizer https://docs.python.org/3/library/runpy.html , certo? :sorriso pretensioso:

@Juanlu001 ainda damos suporte ao Python 2.7. :)

Há um pouco mais de discussão em # 5508 (antes de @dstufft apontar que era uma duplicata deste problema!)

Pessoalmente, acho que uma grande fonte de confusão observada aqui é a incompatibilidade pip vs python -m pip .

ISTM isso é algo que pode ser verificado usando sys.executable e PATH . Além disso, o pip não deve avisar/falhar quando invocado por meio de um caminho (como bin/pip ) que pode ser verificado usando sys.argv[0] . O caso extremo que vejo aqui é: em um sistema operacional em que sys.argv[0] é algo diferente do que é usado para invocar o script. AFAICT, não é um problema no Windows ou MacOS 10.13 (High Sierra).

Isso deve ser uma boa coisa a fazer, independentemente de decidirmos remover os wrappers pip* . Estou faltando alguma coisa aqui?

Acho que o que você está perdendo aqui é que, principalmente, os executáveis pip em questão são aqueles enviados pela distro, que o pip não pode atualizar (por uma razão ou outra - permissões, instaladas em um local diferente de onde um pip install normal vai, problemas de PATH em torno de instalações de usuário versus sistema, etc).

Pessoalmente, suspeito que este não seja um problema que nós (pip) possamos resolver, simplesmente porque o script wrapper que está atrapalhando as coisas não é de nossa propriedade. É por isso que minha inclinação é parar de enviar os wrappers e evitar aumentar a confusão - deixe claramente um caso de "para executar pip, use python -m pip , se você usar um comando pip , fale para quem o entregou, não somos nós". Minha segunda preferência é apenas enviar um wrapper pip não versionado e direcionar as pessoas que atingem o problema para seu fornecedor de distribuição (podemos escrever um script "detectar a configuração" que poderíamos pedir às pessoas para executar quando encontrarem um problema assim - mas, por definição, não podemos enviá-lo com pip porque está diagnosticando problemas em que o pip não será executado corretamente ...) Minha terceira preferência é a mesma, mas continuamos enviando wrappers versionados apenas no Linux (acredito que eles promovem a má prática de ter várias versões do Python no PATH, mas não vejo como vamos conseguir que os usuários do Linux parem de fazer isso).

Mas para responder ao seu ponto "independentemente de decidirmos...", sim, escrever um script que tenta diagnosticar o ambiente do usuário e relatar erros de configuração e problemas seria realmente útil. É só que enviá-lo com pip seria de uso limitado, porque muitas vezes as pessoas não seriam capazes de executá-lo precisamente nos casos em que precisam. No entanto, poderíamos vincular a um script autônomo dos documentos.

Consulte https://github.com/pypa/python-packaging-user-guide/issues/396 para obter uma discussão sobre como transformar algumas etapas de solução de problemas recomendadas em uma receita executável.

Esse script wrapper é de nossa propriedade. Eles estão apenas usando o que estamos gerando, levará muito tempo para uma mudança se infiltrar.

O que eu queria dizer é que eles não o instalam onde esperamos (AFAIK, é por isso que sudo pip install -U pip quebra com o wrapper ainda procurando por pip.main ). Também há uma lógica extra que podemos precisar colocar no wrapper para lidar com sistemas de desembaraço que têm pip instalado em todo o sistema, bem como no site do usuário, e isso é sem dúvida um bug em nossos scripts atuais - embora, até onde eu saiba, o A situação é confusa o suficiente para que eu nunca tenha visto um bom exemplo de como entrar nesse estado de forma reproduzível ...

@ncoghlan Obrigado por essa referência cruzada a esse problema. :)

@pfmoore Isso faz sentido e me faz sentir que separar os wrappers de _pip_ o pacote seria útil; seja uma remoção completa ou movê-lo para um pacote _pip-cli_.

Tentei chegar a algo que satisfaça (quase) todas as preocupações levantadas nesta edição com o status quo. Eu acho que uma boa posição para acabar seria:

• _pip_ não fornece nenhum wrapper CLI; suporta apenas python -m pip
• _pip-cli_ imita python -m pip em processo como um wrapper pip
• Incluir _pip-cli_ nos pacotes instalados por padrão de _virtualenv_

Razões para escolhas aqui:

• Facilidade de uso dentro de um virtualenv; ainda é pip .
• A UX de atualização do Windows melhora
  
  
  
  • pip install --upgrade pip funcionará no Windows :tada:
  
  
  • ainda precisaria fazer python -m pip install --upgrade pip-cli embora
  
  
  • um pouco menos problemático, pois as atualizações para isso podem ser muito menos frequentes
  
  
• A documentação existente diz "pip install ..." que ainda funcionará em venvs.
• Não fornecendo pipX e pipX.Y
  
  
  
  • eles são redundantes em virtualenv + problemas listados no OP; eles não escalam bem
  
  
  • meio que evita entrar em conflito com os executáveis ​​da distribuição até certo ponto (quando a distribuição não fornece variantes não qualificadas)
  
  

Entradas e comentários são bem-vindos sobre o acima.

Outras notas:

• Não vejo argumentos convincentes para pipX e pipX.Y . Eles provavelmente devem ser preteridos / removidos.
• Relacionado: #4625 (Substituindo wrappers existentes)
  
  
  
  • relevante aqui: isso faria a instalação do _pip-cli_ se comportar melhor com os pips instalados na distribuição
  
  
• Ter a "verificação de sanidade" verificando a equivalência de python -m pip e pip , enviado como parte de _pip-cli_ parece tentador para mim.

@pradyunsg No geral, isso parece um bom plano para mim.

+1 para o plano de @pradyunsg de mim.

O único caso de pipX que estou ciente de que o uso é pip3 install --user ... em sistemas Linux, mas mudar isso para python3 -m pip install --user ... não é um fardo muito grande.

Se as distros decidissem que queriam adicionar o script wrapper de volta aos seus pacotes python2-pip e python3-pip por motivos de compatibilidade com versões anteriores, também acho que estaríamos bem com isso.

Acho que a estratégia seria bem direta para pipX , pipX.Y :

1. Liberação n
   
   
   
   • Descontinuar pipX , pipX.Y ; mostra um aviso sobre a remoção quando eles são usados.
   
   
2. Liberação n+1 (ou n+2)?
   
   
   
   • Remova pipX , pipX.Y de _pip_.
   
   

É tão simples que acho que podemos deixar n aqui ser 18,0; agendada para o próximo mês. A única coisa aqui seria: por quanto tempo executamos a descontinuação? Estou em cima do muro sobre isso.

Por pip , fica mais interessante. Tenho certeza de que não queremos que essa mudança seja excessivamente disruptiva para os fluxos de trabalho do usuário _e_ queremos fornecer uma maneira suave de transição para _pip-cli_. Uma coisa que acho que devemos fazer aqui é adicionar um caso especial para que a atualização do pip do _pip_ não sobrescreva o pip do _pip-cli_ durante a transição, mas vice-versa funciona.

Idealmente, teríamos algum tipo de período "beta" para usar _pip-cli_ onde poderíamos pedir aos usuários que testassem usando _pip-cli_. Isso ajudaria a resolver os problemas antes de descontinuarmos pip em _pip_.

1. Liberação n
   
   
   
   • Descontinuar pip de _pip_.
   
   
   • Adicione _pip-cli_ a _virtualenv_; garantindo que ele seja instalado após _pip_.
   
   
   • Sugira aos usuários que mudem para _pip-cli_.
   
   
2. Liberação n+2
   
   
   
   • Remova pip de _pip_.
   
   

Acho que os 2 ciclos de lançamento devem ser tempo suficiente para coletar feedback do usuário sobre essa mudança e reagir adequadamente. Eu acho que o lançamento antes daquele em que removemos pip deveria dizer "o pip wrapper será descartado no próximo lançamento" em vez de "em um lançamento futuro", como eles costumam fazer.

Agora, não tenho certeza se e onde devemos incluir alguma variante das informações de verificação de sanidade/depuração?

• no pip de _pip_? Na versão n + 1?
• no pip de _pip-cli_; no período que antecede o Release n?

@pypa/pip-committers Vamos descontinuar pipX e pipX.Y no pip 18.1?

Nosso plano é apenas dizer às pessoas para usar python -m pip então?

sim. Isso é o que teríamos.

É um pouco mais complicado do que isso, já que "python" pode não se referir ao
coisa certa.

Isso significa que qualquer aviso de descontinuação precisará de algumas heurísticas baseadas em
sys.executable, shutil.which e a plataforma em execução para decidir qual
substituição adequada seria.