Dear Faheem,
Thank you for filing an excellent bug report that includes all
relevant information. Reply follows in-line, but please take care to
reply to the appropriate sub-bugs that will be momentarily created:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=elpa-elpy
elpa-elpy: README.Debian misleads users into enabling nonexistent Python 2 support
* Concerning points: #1, #5, #6, #7
elpa-elpy: Please provide a QuickStart page
* Concerning point #4
elpa-elpy: Please enable Python 2 support
* Concerning points: #1, #5, #6, #7
Bug#926326: elpa-elpy: configuration issues is now
* Concerning points: #2, #3
I've split the aggregate into discrete bugs, because some of these
issues will not receive an unblock for buster.
On Wed, Apr 03, 2019 at 08:39:35PM +0530, Faheem Mitha wrote:
> Package: elpa-elpy
> Version: 1.28.0-1
> Severity: normal
>
> Dear Maintainer,
>
> I've been struggling with getting elpy to work on Debian stable.
>
Thank you for letting me know, and sorry it wasn't easy. Let's fix
this! :-)
> For right now, some comments and suggestions about README.Debian.
>
> 1) There's a typo in your code:
>
> (setq python-shell-interpreter "python"
> python-shell-interpreter-args "-i")
> elpy-rpc-python-command "python")
>
> It should be:
>
> (setq python-shell-interpreter "python"
> python-shell-interpreter-args "-i"
> elpy-rpc-python-command "python")
>
Good catch, thanks!
> 2) You should mention that elpy isn't loaded by default, and indicate
> how to load it. Historically, Debian packages autoload modes once
> installed, and personally I find that more convenient. But I
> understand if you don't load it to preserce compatibility with
> upstream EPLA.
>
Yes, for simple packages this is absolutely the way to go. I chose to
leave (elpa-enable) up to the user because on my system it doubles
Emacs startup time, because elpa-enable is unconditionally executed.
Also, a user may choose to enable Elpy using an alternative
(conditional) method.
> The elpy manual mentions in
> https://elpy.readthedocs.io/en/latest/introduction.html that elpy
> should be enabled with
>
> (package-initialize)
> (elpy-enable)
>
> Just the second line works for me here. I'm not sure what the first
> part does. Some sort of global enable, apparently.
>
For info about package-initialize, see the Emacs manual §48.2 "Package
Installation". Also, your init file may have already had the following
automatically added to the top of it:
;; Added by Package.el. This must come before configurations of
;; installed packages. Don't delete this line. If you don't want it,
;; just comment it out by adding a semicolon to the start of the line.
;; You may delete these explanatory comments.
(package-initialize)
> 3) I suggest mentioning the upstream manual in README.Debian. Namely,
> https://elpy.readthedocs.io/en/latest/
>
Unfortunately this will not provide accurate documentation for users
of Debian buster in the coming months, because that URL will document
a newer version of Elpy, and buster is shipping with 1.28.0. Also, a
link is useless for users who are offline.
Would you please comment on your experience with "info elpy" or "man
elpy"? P.S. The sphinx-generated info page is much nicer than the
the man page it generates, and the following is nicer still:
emacs --eval '(info "elpy")'
# or M-x info, C-s elpy
> 4) And if I were writing the README.Debian, I'd also mention that C-c
> C-c runs the buffer, and that you need C-c C-z to open up a Python
> interpreter buffer. This would help people to get going quickly,
> instead of flailing around trying to figure out what to do.
>
> These commands are both in
> https://elpy.readthedocs.io/en/latest/ide.html
>
> C-c C-y r (elpy-shell-send-region-or-buffer)
> [...]
> Also bound to C-c C-c.
>
> and
>
> C-c C-z (elpy-shell-switch-to-shell)
>
> There are a ton of commands in that manual, and it's really
> confusing. But you really only need a couple to get going. That manual
> really needs a quickstart page.
>
I agree! With more info about the proposed enhancements I'll open an
upstream pull request and investigate filing an unblock for Elpy so
that users of buster can benefit. So far, for the QuickStart we have
1) document shortcuts for elpy-shell-send-region-or-buffer and
elpy-shell-switch-to-shell 2) possibly a solution to the question
below 3) Anything else?
> Do you happen to know if it is possible to configure emacs to open a
> Python buffer in elpy mode by default and skip the C-c C-z?
>
It is :-) Have you tried using an add-hook in your init file? Is
this also an item for the QuickStart section of upstream docs?
> 5) I'm also running into the error message mentioned in
> https://github.com/jorgenschaefer/elpy/issues/1521
>
> Should I report it here? Or just upstream? I added a comment to that
> thread.
>
> 6) Your bug report template should include the output of
> elpy-config. I've included mine at the bottom. I'm not sure what is going on with
>
> Elpy..............: Not found (Python), 1.28.0 (Emacs Lisp)
>
> though. What's the difference between those two cases?
>
#5 and #6 are due to Debian's Elpy package's missing/disabled Python 2
modules, in combination with the custom configuration mentioned in
README.Debian. #6 shows that the Elpy's Python 2 modules are not
found, but that the elisp libraries are present and working.
> 7) I suggest adding Python 2 packages to the package
> dependencies/recommends/suggests too. Like for Jedi. People are still
> using Python 2, and are likely to be doing so for awhile.
>
Unfortunately it's too late in the buster release cycle to make such a
big change as this. The issue is not just depending on the Python 2
deps, but also 1) Building the python2 variant of Elpy's python bits.
2) Hacking the Emacs self-tests to selectively run for each python
version. 3) Running #2 in autopkgtests, to test the package
as-installed rather than from the source package. 4) All tests must
pass, all the time, or Elpy gets dropped from buster. 5)
Additionally, not all deps (eg: black) have Python 2 packages
available on Debian, so the package would probably need to be split
into elpa-elpy, python-elpy, and python3-elpy. #2 might also be
easier with this split.
FYI:
https://pythonclock.org
https://lwn.net/Articles/756628/
Everything I've heard says that Python 2 will be dropped for bullseye,
so all that would work would need to be reverted when Python 2 is
dropped from bullseye. This is why, in early September 2018, I
decided not to support Python 2 in Debian's package. Of course, if
Python 2 miraculously finds a maintainer, and it stays in Debian, then
I'll start work on this.
Thanks again for raising these issues! This makes it clean that it's
time to simplify README.Debian to say that Debian's Elpy package
exclusively supports Python 3, and to note that the source package or
git repository should be consulted to see how upstream defaults have
been altered.
> The Python interpreter could not find the elpy module. Make sure the
> module is installed.
>
> [run] easy_install --user elpy
>
> The yapf package is not available. Commands using this will not work.
>
> [run] easy_install --user yapf
>
> The black package is not available. Commands using this will not work.
>
> [run] easy_install --user black
>
This looks like a symptom of missing Python 2 modules. At this time,
for Python 2 support, it's easier to purge elpa-elpy and just use the
MELPA package.
Regards,
Nicholas
Attachment:
signature.asc
Description: PGP signature