pythonic-emacs / pythonic Goto Github PK

I'm getting an error from pythonic which prevents me from opening new files in emacs:

  pythonic-python-readable-file-name: Wrong type argument: stringp, nil

This happens after I've installed flx-ido, and am using M-x f to attempt to open a file. With flx-ido, there's an "extra" key sequence you can use (Ctrl-f) to exit IDO and use basic file opening which does work with pythonic.

I believe the problem is that pythonic-python-readable-file-name is assuming that the filename argument passed to it is non-nil. This is not always going to be the case:

https://stackoverflow.com/a/5414033

I don't really understand elisp, but I have replaced pythonic-python-readable file name with

(defun pythonic-python-readable-file-name (filename)
  "Emacs to Python FILENAME conversion.
Take FILENAME from the perspective of the localhost and translate
it to the FILENAME Python process can read.  Python can be
running locally or remotely.  FILENAME can have local or tramp
format.  Result will have local format."
(if filename
  (let ((alias (pythonic-aliased-path (expand-file-name filename))))
   (if (tramp-tramp-file-p alias)
        (tramp-file-name-localname (tramp-dissect-file-name alias))
     alias))
  filename
  ))

And the problem goes away. In keeping with the "be liberal in what you accept" dictum, can you modify pythonic-python-readable-file-name to return filename if it is nil?

Is there a way to just open a docker connection, looking at the code this does not happen because it uses tramp-file variable to determine if its a docker container which on first opening a project I do not have.

Looking for a more pragmatic / automated solution the project has a compose file so should just start using docker, if this is not possible I may add an activate-docker type method, but what are you thoughts would auto connect be okay or would you prefer an activate docker type function ?

Detecting vagrant environments is too specific considering it's just a plain old ssh connection which is easily detected by (pythonic-remote-method), which returns "ssh".
We might add ssh-detection, and then replace vagrant detection with it. It might help, for example, with anaconda-mode port forwarding feature in case of generic ssh connection, and not just vagrant. I'll provide a PR, so it'll be clearer what do I mean.

You would know the root of this issue from here. Using benchmark-init I was able to notice the require call to tramp-loaddefs taking as much as 30s as you would see in this photo.

I really like pythonic and the way it works well with continers and virtual env's.

I was curious if it could be easily expended to run other commands like pytest but automatically using the configured setup, ie make it a bit more generic would this be quite simple ?

I may give this a try if its not possible and I can find some time, or is this outside the scope of the project ?

If I have a package with a src/foo/bar/site.py, and I use pythonic-start-process to start my interpreter while editing that file, it crashes because it shadows the built-in site module, even if there is properly a __init__.py file in that folder marking it as a package. There should be some heuristics to select an appropriate cwd, or at least an easy option to do so.

(This is derived from the behavior of the 'isortify' package, but perhaps they're using it improperly?)

Hi all,

I'm trying to use pyenv-mode in emacs 25.2.2 on Linux Mint 19.1, but is fails with the messsage: Cannot open load file: No such file or directory, f.
Trying to dig around I find that pythonic-activate gives the same error.

Could you provide any suggestion as to how to fix pythonic-activate?
(elisp noob here, so detailed instructions are most useful and highly appreciated :) )

Hi - I received this bug report, which appears due to this code in Pythonic.

I'd suggest either the logic be adjusted or - better - you use the python-shell-interpreter variable, so that Emacs users can continue to set their Python executable path unambiguously in one place.

Hi!
matplotlib.pyplot does not work in virtualenv with pythonic-activate

Steps to reproduce:

1. Create an empty environment with virtualenv -p python2 test
2. Activate with . test/bin/activate
3. Install the MWE requisites with pip install ipython matplotlib pyside
4. In your emacs session, pythonic-activate test
5. run-python
6. enter the magic command %matplotlib qt
7. Next run import matplotlib.pyplot as plt and plt.figure()
   A figure should appear. It doesn't.

How it works in emacs without pythonic-activate:

1. Without activating the virtualenv, run-python
2. Run in the inferior mode the magic command %matplotlib qt
3. Next run import matplotlib.pyplot as plt and plt.figure()
   A figure window should appear

How it works in a virtualenv outside emacs:

1. Create an empty environment with virtualenv -p python2 test
2. Activate with . test/bin/activate
3. Install the MWE requisites pip install ipython matplotlib pyside
4. enter an ipython session
5. enter the magic command %matplotlib qt
6. Next run import matplotlib.pyplot as plt and plt.figure()
   A figure should appear.

There exist at least 69 packages that contain a file named test-helper.el that also provides the feature test-helper.

This leads to issues for users who have at least two of these packages installed. It is unlikely that such a user would be able to run the tests of all of those packages. If the primary test file of one of those packages does (require 'test-helper), then it is undefined which of the various test-helper.el files gets loaded. Which it is, depends on the order of the load-path.

To avoid this conflicts, you should rename your test-helper.el to <your-package>-test-helper.el and adjust the feature accordingly.

Also don't forget to update the require form in your primary test file and/or update references to the library/feature elsewhere. Also, if your primary test file is named something like test.el, then please consider renaming that too (same for any other utility elisp files your repositoroy may contain).

Thanks!

PS: This issue is a bit generic because I had to open 69 issues.