Doom-emacs: Problemas com a configuração da versão pyenv automaticamente (desenvolver ramificação)

Se você executar o Emacs no MacOS, e se você iniciar o Emacs do Dock, você pode ter exatamente o mesmo problema que eu tive. O MacOS fez algo estranho com as variáveis ​​de ambiente quando você iniciou a partir do Dock ou LaunchPad, de modo que $ PATH não está sincronizado com seu shell real.

Minha solução alternativa atual é criar um script em / usr / local / bin, cujo conteúdo é:

#!/usr/bin/env zsh
(/usr/local/Cellar/emacs-mac/emacs-26.1-z-mac-7.1/Emacs.app/Contents/MacOS/Emacs "$@") &

Você precisa atualizar este script de acordo com sua própria configuração, como o shell que você está usando e onde o emacs está instalado. Mas essa maneira geralmente resolve o problema de $ PATH.

Eu estava executando o Emacs do Alfred, tão efetivamente o mesmo que inicializar do Dock ou LaunchPad. No entanto, usar o script que você forneceu inicia o Emacs sem problemas, mas não resolve o problema de pyenv que eu tive, infelizmente. Acabei de obter os mesmos resultados que obtive acima. No emacs, (getenv PATH) me dá o mesmo caminho que tenho no shell (incluindo o caminho de shims pyenv). É um pouco desconcertante!

@bsag Você poderia me dizer se a variável +python-current-version contém a versão correta?

Não, ele retorna:
"2.7.14"

Nesse diretório, há um arquivo .python_version que especifica o "photo2hugo" e executando python --version nesse diretório no terminal retorna "Python 3.6.5".

pyenv global também é 3.6.5

Eu tenho 2.7.14 como uma das versões do python disponíveis para o pyenv, mas ele não está ativado em nenhum dos meus ambientes até onde eu sei.

Obrigado por investigar!

Oi eu também encontrei o mesmo problema.

E + python-current-version retorna nil enquanto + python-pyenv-versions retorna 3.6.5.

Observa que funciona bem no emacs --nw, mas dá errado iniciar a GUI no OSX 10.13

Eu empurrei uma solução potencial para isso. Contanto que o diretório shims de pyenv esteja em PATH (e exec-path , por extensão), +python-current-version deve conter a versão atual. Por favor, atualize e me informe se for o caso

Olá, hlissner, obrigado pela atualização.

Após a atualização, ainda não funciona como esperado, e eu tenho

1. + python-current-versions retorna

Seu valor é "2.7.15" (enquanto + python-pyenv-versions retorna 3.6.5)
Local no buffer bigpydir.py (meus arquivos); valor global é nulo

Torna-se automaticamente local de buffer quando definido

2.> echo $ PATH
/Users/yanbo/.pyenv/shims:/Users/yanbo/.jenv/shims:/Users/yanbo/.jenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/ usr / bin: / sbin: / bin: / usr / games: / usr / local / games: /Users/yanbo/.composer/vendor/bin: /Users/yanbo/.rvm/bin

Olá, @hlissner , infelizmente tive a mesma experiência que @Yanbo. Ainda não funciona, e ainda mais estranho, agora não parece ter + python-current-version disponível para o Mx. Tentei comentar a linha python em meu init.el para desinstalá-lo e reinstalá-lo, para ter certeza de que algo não estragou, mas ainda não tenho + python-current-version.

Para constar , também experimentei instalar o :!pyenv version .

Hmm, curioso. Agora está funcionando ... mais ou menos.

Como parte da tentativa de depurar alguns problemas que tive ao executar um R REPL por meio de ESS quando iniciei o Emacs como um emacsclient, adicionei estas linhas ao meu .config.el:

(require 'exec-path-from-shell)
(exec-path-from-shell-initialize)

Isso significava que o ESS poderia encontrar meu binário R e, quando por acaso iniciei um espaço de trabalho baseado em python, descobri que o modeline agora estava relatando a versão pyenv correta e o REPL do Python foi iniciado corretamente. No entanto, o preenchimento automático não está funcionando e recebo a seguinte mensagem de erro com frequência:

A conclusão nativa do Shell está desativada, usando fallback
Erro do servidor: TypeError ("__ init __ () obteve um argumento de palavra-chave inesperado 'ambiente'",)

Algo a ver com o servidor de linguagem, talvez, mas eu tenho o python-language-server (v 0.17.1) instalado nesse ambiente virtual. Enfim, progresso, eu acho!

@bsag Você tem usado o Emacs através do daemon todo esse tempo? Isso explicaria muito, porque o Doom usa exec-path-from-shell , mas apenas em sessões de GUI (não daemon ou sessões de terminal, porque essas devem ter sido iniciadas a partir de um ambiente de shell lógico, que, em retrospectiva, não é verdadeiro para o daemon no MacOS, a menos que tenha sido iniciado manualmente por meio de emacs --daemon , em vez de por meio de launchctl ou brew services ).

_Sem_ aquelas linhas exec-path-from-shell em sua configuração, e se você iniciar o daemon via emacs --daemon , a versão correta do pyenv foi detectada?

Acabei de tentar o que você sugere e ele não relata o pyenv correto ao executar a partir do emacs --daemon.

De qualquer forma, executá-lo NÃO através da GUI é uma coisa que venho tentando recentemente (deveria ter explicado). Quando eu relatei originalmente, eu estava executando direto da GUI (ou seja, iniciando o Emacs.app que o homebrew instala). Isso mostrou a versão incorreta do pyenv.

Então eu estava mexendo neste fim de semana e decidi tentar usar o serviço launchctl fornecido pela brew. Como você apontou, ele não define o caminho corretamente, então descobri que tive que usar essas linhas para fazer com que ele reconhecesse o caminho, o que parecia (parcialmente, pelo menos, embora algo sobre o ambiente esteja quebrado de algumas maneiras Não entendo).

Estou tendo o mesmo problema. +1

Avancei no módulo lang / python; o suporte pyenv, pyvenv e pipenv está disponível e o suporte conda foi melhorado. Como as informações de versão / env são mostradas na linha de modo foram reescritas. E o Doom mudou sua filosofia para interagir com seus ambientes pyenv / pyvenv / conda.

Da maneira antiga: o Doom tentaria adivinhar o env correto sempre que você iniciar o modo python.

A nova maneira: a troca de env / versão agora é feita manualmente e globalmente, via M-x e os comandos fornecidos pelos plug-ins pyenv-mode, pyvenv e conda Emacs:

• pyenv: pyenv-mode-set e pyenv-mode-unset
• pyvenv: pyvenv-activate e pyvenv-deactivate
• conda: conda-env-activate e conda-env-deactivate
• pipenv: pipenv-activate e pipenv-deactivate (EDITAR)

Por que a mudança: tentar "adivinhar" o env correto está sujeito a erros. Os plug-ins manipulam forçosamente o ambiente de processo Emacs, que contamina os resultados de qualquer processo externo criado a partir do Emacs. É muito imprevisível e o Emacs não tem nenhuma noção de "envvars locais de buffer".

Isso pode ser frustrante para as pessoas que procuram arquivos Python em diferentes projetos com diferentes requisitos / envs, mas seu comportamento é muito mais previsível dessa forma.

EDIT: A única exceção a tudo isso é pipenv. A versão python na modeline leva em consideração o env pipenv atual (e não precisa definir ou ler nenhum envvars para fazer isso). Assim, o pipenv obtém suporte de primeira classe.

Isso deve resolver efetivamente o problema, mas pode exigir mais testes.

Ah, e esqueci de mencionar, o lang / python agora também tem os seguintes sinalizadores de módulo para habilitar esses (ou outros) recursos:

• +pyenv
• +pyvenv
• +conda
• +ipython

Excelente, isso funciona! No entanto, quando eu pyenv-mode-set outra versão pyenv (por exemplo, 3.6.5), ele ativa esse ambiente corretamente, mas ainda deixa a modeline mostrando Python 2.7.14, bem como a versão pyenv correta. Uma vez que funciona corretamente, isso é bom - um pouco confuso.

Obrigado por corrigir isso!

Olá, acabei de instalar o doom-emacs (da neovim) recentemente, desculpe minha falta de conhecimento sobre o Emacs em geral.

Estou tentando fazer com que meu projeto (em Python) detecte meu ambiente pipenv corretamente.

Percebi que você mencionou acima:

• pyenv: pyenv-mode-set e pyenv-mode-unset
• pyvenv: pyvenv-activate e pyvenv-deactivate
• conda: conda-env-activate e conda-env-deactivate

Mas que tal pipenv ? Quando executei :pipenv-activate , recebo apenas a seguinte saída:

Finished pipenv --venv

Quando tento examinar a definição do código (por meio do CD do SPC), ainda diz Nada "Nenhuma definição encontrada".

Eu perdi alguma coisa?

Obrigado.

A única coisa que eu poderia fazer para encontrar definições de código para funcionar é se eu executar:

: pythonic-activate RET / path / to / virtualenv / RET

No entanto, é bastante irritante para os usuários do pipenv, pois o caminho para o virtualenv no pipenv geralmente está em um diretório diferente do próprio projeto.

@rezmuh Você quis dizer M-x pipenv-activate ? Porque :pipenv não é um comando ex real (pode funcionar, mas não da maneira que você imagina).

@hlissner , tentei de várias maneiras.

Primeiro fiz apenas com :pipenv-activate depois com M-x pipenv-activate e também SPC : pipenv-activate

Mas a saída foi a mesma, que é Finished pipenv --venv conforme mostrado abaixo:

Então, as definições de código ainda não estavam disponíveis

@hlissner python-mode não parece funcionar a menos que eu instale o python3 em todo o sistema, estou usando o pyenv e ele não detecta nem ativa o modo python a menos que eu instale o python3. Tenho python3 em pyenv e é a versão global definida para minha conta de usuário. Não tenho certeza se isso é um bug ou apenas um acaso da minha configuração incorreta.

Antes de instalar: python3

Depois de instalar: python3 brew install python3

@georgreen Você poderia verificar suas * Mensagens * em busca de mensagens de erro ou aviso (você pode abri-las com SPC h e ) ao abrir o modo python sem o python3 instalado?

@hlissner

Por algum motivo, essa combinação de teclas não funciona, mas eu vi uma mensagem reclamando que pipenv não foi encontrado no meu caminho. Porém, está disponível em meu shim python3.

spc h m trabalhe embora

pipenv e python

Quando tento alternar manualmente usando m-x python-mode : pipenv not found on your path aparece.

Em alguns projetos, o modo python simplesmente falha ao carregar.

Suspeito que você precise adicionar ~ / .pyenv / shims ao seu PATH dentro do arquivo ~ / .profile.

export PATH=~/.pyenv/shims:$PATH

@rphillips meu caminho já tem isso.

@hlissner Iniciar o emacs via terminal com o env virtual habilitado parece resolver isso.

A partir disso, acho conclusivo que é uma questão de caminho.

@hlissner Corrigido: sweat_smile :, por favor, descarte todas as minhas preocupações. Eu descobri que o problema era como ZSH estava carregando minhas variáveis ​​env. Tudo que tive que fazer foi carregá-los corretamente via .profil ou .zshenv para este caso, tudo funcionou perfeitamente como deveria. Eu acho que isso se aplica ao resto do tópico se o seu caminho está sendo definido, use .bash_profile , .profile ou .zshenv para que o emacs possa escolher o caminho correto (eu tive meu env em zshrc que parece ser a causa de todo aquele comportamento inesperado), se você não está preparado para isso, inicie seu emacs a partir do terminal, ou seja, emacs .

@georgreen Sem problemas! Você está certo. .zshrc só é lido em sessões zsh interativas, enquanto .zshenv é lido em todas as sessões, interativas ou não. Ao iniciar a GUI Emacs no MacOS, o Doom abre um shell não interativo para copiar seu ambiente de shell (para ser copiado para o Emacs). Esse é o comportamento correto, embora seja uma fonte comum de confusão.

No entanto, quando eu pyenv-mode-set outra versão pyenv (por exemplo, 3.6.5), ele ativa esse ambiente corretamente, mas ainda deixa a modeline mostrando Python 2.7.14, bem como a versão pyenv correta.

@bsag Por acaso, é um projeto pipenv? Sua versão no modeline deve respeitar os pythons instalados no pyenv, mas consultará o pipenv primeiro se o buffer atual for um projeto pipenv.

Além disso, em qual sistema operacional você está? Se você estiver no Linux, como iniciar o Emacs?

@hlissner Não, não tenho o pipenv instalado. No entanto, parece que posso ter o mesmo problema que @georgreen , pois não estou definindo as variáveis ​​env no lugar certo. Eu vou consertar isso. Na verdade, isso é uma coisa muito útil para aprender, então, obrigado!

Então aqui está um pequeno enigma. Felizmente, é uma solução fácil.

Fiz uma nova instalação do os X Mojave apenas porque instalei o python3 via pyenv e pyenv via homebrew. Eu segui as instruções muito úteis neste tópico para fazer o python 3 ser reconhecido pelo DOOM. Coloquei as linhas relevantes no arquivo .zshenv para que o DOOM o pegasse e eu tivesse o caminho correto com os shims pyenv na frente.

Aqui está meu arquivo .zshenv

Tudo estava funcionando bem por um tempo, até que comecei um novo projeto. Claro, não posso dizer que iniciar o novo projeto criou esse problema, mas também não consigo pensar em mais nada que mudou. Agora, quando abro um arquivo python, obtenho o sistema padrão python versão 2.7.10 visto aqui:

Como você pode ver, só tenho o Python3 mais recente instalado via pyenv

Se alguém tiver alguma sugestão eu ficaria muito grato!

problema semelhante à pessoa acima. pipenv, uma vez ativado, inicia a versão correta do interpretador. No entanto, apenas executando SPC-: run-python me dá 2.7.15 por algum motivo.
basicamente o pyenv global não é respeitado.

feliz em fornecer mais informações sobre minha configuração, se necessário.

@finnkauski Resolvi meu problema seguindo as instruções aqui .

Eu simplesmente coloquei a seguinte linha no arquivo ~ / .doom.d / config.el

(setq python-shell-interpreter "python3" flycheck-python-pycompile-executable "python3")

Espero que ajude!

Oi,

Estou usando o doom-emacs (da Spacemacs hybrid) no Buster. Minha sessão tem PATH adequado e mais usando variáveis ​​de ambiente do systemd. Eu uso pyenv e poesia. Eu costumava fazer a ponte com o Emacs colocando VIRTUAL_ENV no arquivo .venv e a versão pyenv no arquivo .python-version . Na verdade, isso aponta para o mesmo, uma vez que a venv está em versões pyenv. No doom-emacs, parece que nenhum dos dois é lido, o doom-emacs continua usando o sistema python3 (3.7.3) enquanto o padrão do sistema é 2.7.16.

Meu .doom.d / init.el:

       (python
        +pyenv)          ; beautiful is better than ugly

Alguma pista para que Doom atribua a versão python de acordo com a versão pyenv?

Saudações,

Executar :!pyenv version retorna o valor correto.