If I have a module, foo, in Lib/site-packages, I can just import foo and it will work. However, when I install stuff from eggs, I get something like blah-4.0.1-py2.7-win32.egg as a folder, with the module contents inside, yet I still only need do import foo, not anything more complicated. How does Python keep track of eggs? It is not just dirname matching as if I drop that folder into a Python installation without going through dist-utils, it does not find the module.
To be clearer: I just installed zope. The folder name is "zope.interface-3.3.0-py2.7-win32.egg". This works:
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import zope.interface
>>>
I create a "blah-4.0.1-py2.7-win32.egg" folder with an empty module "haha" in it (and __init__.py). This does not work:
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import blah.haha
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named blah.haha
>>>
This does, though:
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg_resources import require
>>> require("blah>=1.0")
[blah 4.0.1 (c:\python27\lib\site-packages\blah-4.0.1-py2.7-win32.egg)]
>>> import haha
>>>
So how do I make it work without a require?
If you use the easy_install script provided by setuptools (or the Distribute fork of it) to install packages as eggs, you will see that, by default, it creates a file named easy-install.pth in the site-packages directory of your Python installation. Path configuration files are a standard feature of Python:
A path configuration file is a file
whose name has the form package.pth
and exists in one of the four
directories mentioned above; its
contents are additional items (one per
line) to be added to sys.path.
easy_install makes heavy use of this Python feature. When you use easy_install to add or update a distribution, it modifies easy-install.pth to add the egg directory or zip file. In this way, easy_install maintains control of the module searching order and ensures that the eggs it installs appear early in the search order. Here is an example of the contents of an easy-install.pth:
import sys; sys.__plen = len(sys.path)
./appscript-0.21.1-py2.6-macosx-10.5-ppc.egg
./yolk-0.4.1-py2.6.egg
./Elixir-0.7.1-py2.6.egg
./Fabric-0.9.0-py2.6.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginse
rt',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)
As you can see here and if you examine the code in setuptools, you will find it goes to some trickery to bootstrap itself and then cover its tracks which can make debugging problems with site.py and interpreter startup a bit interesting. (That is one of the reasons that some developers are not fond of using it.)
If you use the -m parameter of easy_install to install a distribution as multi-version, the easy-install.pth entry for it is not added or is removed if it already exists. This is why the easy_install documentation tells you to use -m before deleting an installed egg.
When you run easy_install it copies the egg into site-packages and puts the path to that egg on your sys.path variable. (Note that sys.path is not your PATH environment variable, it is constructed from PYTHONPATH and other environment variables. So the .egg file you install with easy_install gets put in some environment variable and python knows to add it to sys.path when the python interpreter starts).
To get blah.haha to work in your example, either run easy_install blah-4.0.1-py2.7-win32.egg and then you can import haha from within python, or just put the haha module directly in site-packages.
Related
I have installed the latest version of python (3.7.3)
When I go to cmd and I put py, it says my version is 3.7.3. But the problem comes when i put python or python --version, because it says that my version is 2.7.10. And i don´t know why.
I´m learning how to do my first website, and i´m just following what the tutorial says. I don´t know if the version of python is the cause of the problem, but i tell you what happens to me appart from not knowing what version i have.
I´m using Visual Studio Code and the guy from the tutorial said that we had to have at least a version of python over 3, and to find this out we have to write on CMD python --version. Then we had to know what version of pip we have putting pip --version.
Now I´ll show you the code he did and I copied, I had to install flask from CMD putting pip install flask.
So when I go to CMD to run this as the youtuber did, putting cd Desktop then cd NoFear (NoFear is the name of the folder) and finally python index.py. I got the following output:
C:\Users\Usuario\Desktop\NoFear>python index.py
Traceback (most recent call last):
File "index.py", line 1, in <module>
from flask import Flask
ImportError: No module named flask
C:\Users\Usuario>py
Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 21:26:53) [MSC v.1916 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
C:\Users\Usuario>python
Python 2.7.10 (default, May 23 2015, 09:44:00) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
C:\Users\Usuario>python --version
Python 2.7.10
from flask import Flask
app = Flask(__name__)
#app.route('/')
def home():
return 'Hello World'
if __name__=='__main__':
app.run()
Type Py -3 index.py in cmd instead of typing python index.py. I hope this helps
You have two versions of python so uninstall the older version first
You can create a virtual environment that will isolate your Python dependencies. Because you have stated you are using Python 3.7.3, you can create a virtual environment by running the following command:
$ python3 -m venv .venv
Then you can activate it by using:
$ source .venv/bin/activate
Then if you run python in the terminal, you will start Python 3.7.3 because your virtual environment has been created using this version of Python.
Finally, if you want to deactivate the virtual environment just run:
$ deactivate
You can uninstall a your other python versions or if you want to keep them you can rearrange the path. That being said I would recommend looking into creating virtual environments.
1) In the bottom left of windows search for: environment variables
2) Select Environment Variables... on the bottom right.
3) Select the Path variable on the top (or bottom if there is not one on the top).
4) Move python3 above python2.7 and save.
Maybe get atom cause you are working in IDLE and i had the same problem each time you want to use code form IDLE on other software you cannot run it because of the lines on top
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 19:29:22) [MSC v.1916 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
you have to take them of or use virtual studio or atom or oder IDE, i think.
My Python 2 environmental path:
C:\Python27
C:\Python27\Scripts
My Python 3 environmental path:
C:\Python35
C:\Python35\Scripts
I set the environmental path for Anaconda2
C:\Users\User\Anaconda2\Scripts
C:\Users\User\Anaconda2
But when i typed python to enter the shell in cmd (C:\Users\user)
Importing the module of Anaconda like numpy or matplotlib
C:\Users\User>python
Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named numpy
C:\Users\User>cd Anaconda2
C:\Users\User\Anaconda2>python
Python 2.7.12 |Anaconda 4.1.1 (64-bit)| (default, Jun 29 2016, 11:07:13) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import numpy
>>>
So i don't know
1.Why my module can't import while not in Anaconda2
2.It is said that the path of Python2 will overrdie the Python,so how to enter in the Python35 shell?
thanks everybody
Each Python installation has its own libraries. As you will see, you are not running the same Python 2.7 interpreter when you run with Anaconda active as you are without (I assume that's either the system Python or one you installed yourself).
Libraries installed in one interpreter aren't available to others. You should consider learning about conda environments to allow you to manage multiple projects easily.
The command deactivate should terminate the Anaconda environment, and if the Python 3 interpreter is first on your PATH you should then be able to run it. Another way would be to explicitly use the command
C:\Python35\python
which should work even with Anaconda active.
Caution: it's a long time since I used Windows, and I don't have current information on getting multiple Pythons to live happily together on Windows.
I'm in the early stages of integrating some Python to invoke some computations in Matlab and roll up all the figures into some html generation I'll be doing in ll.xist. I had initially installed Python 2.7.5 32bit, but with a 64bit Matlab R2015a installation I could not install the matlab engine for that version of python. I then downloaded a 64bit version of Python 2.7.9 and tried to do a pip into ll-xist, which was apparently not well maintained and failed. I then downloaded Python 3.4.3 64bit, downloaded the ll.xist installer ll-xist-5.13.win-amd64-py3.4.exe and thought I was good to go. I had to do a pip to pull in cssutils, which succeeded.
Now I come to the point where I invoke my python file from the console. If I invoke it preceded with python everything works fine, if I don't the import isn't recognized. What could account for that discrepancy? Looks like some installation snafu between the various versions I've installed, somehow the python version on the path isn't being called appropriately and I'm guessing the 2.7.9 version of python is being invoked somehow because that install never had ll.xist installed, though my 2.7.5 install did.
C:\Temp>python MyScript.py a.txt b.txt
file1: a.txt
file2: b.txt
C:\Temp>MyScript.py a.txt b.txt
Traceback (most recent call last):
File "C:\Temp\MyScript.py", line 20, in <module>
from ll.xist import xsc
ImportError: No module named ll.xist
Here's a sanity check too...
C:\Temp>python
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
C:\Temp>which python
/cygdrive/c/Python34/python
Check the file association for .py. While the proper installation might be in your path, the file association might still be pointing to a different version.
You can check this by importing the sys module in a test script and call print(sys.version). Then run the test script with python test.py and just test.py to see which versions are printed.
Turns out the governing issue here is what is known as the Python Launcher for Windows.
3.4. Python Launcher for Windows New in version 3.3.
The Python launcher for Windows is a utility which aids in the
location and execution of different Python versions. It allows scripts
(or the command-line) to indicate a preference for a specific Python
version, and will locate and execute that version.
From my console, I can see the "default" version via the py command...
C:\Users\me>py
Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
C:\Users\me>py -3
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
Here's the fundamental fix...
The key benefit of this is that a single launcher can support multiple
Python versions at the same time depending on the contents of the
first line.
The first line I had to add in my case to my script was
#! python3
Great commentary linked here for details and motivations behind the Launcher.
I have build my virtual env with this command:
virtualenv env --distribute --no-site-packages
And then I have installed several modules (django etc) into env with pip, the problem is that when I wanted to run the code on the second machine it would not work, here is what I have done:
visgean#rewitaqia:~/scripty/project_name$ source ./env/bin/activate
(env)visgean#rewitaqia:~/scripty/project_name$ python
Python 2.7.1+ (r271:86832, Sep 27 2012, 21:12:17)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> django.__file__
'/home/visgean/scripty/project_name/env/lib/python2.7/site-packages/django/__init__.pyc'
but when I want to run it on the second machine:
(env)user#debian:~/project_name$ python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named django
>>>
I wild error appears! The first machine is ubuntu, the second one is ubuntu. There seems to be some broken links in /home/user/project_name/env/lib/python2.7 , is that the problem? and if so, how should I prevent it/repair it?
If you are just copying the virtualenv to the second machine you may encounter some issues. From the virtualenv site:
Normally environments are tied to a specific path. That means that you
cannot move an environment around or copy it to another computer. You
can fix up an environment to make it relocatable with the command:
$ virtualenv --relocatable ENV
This will make some of the files
created by setuptools or distribute use relative paths, and will
change all the scripts to use activate_this.py instead of using the
location of the Python interpreter to select the environment.
Note: you must run this after you've installed any packages into the
environment. If you make an environment relocatable, then install a
new package, you must run virtualenv --relocatable again.
I have just noticed that I did have a wrong version of python on the second machine - debian does not have python2.7, installing 2.7 and pip for is the solution
I created a virtualenv, and while it has many system paths, it doesn't have others. Specifically, pyshared and dist-packages don't seem to be included. As a result, my system-wide MySQLdb and psycopg2 aren't available. Any ideas why?
Seems to be related to Ubuntu's messing with python and virtualenv
The only possible way that i'm aware of, is if you have created your virtualenv with the argument --no-site-packages:
from Here:
If you build with virtualenv
--no-site-packages ENV it will not inherit any packages from
/usr/lib/python2.5/site-packages (or
wherever your global site-packages
directory is). This can be used if you
don't have control over site-packages
and don't want to depend on the
packages there, or you just want more
isolation from the global system.
so Here is an example to understand more:
First i will create a virtualenv normally (without --no-site-package) and you will see that
i can always access django that is installed in my system site-packages (or dist-packages):
$ virtualenv A
New python executable in A/bin/python
Installing setuptools............done
$ source A/bin/activate
(A)$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> django.__file__
'/usr/local/lib/python2.6/dist-packages/django/__init__.pyc'
But now i will create the virtual env using --no-site-package:
$ virtualenv B --no-site-package
New python executable in B/bin/python
Installing setuptools............done.
$ source B/bin/activate
(B)$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named django
now you see that virtaulenv was able to access django from system dist-packages (ubuntu) in my machine.
Hope this will help :)