file-error "Cannot open load file" "python-environment" #140

Closed
shackra opened this Issue Mar 11, 2014 · 13 comments

Comments

Projects
None yet
6 participants
@shackra

shackra commented Mar 11, 2014

I updated yesterday my emacs pakages. Today I open emacs and it yelled this error:

Debugger entered--Lisp error: (file-error "Cannot open load file" "python-environment") require(python-environment) eval-buffer(#<buffer *load*-53761> nil "/home/jorge/.emacs.d/elpa/jedi-20140310.1248/jedi.el" nil t) ; Reading at buffer position 1077 load-with-code-conversion("/home/jorge/.emacs.d/elpa/jedi-20140310.1248/jedi.el" "/home/jorge/.emacs.d/elpa/jedi-20140310.1248/jedi.el" nil t) require(jedi) eval-buffer(#<buffer *load*-7995> nil "/home/jorge/.emacs.d/requrs.el" nil t) ; Reading at buffer position 360 load-with-code-conversion("/home/jorge/.emacs.d/requrs.el" "/home/jorge/.emacs.d/requrs.el" nil nil) load("/home/jorge/.emacs.d/requrs.el" nil nil t) load-file("~/.emacs.d/requrs.el") eval-buffer(#<buffer *load*> nil "/home/jorge/.emacs.d/init.el" nil t) ; Reading at buffer position 547 load-with-code-conversion("/home/jorge/.emacs.d/init.el" "/home/jorge/.emacs.d/init.el" t t) load("/home/jorge/.emacs.d/init" t t) #[0 "�\205\262 [···] command-line() normal-top-level()

And sadly, I don't understand what jedi:install-server means. in ~/.emacs.d/.python-environments/ I tried to create a directory and a empty file called default and in both cases the same error is yelled by emacs.

@syohex

This comment has been minimized.

Show comment
Hide comment
@syohex

syohex Mar 11, 2014

Collaborator

@shackra This issue is already fixed(#138, #139).
Could you upgrade emacs-jedi and try again ?

Collaborator

syohex commented Mar 11, 2014

@shackra This issue is already fixed(#138, #139).
Could you upgrade emacs-jedi and try again ?

@tkf

This comment has been minimized.

Show comment
Hide comment
@tkf

tkf Mar 11, 2014

Owner

Please explain why you don't understand jedi:install-server and why you think creating the directory solves the problem. It is VERY important to have a clear document so that we don't need to deal with questions.

Let me add more explanations.

Running jedi:install-server installs Python modules required by Jedi.el. You just need to type M-x jedi:install-server RET to install or update the Python modules. To make this command to work, you need an Emacs package called python-environment.el and Python command line program called virtualenv. We have jedi:install-server to solve dependencies outside of Emacs packaging system. This cannot be integrated with, for example with package-install command since Emacs packaging system does not allow us to install Python packages at the install time. The command jedi:install-server makes Python virtual environment in ~/.emacs.d/.python-environments/default/ and install all Python modules required by Jedi.el in it. This way, you don't need sudo or su to install anything and it is easy to install compatible Python packages.

What was most informative in above? Which part do you think that we should add to the document?

Owner

tkf commented Mar 11, 2014

Please explain why you don't understand jedi:install-server and why you think creating the directory solves the problem. It is VERY important to have a clear document so that we don't need to deal with questions.

Let me add more explanations.

Running jedi:install-server installs Python modules required by Jedi.el. You just need to type M-x jedi:install-server RET to install or update the Python modules. To make this command to work, you need an Emacs package called python-environment.el and Python command line program called virtualenv. We have jedi:install-server to solve dependencies outside of Emacs packaging system. This cannot be integrated with, for example with package-install command since Emacs packaging system does not allow us to install Python packages at the install time. The command jedi:install-server makes Python virtual environment in ~/.emacs.d/.python-environments/default/ and install all Python modules required by Jedi.el in it. This way, you don't need sudo or su to install anything and it is easy to install compatible Python packages.

What was most informative in above? Which part do you think that we should add to the document?

@shackra

This comment has been minimized.

Show comment
Hide comment
@shackra

shackra Mar 12, 2014

Hey @tkf!

I love your commitment to make better documentation. It wasn't clear if jedi:install-server should be run after emacs-jedi was installed. And, since the error I reported was buggy me, I though the directory or file (you cannot tell because the missing slash) ~/.emacs.d/.python-environments/default/ was necessary to run emacs without it yelling this error.

I updated and things are good! I may request a feature since I have python2 and python3 installed on my system.

Thanks!

shackra commented Mar 12, 2014

Hey @tkf!

I love your commitment to make better documentation. It wasn't clear if jedi:install-server should be run after emacs-jedi was installed. And, since the error I reported was buggy me, I though the directory or file (you cannot tell because the missing slash) ~/.emacs.d/.python-environments/default/ was necessary to run emacs without it yelling this error.

I updated and things are good! I may request a feature since I have python2 and python3 installed on my system.

Thanks!

@tkf tkf closed this Mar 12, 2014

@spearsem

This comment has been minimized.

Show comment
Hide comment
@spearsem

spearsem Mar 17, 2014

Would it be possible to add support for installing from the conda package manager as well, instead of solely from virtualenv? I'm happy to help if I can get some direction on what I'd need to do to contribute.

< http://conda.pydata.org/docs/index.html >

Would it be possible to add support for installing from the conda package manager as well, instead of solely from virtualenv? I'm happy to help if I can get some direction on what I'd need to do to contribute.

< http://conda.pydata.org/docs/index.html >

@tkf

This comment has been minimized.

Show comment
Hide comment
@tkf

tkf Mar 17, 2014

Owner

Jedi.el uses python-environment.el which just runs virtualenv command to create a virtual environment under ~/.emacs.d/.python-environments/default. If conda can make a virtual environment at arbitrary place and directory organization is same as the one made by virtualenv, then you just have to set:

(setq python-environment-virtualenv '("THAT" "CONDA" "COMMAND"))

Then python-environment.el makes conda's virtual environment at ~/.emacs.d/.python-environments/default.

Owner

tkf commented Mar 17, 2014

Jedi.el uses python-environment.el which just runs virtualenv command to create a virtual environment under ~/.emacs.d/.python-environments/default. If conda can make a virtual environment at arbitrary place and directory organization is same as the one made by virtualenv, then you just have to set:

(setq python-environment-virtualenv '("THAT" "CONDA" "COMMAND"))

Then python-environment.el makes conda's virtual environment at ~/.emacs.d/.python-environments/default.

@tkf

This comment has been minimized.

Show comment
Hide comment
@tkf

tkf Mar 17, 2014

Owner

I mean, "that conda command" has to be equivalent to the virtualenv command, which takes a directory as positional argument and create virtual environment there.

Owner

tkf commented Mar 17, 2014

I mean, "that conda command" has to be equivalent to the virtualenv command, which takes a directory as positional argument and create virtual environment there.

@asmeurer

This comment has been minimized.

Show comment
Hide comment
@asmeurer

asmeurer Mar 17, 2014

Contributor

That conda command is conda create -p jedi epc (those packages are not in the Continuum repos, but there are recipes at https://github.com/conda/conda-recipes and builds on my binstar for OS X).

The question I am not clear about is, what, if anything, does Jedi do with virtualenv to find the true site-packages in order to find more completions for installed modules? Conda environments are completely isolated from one another, unlike virtualenv, so it wouldn't work, but maybe there is a way to "point" it to some other Python installation to get further package completions from (typically the root Anaconda installation). Alternately, you would have to install every conda package into the emacs-jedi env (like conda install -p /path/to/emacs-jedi/env anaconda). This is not too bad because conda is space efficient with its environments (it uses hard links), but there will always be some additional package that doesn't come with Anaconda that you will forget to install there. If you or @davidhalter could clarify what exactly happens here, that would help.

Contributor

asmeurer commented Mar 17, 2014

That conda command is conda create -p jedi epc (those packages are not in the Continuum repos, but there are recipes at https://github.com/conda/conda-recipes and builds on my binstar for OS X).

The question I am not clear about is, what, if anything, does Jedi do with virtualenv to find the true site-packages in order to find more completions for installed modules? Conda environments are completely isolated from one another, unlike virtualenv, so it wouldn't work, but maybe there is a way to "point" it to some other Python installation to get further package completions from (typically the root Anaconda installation). Alternately, you would have to install every conda package into the emacs-jedi env (like conda install -p /path/to/emacs-jedi/env anaconda). This is not too bad because conda is space efficient with its environments (it uses hard links), but there will always be some additional package that doesn't come with Anaconda that you will forget to install there. If you or @davidhalter could clarify what exactly happens here, that would help.

@tkf

This comment has been minimized.

Show comment
Hide comment
@tkf

tkf Mar 17, 2014

Owner

That conda command is conda create -p jedi epc

Please don't increase ways to install Emacs-Jedi, if you want to help us ;) Using make was not perfect so I understand you wanted a better method. But it is solved in the new version. So, I hate to say it, but it would be nice if you can remove that recipe, to avoid further trouble.

I am trying to reduce ways to install Jedi by hiding it from users. All users have to know is that (1) virtualenv command have to be there and (2) they have to hit M-x jedi:install-server when error message says so. It helps us solving problem like #110 since we can track Python module installation. Overall, I think installation becomes easier, especially for new users.

For your question, Emacs-Jedi supports additional virtualenv for ages: http://tkf.github.io/emacs-jedi/latest/#jedi:server-args
By reading http://conda.pydata.org/docs/commands/install.html, it looks like each ROOT_DIR/envs/NAME is a virtual environment, right? Then you just have to pass --virtual-env ROOT_DIR/envs/NAME to jediepcserver.py. You can pass it as many as possible.

@asmeurer @spearsem If you want further discussion, please open a new issue. We are discussing two different questions, even we are talking about conda.

Owner

tkf commented Mar 17, 2014

That conda command is conda create -p jedi epc

Please don't increase ways to install Emacs-Jedi, if you want to help us ;) Using make was not perfect so I understand you wanted a better method. But it is solved in the new version. So, I hate to say it, but it would be nice if you can remove that recipe, to avoid further trouble.

I am trying to reduce ways to install Jedi by hiding it from users. All users have to know is that (1) virtualenv command have to be there and (2) they have to hit M-x jedi:install-server when error message says so. It helps us solving problem like #110 since we can track Python module installation. Overall, I think installation becomes easier, especially for new users.

For your question, Emacs-Jedi supports additional virtualenv for ages: http://tkf.github.io/emacs-jedi/latest/#jedi:server-args
By reading http://conda.pydata.org/docs/commands/install.html, it looks like each ROOT_DIR/envs/NAME is a virtual environment, right? Then you just have to pass --virtual-env ROOT_DIR/envs/NAME to jediepcserver.py. You can pass it as many as possible.

@asmeurer @spearsem If you want further discussion, please open a new issue. We are discussing two different questions, even we are talking about conda.

@davidhalter

This comment has been minimized.

Show comment
Hide comment
@davidhalter

davidhalter Mar 17, 2014

If you or @davidhalter could clarify what exactly happens here, that would help.

(Just speaking for Jedi). virtualenv isn't supported in a lot of ways. You can either specify the VIRTUAL_ENV variable in the shell or modify the sys.path yourself or implicitly by starting Jedi in a virtualenv.

"Support" obviously means "support for autocompletion", not support for being installed in a virtualenv.

If you or @davidhalter could clarify what exactly happens here, that would help.

(Just speaking for Jedi). virtualenv isn't supported in a lot of ways. You can either specify the VIRTUAL_ENV variable in the shell or modify the sys.path yourself or implicitly by starting Jedi in a virtualenv.

"Support" obviously means "support for autocompletion", not support for being installed in a virtualenv.

@tkf

This comment has been minimized.

Show comment
Hide comment
@tkf

tkf Mar 17, 2014

Owner

modify the sys.path yourself

Emacs Jedi does this. It is supported.

Owner

tkf commented Mar 17, 2014

modify the sys.path yourself

Emacs Jedi does this. It is supported.

@davidhalter

This comment has been minimized.

Show comment
Hide comment
@davidhalter

davidhalter Mar 17, 2014

@tkf Yes but it would be much nicer if we had a nice interface on the Jedi side - see also davidhalter/jedi#371.

@tkf Yes but it would be much nicer if we had a nice interface on the Jedi side - see also davidhalter/jedi#371.

@asmeurer

This comment has been minimized.

Show comment
Hide comment
@asmeurer

asmeurer Mar 21, 2014

Contributor

No, conda environments are not virtualenvs. Virtualenvs are hacks that fiddle with Python's site.py and does some symlinking. Conda environments are basically done the "right" way: each environment is basically a completely independent installation of everything in the prefix (including Python). Once you get how awesome conda environments are (not to mention conda packages themselves), you don't want to go back to using virtualenv.

I don't think anyone answered my question, which is, what (if anything) does jedi do when installed in a virtualenv to try to find completions for packages outside that virtualenv?

Contributor

asmeurer commented Mar 21, 2014

No, conda environments are not virtualenvs. Virtualenvs are hacks that fiddle with Python's site.py and does some symlinking. Conda environments are basically done the "right" way: each environment is basically a completely independent installation of everything in the prefix (including Python). Once you get how awesome conda environments are (not to mention conda packages themselves), you don't want to go back to using virtualenv.

I don't think anyone answered my question, which is, what (if anything) does jedi do when installed in a virtualenv to try to find completions for packages outside that virtualenv?

@davidhalter

This comment has been minimized.

Show comment
Hide comment
@davidhalter

davidhalter Mar 22, 2014

I don't think anyone answered my question, which is, what (if anything) does jedi do when installed in a virtualenv to try to find completions for packages outside that virtualenv?

I don't think we do anything. The only "magic" that happens is virtualenv detection by looking at VIRTUAL_ENV. But that's sort of a crappy implementation (see the latest few issues).

I don't think anyone answered my question, which is, what (if anything) does jedi do when installed in a virtualenv to try to find completions for packages outside that virtualenv?

I don't think we do anything. The only "magic" that happens is virtualenv detection by looking at VIRTUAL_ENV. But that's sort of a crappy implementation (see the latest few issues).

@kyleabeauchamp kyleabeauchamp referenced this issue in omnia-md/conda-recipes Apr 13, 2014

Merged

Add AmberTools conda recipe #2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment