wyuenho / emacs-pet

Tracks down the correct Python tooling executables from your virtualenvs so you can glue the binaries to Emacs and delete code in init.el
GNU General Public License v3.0
91 stars 11 forks source link

Pipenv virtualenv detection does not work properly #6

Closed janoc closed 1 year ago

janoc commented 1 year ago

Description Pipenv virtualenv detection does not work right, even though the Pipfileand pipenv itself are found just fine.

Reproduction steps

  1. Use the arbitrary-config-file-path branch for pet
  2. Create a project where the Pipfile isn't placed in the project root but in a subdirectory and a Python source file is in a subfolder below the Pipfile.
    root
    |-- project1
         |-- Pipfile
         |-- src
               |-- main.py
  3. Open the python file
  4. Enable pet-mode
  5. (pet-virtualenv-root) points to the wrong place, (pet-use-pipenv-p) returns path to pipenv, (pet-pipfile) returns content of the Pipfile

Expected behavior Correct virtualenv is choosen.

PET version arbitrary-config-file-path branch, 21c2933

Emacs version

29.1, self-built

Desktop (please complete the following information):

System tools versions

Additional context It seems the problem stems from this bit of code in pet-virtualenv-root:

        ((when-let ((program (pet-use-pipenv-p)))
           (condition-case err
               (with-temp-buffer
                 (let ((exit-code (call-process program nil t nil "--venv"))
                       (output (string-trim (buffer-string))))
                   (if (zerop exit-code)
                       (prog1 output
                         (setf (alist-get root pet-project-virtualenv-cache nil nil 'equal) output))
                     (user-error (buffer-string)))))
             (error (pet-report-error err)))))

This will try to execute pipenv --venv from whichever directory Emacs is in when visiting the python file but that does not work! One has to start pipenv from the directory where the Pipfile is located, otherwise it just fails, or, worse, in some cases generates a new Pipfile in the current folder (not for the --venv command, though).

This is different from poetry - poetry will return the correct virtual env even when started from a folder below the pyproject.toml where the visited source file is. Pipenv will not.

Generally speaking, I think it would be safest to execute these tools from the folder where their corresponding config file is, even if it is not required e.g. for poetry (no idea about pdm or pipx, I don't use them).

BTW, this is broken also on the main branch, if one uses a project that has source files in a subfolder and not right next to the Pipfile.

wyuenho commented 1 year ago

It should work properly now, I'll tag a new release after your confirmation.

janoc commented 1 year ago

Great, I will give it a test in the morning on my work machine and report back.

janoc commented 1 year ago

I have just tested it with both pipenv and poetry and both work fine! Thanks for the quick fix, really appreciated!