Bug#926326: elpa-elpy: configuration issues
Hi Nicholas,
On Sun, 14 Apr 2019, Nicholas D Steeves wrote:
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
Thank you for the kind words. I've noted the bug split. I'm not sure
exactly what you want me to do regarding replying to the bugs, so I've
CCed the original bug, as well as the three new sub-bugs that you created.
I could have split up my reply across the three different bugs, but that
would be quite a lot of work, and might be confusing. I suggest followups
for the relevant points from here on should just go to the relevant bugs.
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
It would be more accurate to write
README.Debian misleads users into assuming nonexistent Python 2 support
Since it does not say anything to the contrary.
The only really important thing is to make it clear to users that Buster's
elpy does not support usage with Python 2, as mentioned later.
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.
Fine, just document it in the README.Debian. And (preferably) tell users
what to add to enable it. If they don't want to use it, they don't have
to. But at least then they won't have to go looking for a method that will
work.
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)
Yes, it does indeed have exactly that on top.
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
It didn't occur to me that either of those exists. Thank you for the
pointers. I think that's also something that could usefully be mentioned
in README.Debian. Most Python packages don't have either of those, I
think. So it will probably not occur to people to look for them.
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?
It seems to me that those two would be enough to start with. While I've
been using Elpy, that's basically all I've been using.
But perhaps other people have opinions? I was just thinking of adding a
short section to README.Debian right now, perhaps entitled "Quickstart",
but perhaps it's something that could be suggested to upstream too. I
spent a fair amount of time staring at the manual in bewilderment.
Granted, I might not be the brightest bulb, but I'm probably not the only
one to have that experience.
And yes, a way to have a Python buffer automatically come up in elpy mode
would be useful, but not a big deal.
I think you could also tell people to check M-x elpy-mode to make sure
they have all the suggested packages installed. Though in Debian the
versions will typically not be up to date.
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?
No, I've not tried using an add-hook. I'm not exactly Emacs Lisp literate.
And yes, that could be an item for a hyothetical Quickstart, I suppose.
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.
Yes, I figured that out after writing the bug report.
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.
Yes, I guess that this is not a priority. And, as you say, it's not
possible for Buster, anyway. Though Python 2 is still the default Python
in Buster. I suggest adding a note in the README.Debian telling people
that the `elpa-elpy` in Buster is a Python 3 package/module, and that is
will not work with Python 2 files/scripts. This is a not unimportant
detail, because lacking this information, it's quite natural to try using
Python 2 files/scripts with Buster's elpy. After all, Python 2 hasn't gone
anywhere, and is still the default Python in Buster.
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.
Some additions to the README.Debian would indeed be helpful. Provided that
people actually go and read the README.Debian. Consider if there is a way
to tell new users who have installed elpy to go and read README.Debian.
Perhaps a message on the shell, immediately after installation? I know
that is possible, because I've seen it before.
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.
Yes, I think you are right.
Regards, Faheem Mitha
Regards,
Nicholas
Reply to: