From PEP-370:
user script directory
A directory for binaries and scripts. [10] It's shared across Python versions and the destination directory for scripts.
Unix (including Mac)
~/.local/bin
Windows
%APPDATA%/Python/Scripts
Why does it propose version-specific user site dirs but not user script dirs? Wouldn't scripts coming from different python versions conflict each other then?
Edit. Yes, they would. I did a test with python2-pytest and python3-pytest. When installing both into user dir with pip, one pytest script overwrote another without a warning.
There seems to be a relevant link but it's dead:
Discussion about the bin directory http://permalink.gmane.org/gmane.comp.python.devel/91095
The shell doesn't support per-Python-version binaries. There is a single namespace for command-line executables, the first name found in the directories listed on PATH is used.
The point of the ~/.local/bin directory here is that it is added to the PATH environment variable, and that scripts and other executables are put there for command line use. And because there is only a single namespace for such executables, there is no point in putting commands into per-version directories here.
Instead, it is up to the project to provide you with versioned executables. The pip project uses setup.py configuration to pip, pipX and pipX.Y scripts when installed with Python X.Y, and so you'll always have a more specific version of the script when there are multiple Python versions. And you can also use the module as a script with pythonX.Y -m pip. Lots of Python command-line tools have similar support.
As for the lost GMane link (still available on the web archive); there are other archives of the Python-dev discussion still available, such as this grokbase.com rendering of the same post; that discussion was about what directory to place the scripts in, ~/bin or ~/.local/bin, and was never about per-Python-version directories.
Related
I have the following problem:
I have to run some test/diagnostic Python script on a Windows system. Due to explicit requirement, the system has no default system-wide Python instance, but there are two different Python instances installed, used locally by applications running on the system. However, both these instances lack some basic modules my script uses (like logging, urllib, configparser etc.).
I want to run %PYTHONPATH%\python.exe myscript.py where %PYTHONPATH% points to one of the installed Python instances, but install the required additional modules "somewhere" outside %PYTHONPATH% (preferrably, in the same directory where my script is installed) so that my script can use them.
As my script is a test tool, it should not modify the OS or installed software, so the Python installation under %PYTHONPATH% should not be changed in any way.
It is also expected that the installation can be fully automated, ie. the best way to install would be just have the modules in the same .zip file with my script which is unpacked onto the target path.
It is also important that the system has no Internet access, so I have to download required files on another machine and copy them to the target system.
Can you guide me how to do it?
I found an answer myself - it is quite simple:
obtain the zip file containing standard modules from the appropriate Python version distribution (in my case it was the file python38.zip, it is inside the main zip file downloadable from Python site)
Unpack the contents of this file to c:\mydir\Python38\site-packages, where c:\mydir is the directory containing my script
set the environment variable PYTHONUSERBASE=c:\mydir before running my script
Now I can run the script and it finds all "missing" standard modules in c:\mydir\Python38\site-packages.
I think what youy are seeking for is a python virtual environment.
( internet needed )
Check :
https://docs.python.org/fr/3/library/venv.html
Then for the installation, you can creat a .exe file containing all dependencies.
(no internet needed)
Check:
https://www.pyinstaller.org/
I have some packages installed under my ~/.local/lib/python2.7/site-packages/ subdir, which was for use with system python (/usr/bin/python). Now I have just installed Anaconda python (which is also python 2.7, but minor version 11). The whole idea of Anaconda distro is to have a self-containing python environment, such that EVERY module resides within anaconda install tree.
But what annoys me is that for some reason I cannot disable inclusion of ~/.local/lib/python2.7/site-packages/ from sys.path although I did not have PYTHONPATH environment variable. Is it possible to run python executable (in this case, Anaconda's python executable) without having to implicitly add ~/.local/lib/python2.7/site-packages/ and the eggs underneath it in the python search path?
Why this problem? Unfortunately the ~/.local/lib/python2.7/site-packages/easy-install.pth also contains a reference to /usr/lib/python2.7/dist-packages, which causes this system-wide dist-packages to still be searched for.
Well, there is a -s flag in python executable to disable searching the user site directory (`~/.local/lib/python2.7/site-packages etc). That solves the problem above!
I am trying to add an interpreter (created using virtualenv) to PyDev but I get the following error:
It seems that the Python /Lib folder
(which contains the standard library)
was not found /selected during the
instal process.
This folder (which contains files such
as threading.py and traceback.py) is
required for PyDev to function
properly (and it must contain the
actual source files, not only .pyc
files) ...
Note that if this is a virtualenv
install, the /Lib folder from the base
install needs to be selected (unlike
the site-packages which is
optional)...
The problem is that there is no /lib folder under my default installation... I created the virtualenv with the 'no-site-packages' option... How can I solve? thanks!
I've come across this myself before. When adding an interpreter created using virtualenv in PyDev, when it asks for the folders that need to be added to the SYSTEM pythonpath, I had to select
/usr/lib/python2.7
/usr/lib/python2.7/lib-tk
/usr/lib/python2.7/plat-linux2
See the screenshot for what I had to do. Here temp is my virtualenv.
Even though the system Python directory was added, PyDev did not pick up the global site packages, so you still achieve the "no-site-packages" effect. I'm assuming you would have to do something similar on Windows i.e. select all the folder in the "Select Needed" dialog, including the C:\Pythonx.x folder.
EDIT: I just tried it out with PyDev 2.3 on Eclipse Indigo (Arch Linux with virtualenv 1.7), and it seems that plat-linux2 does not need to be selected (not sure about lib-tk, but /usr/lib/python2.7 is definitely required). Thanks fijiaaron for pointing it out.
EDIT 2: Pydev 2.5 (and probably 2.6 too, from the docs) still requires the /Lib folder to function properly, though it now lets you ignore the "Python stdlib not found" dialog and add the interpreter anyway (but mentions that it still needs to be included later).
to skip this message in pydev you can create manual symbolic links to stdlib not linked by virtualenv.
Example:
ln -s /usr/lib/python3.3/threading.py /home/path/to/virtual/myenv/lib/python3.3/threading.py
ln -s /usr/lib/python3.3/traceback.py /home/path/to/virtual/myenv/lib/python3.3/traceback.py
There is a lot of stdlib not linked in virtualenv. Probably you should make as you need manualy.
Look at /usr/lib/python3.3 and compare with /home/path/to/virtual/myenv/lib/python3.3
You can add, per example, /usr/lib/python3.3/concurrent/ in your pydev path.
if you add /usr/lib/python2.7 (or /usr/lib/python3.3) as suggest by Mr. Bhaduri you can explode your virtualenv because your package could look at site-packages directory in /usr/lib/python2.7 and this is exactly what you dont want.
You want isolate your enviroment. You want your package look only in /home/path/to/virtual/myenv/lib/python3.3/site-packages/
I have been programming in Python for a while now, and have created some utilities that I use a lot. Whenever I start a new project, I start writing, and as I need these utilities I copy them from where ever I think the latest version of the particular utility is. I have enough projects now that I am losing track of where the latest version is. And, I will upgrade one of these scripts to fix a problem in a specific situation, and then wish it had propagated back to all of the other projects that use that script.
I am thinking the best way to solve this problem is to create a directory in the site-packages directory, and put all of my utility modules in there. And then add this directory to the sys.path directory list.
Is this the best way to solve this problem?
How do modify my installation of Python so that this directory is always added to sys.path, and I don't have to explicitly modify sys.path at the beginning of each module that needs to use these utilities?
I'm using Python 2.5 on Windows XP, and Wing IDE.
The site-packages directory within the Python lib directory should always be added to sys.path, so you shouldn't need to modify anything to take care of that. That's actually just what I'd recommend, that you make yourself a Python package within that directory and put your code in there.
Actually, something you might consider is packaging up your utilities using distutils. All that entails is basically creating a setup.py file in the root of the folder tree where you keep your utility code. The distutils documentation that I just linked to describes what should go in setup.py. Then, from within that directory, run
python setup.py install
to install your utility code into the system site-packages directory, creating the necessary folder structure automatically. Or you can use
python setup.py install --user
to install it into a site-packages folder in your own user account.
Add your directory to the PYTHONPATH environment variable. For windows, see these directions.
If it's not in site-packages then you can add a file with the extension .pth to your site-packages directory.
The file should have one path per line, that you want included in sys.path
I currently have it installed and it's running a website.
http://www.djangoproject.com/download/
This is the new version. How do I upgrade it? (How do I install the new version over my current one?)
read about this in :
http://docs.djangoproject.com/en/dev/topics/install/
For installing Django to be able to update to the latest code in trunk:
If you'd like to be able to update
your Django code occasionally with the
latest bug fixes and improvements,
follow these instructions:
1.Make sure that you have Subversion installed, and that you can run its
commands from a shell. (Enter svn help
at a shell prompt to test this.)
2.Check out Django's main development branch (the 'trunk') like so:
svn co
http://code.djangoproject.com/svn/django/trunk/
django-trunk
3.Next, make sure that the Python interpreter can load Django's code.
There are various ways of
accomplishing this. One of the most
convenient, on Linux, Mac OSX or other
Unix-like systems, is to use a
symbolic link:
ln -s pwd/django-trunk/django
SITE-PACKAGES-DIR/django (In the above
line, change SITE-PACKAGES-DIR to
match the location of your system's
site-packages directory, as explained
in the "Where are my site-packages
stored?" section above.)
Alternatively, you can define your
PYTHONPATH environment variable so
that it includes the django-trunk
directory. This is perhaps the most
convenient solution on Windows
systems, which don't support symbolic
links. (Environment variables can be
defined on Windows systems from the
Control Panel.)
What about Apache and mod_python?
If you take the approach of setting
PYTHONPATH, you'll need to remember to
do the same thing in your Apache
configuration once you deploy your
production site. Do this by setting
PythonPath in your Apache
configuration file.
More information about deployment is
available, of course, in our How to
use Django with mod_python
documentation.
4.On Unix-like systems, create a symbolic link to the file
django-trunk/django/bin/django-admin.py
in a directory on your system path,
such as /usr/local/bin. For example:
ln -s
pwd/django-trunk/django/bin/django-admin.py
/usr/local/bin This simply lets you
type django-admin.py from within any
directory, rather than having to
qualify the command with the full path
to the file.
On Windows systems, the same result
can be achieved by copying the file
django-trunk/django/bin/django-admin.py
to somewhere on your system path, for
example C:\Python24\Scripts.
You don't have to run python setup.py
install, because you've already
carried out the equivalent actions in
steps 3 and 4.
When you want to update your copy of
the Django source code, just run the
command svn update from within the
django-trunk directory. When you do
this, Subversion will automatically
download any changes
For updating Django from stable release to another stable release:
If you are upgrading your installation of Django from a previous
version, you will need to uninstall the old Django version before
installing the new version.
If you installed Django using setup.py install, uninstalling is as
simple as deleting the django directory from your Python
site-packages.
If you installed Django from a Python egg, remove the Django .egg
file, and remove the reference to the egg in the file named
easy-install.pth. This file should also be located in your
site-packages directory.
First of all, don't. Install/upgrade it on your staging server first and test your app to make sure that it still works. Only after complete testing should you cut over to the new version on your production website.