Bug#926326: elpa-elpy: configuration issues
clone 926326 -1 retitle -1 elpa-elpy: please provide docs in html format thanks On Thu, Apr 25, 2019 at 01:04:18AM +0530, Faheem Mitha wrote: > > 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. > In general (and especially during a freeze) it's better to do one-issue-per-bug. Please do not CC each bug... The bts stores the info for each cloned bug's common origin, which can be consulted either using "bts show --mbox bug-number" or the link to a particular bug's URL. If using 'bts show --mbox' take care that replies go to the cloned bug's email rather than to the common origin's email. signature.asc Description: PGP signature
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 o
Bug#926326: elpa-elpy: configuration issues
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 sk
Bug#926326: elpa-elpy: configuration issues
clone 926326 -1 -2 -3 retitle -1 elpa-elpy: README.Debian misleads users into enabling nonexistent Python 2 support severity -1 important retitle -2 elpa-elpy: Please provide a QuickStart page retitle -3 elpa-elpy: Please enable Python 2 support severity -3 wishlist signature.asc Description: PGP signature
Bug#926326: elpa-elpy: configuration issues
Package: elpa-elpy Version: 1.28.0-1 Severity: normal Dear Maintainer, I've been struggling with getting elpy to work on Debian stable. 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") 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. 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. 3) I suggest mentioning the upstream manual in README.Debian. Namely, https://elpy.readthedocs.io/en/latest/ 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. 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? 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? 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. Regards, Faheem Mitha -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages elpa-elpy depends on: ii elpa-company0.9.9-2 ii elpa-find-file-in-project 5.7.3-1 ii elpa-highlight-indentation 0.7.0-1 ii elpa-pyvenv 1.20-1 ii elpa-s 1.12.0-2 ii elpa-yasnippet 0.11.0-2 ii emacsen-common 2.0.8 ii flake8 3.2.1-1 ii python3 3.5.3-1 ii python3-flake8 3.2.1-1 Versions of packages elpa-elpy recommends: ii emacs 46.1 ii python3-jedi 0.10.0~git1+f05c071-1 Versions of packages elpa-elpy suggests: pn black ii python3-autopep8 1.4.3-1 ii python3-jupyter-console 5.0.0-1 ii python3-pip 9.0.1-2 pn yapf3 -- debconf-show failed Output of M-x elpy-config Elpy Configuration Virtualenv: None RPC Python: 2.7.13 (/usr/bin/python) Interactive Python: python (/usr/bin/python) Emacs.: 25.1.1 Elpy..: Not found (Python), 1.28.0 (Emacs Lisp) Jedi..: 0.12.0 Rope..: 0.10.3 Autopep8..: 0.9.1 Yapf..: Not found Black.: Not found Syntax checker: flake8 (/usr/bin/flake8) You have not activated a virtual env. While Elpy supports this, it is often a good idea to work inside a virtual env. You can use M-x pyvenv-activate or M-x pyvenv-workon to activate a virtual env. The directory ~/.local/bin/ is not in your PATH. As there is no active virtualenv, installing Python packages locally will place executables in that directory, so Emacs won't find them. If you are missing some commands, do add this directory to your PATH -- and then do `elpy-rpc-restart'. The Python interpreter could not find the elpy module. Make sure the module is installed. [run] easy_install --user elpy
