I use macvim built with python interpreter support on OS X lion for python coding.
In order for omnicompletion to work with the libraries for a particular python
virtualenv I would like macvim to recognize that it is opened within an activated
python virtualenv.
On Ubuntu this works exactly like i expect it to;
If I open vim in and activate virtualenv, all libs specific to that virtualenv are on Python's
path. This does not work in macvim when launch from the mvim shell script inside an
activated virtualenv. Instead, the Python path consists of the global Python's libs.
I know there is a way around this with some semi heavy vim-scripting, but I would
prefer it if it behaves like on Ubuntu. I would at least want to know why it doesn't
behave that way. Any ideas are welcome.
Related
Firstly, I have an objective of using using tesseract-OCR to extract data with. However, I have a pdf file which needs to be converted into JPEG, which is said to be easily carried out by the pdf2image library.
That sounds simple enough, but I get confused with how certain libraries are 'apparently' either one of the following: 'dependencies', are 'wrappers' or simply Windows or Linux based.
Particularly, a 'feature', that is 'convert_from_path' that I feel I will needs as I have directories to attend my pdfs from, requires a library called 'poppler' that - 'is in Linux' The readme text suggest manipulating a .path file which was not obvious to me as it was in a r'' string? I know regex starts with r'' strings, but how that is important to adding paths it was not specified.
Moving on, I followed a recent thread installing WSL which I had done. Now I have a linux terminal in Pycharm IDE where I have recently installed PIP3. From here, it was advice I install the packages I require. But on which terminal? Install using BASH? or the default terminal (however you call it for windows?).
This also brings me to the title of my question. Say I install it in BASH, does that mean I can import the library like so:
import matplotlib #pre-installed with CMD venv
import os #pre-installed with CMD venv
import pillow #pip-installed with CMD venv
import tesseract-ocr #pip-installed with CMD venv
import poppler #pip3-installed with BASH # and how does a CMD venv even interact with a BASH?
import pdf2image #pip-installed with CMD venv, but is a wrapper that is on linux?
will these libraries simply be read by both the python for windows and python for Linux serially? (as in, if it cant 'read' the library in window, it would go to the next interpreter that is the Linux interpreter if I have added it in in my venv interpreter's settings?)
Also, Pycharm runs on a python 3.7, while WSL Linux has a default python 3.8.10. Not to mention WSL -version does not exist for windows when I thought I could just update them so they match.
At this point, the answer I am hoping to receive, is whether an import method like above - installed by different 'systems' inside a python ide such as Pycharm or even when ran in CMD would work or would not work and why not?
I am trying to use Anaconda and conda environments to allow Python programs for data acquisition* etc. to run from the (Anaconda) command line on Windows. The set up will be that the Python programs are installed to a particular location (cloned from Github), within %PATH% or whichever environment variable is more appropriate.
From an Anaconda command prompt in another directory and a particular conda environment, I want (both myself and other users) to be able run either python test.py <args> or test.py <args> (either solution is acceptable) and have a system wide conda environment run its Python to execute the program. test.py can/will have an appropriate shebang set.
Right now the python test.py calls the correct Python within the active conda environment, but cannot find the test.py program as Python won't search the %PATH% or similar looking for the program. test.py does something (Windows does not complain that the executable can't be found, and I've been playing with the file associations to get this far), but doesn't appear to start Python - a simple print function or raise statement as the only entry in the file does nothing.
I've tried setting file associations in Windows, but this hasn't changed anything. I've copied the py.exe/pyw.exe across to the Anaconda environments, with no change.
Is this something that can be done within Anaconda, or am I going to have to fall back on installing base Python directly and trying to use the launcher mechanism there?
Note that I'm also intending to deploy these programs on Raspbian, so any solutions, including non-Anaconda ones, that will work cross platform there would be worth extra effort on my part.
*these programs have significant usage of library packages for accessing external USB/GPIB/serial/ethernet connected lab equipment and use matplotlib, scipy, etc., hence the desire for a cloneable conda environment as the base environment.
It turns out the correct answer to this is fairly simple, but is fairly hard to find explained well. This might be a little clearer than the other answers I found:
Install the standalone launcher from pylauncher and add #!/usr/bin/env python shebangs to your scripts.
This should register .py files to Python.File and will find your Anaconda Pythons in appropriate environments. If you don't have a non-Anaconda python, it will use the Anaconda base environment (these two facts were the key element I was missing from various other answers around this problem that I had looked at, including the documents on python.org).
If you have a Python from python.org installed, then a standalone command line shell will use that, defaulting to Python 2.x, then Python 3.x. With #!/usr/bin/env python shebang, then a regular command shell will try to use python.org pythons first, then the Anaconda base environment. An Anaconda prompt will use the active environment. #! /usr/bin/env python2 or python3 will try to use python.org pythons only and fail if they are not found.
Installing Python 2.7 from python.org installers (and letting the installer set the file associations) will break pylauncher, and reinstalling will not fix it. Instead, set Computer\HKEY_CLASSES_ROOT\Python.File\Shell\open\command default value to "C:\WINDOWS\py.exe" "%L" %* to revert back to the pylauncher set up (assuming you used the launchwin.* packages to install it).
So, I've been toying around with python environments and I think i screwed mine up.
So when I ran python in shell, it would tell me i'm running on 2.7
I'm on windows 10, and i need a python switcher for my next project so i download pywin and used pywin to switch it to 3.5
the command i used was
pywin setdefault 3.5
now when i type python it says
python is not recognized as an internal or external command.
but py produces
Python 2.7.12
Now i can't use pip, easy_install, virtualenv
all of these commands i used to use, i suddenly no longer have access to them.
I tried switching back
but it wont even recognize pywin anymore.
The best way to check which Python version is executed is to check your environment variables. Another way of checking this is using the which command. (open cmd and run which python).
But, first you need to start a new cmd prompt to ensure your environment variables are not altered.
On Windows, but also any OS, you need to check the PATH and PYTHONPATH variables.
For Windows, follow the recommandations available in the Python documentation.
If you're not very experienced with working with windows, installations, and other similar things, I would recommend that you uninstall python, delete all versions/folders containing python (compiled) files (those that were installed with python, not the ones you've written) and then reinstall python. The installer should re-set the path variable to the correct location.
I have a full python installation with files in /usr/local/, but also have one that I compiled from source sitting in ~/python_dist. If I look at sys.path on each interpreter I see that they indeed import from different libraries.
Currently I can run $ PYTHONPATH=~/other_py_libs ~/python_dist/bin/python to invoke the custom interpreter with some other modules available in the path. However, I don't want permanently change the global PYTHONPATH variable.
How can I permanently change the python path for only one specific python install?
The easiest way to do this is to use a virtualenv (manage with virtualenvwrapper). With virtual environments you can set up different, isolated python environments (kind of like little python playgrounds). Switching between them (with the help of virtualenvwrapper) is as easy as typing workon envname. You don't have to worry about switching the PYTHONPATH around, and you can direct scripts to use a specific environment simply by running them with the python install in that environment, e.g. using #! /home/myname/.virtualenvs/envname/bin python.
Just reformatted my Mac to Yosemite and installed Python 2 & 3 using Homebrew. I've also setup some aliases in my bash_profile file which allows me to activate which version of Python I want to use. So if I type p3, it'll launch the python3 shell.
I'm wondering if it's possible to activate a specific version of Python without it starting the Python shell? So if I bring any files into the Terminal for instance, it'll use the version which I've activated?
Cheers!
Apologies if this has been answered elsewhere, I had a good search but I couldn't find anything.
Rather than writing your own scripts to manage different Python versions, I would suggest using a highly-used manager that has been tested in and out by the community: pyenv. With pyenv you can:
Easily install several different Python versions from the command line with no issues of them fighting (pyenv install 3.4.2)
Create virtual environments from any one of those versions if you want to compartmentalize the packages that are available (pyenv virtualenv 3.4.2 mypy3projectvenv), and
Set specific environments or versions to be active either
globally (pyenv global [version-or-venv]),
locally in and below folders you configure (pyenv local [ver-or-venv]), usually useful for projects that you have at a specific version/virtualenv, and
local to the shell until closed (pyenv shell [ver-or-venv]) (this is perhaps most-similar to your putative p3 command.
After setting the Python you want to use, all Python-related calls are redirected to their appropriate target (e.g. python, pip, easy_install, ipython*, django-admin*). Don't execute the Python scripts with any special command, just call them normally (or prefix a standard #!/usr/bin/env python shebang)
*If installed in that version/virtualenv
If you use the pyenv-installer script:
curl -L https://raw.githubusercontent.com/yyuu/pyenv-installer/master/bin/pyenv-installer | bash
Then add the couple lines it tells you to your ~/.bash_profile script (and either source it or restart bash)...you'll be up and running in seconds. The trick is usually installing all the Python build dependencies with brew (sqlite, OpenSSH, zlib...), but after that then you're golden.