Python use pip from code

Installing Packages¶

This section covers the basics of how to install Python packages .

It’s important to note that the term “package” in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a distribution ). It does not to refer to the kind of package that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a distribution using the term “package”. Using the term “distribution” is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself.

Requirements for Installing Packages¶

This section describes the steps to follow before installing other Python packages.

Ensure you can run Python from the command line¶

Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:

You should get some output like Python 3.6.3 . If you do not have Python, please install the latest 3.x version from python.org or refer to the Installing Python section of the Hitchhiker’s Guide to Python.

If you’re a newcomer and you get an error like this:

>>> python3 --version Traceback (most recent call last): File "", line 1, in NameError: name 'python3' is not defined 

It’s because this command and other suggested commands in this tutorial are intended to be run in a shell (also called a terminal or console). See the Python for Beginners getting started tutorial for an introduction to using your operating system’s shell and interacting with Python.

If you’re using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ! character:

In [1]: import sys ! --version Python 3.6.3

It’s recommended to write rather than plain python in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the python command refers to).

Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the python command in this tutorial with python3 and the python -m pip command with python3 -m pip —user . Do not run any of the commands in this tutorial with sudo : if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written.

Ensure you can run pip from the command line¶

Additionally, you’ll need to make sure you have pip available. You can check this by running:

If you installed Python from source, with an installer from python.org, or via Homebrew you should already have pip. If you’re on Linux and installed using your OS package manager, you may have to install pip separately, see Installing pip/setuptools/wheel with Linux Package Managers .

If pip isn’t already installed, then first try to bootstrap it from the standard library:

python3 -m ensurepip --default-pip

py -m ensurepip --default-pip

If that still doesn’t allow you to run python -m pip :

• Securely Download get-pip.py1
• Run python get-pip.py . 2 This will install or upgrade pip. Additionally, it will install setuptools and wheel if they’re not installed already.

Warning Be cautious if you’re using a Python install that’s managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use python get-pip.py —prefix=/usr/local/ to install in /usr/local which is designed for locally-installed software.

Ensure pip, setuptools, and wheel are up to date¶

While pip alone is sufficient to install from pre-built binary archives, up to date copies of the setuptools and wheel projects are useful to ensure you can also install from source archives:

python3 -m pip install --upgrade pip setuptools wheel

py -m pip install --upgrade pip setuptools wheel

Optionally, create a virtual environment¶

See section below for details, but here’s the basic venv 3 command to use on a typical Linux system:

python3 -m venv tutorial_env source tutorial_env/bin/activate

py -m venv tutorial_env tutorial_env\Scripts\activate

This will create a new virtual environment in the tutorial_env subdirectory, and configure the current shell to use it as the default python environment.

Creating Virtual Environments¶

Python “Virtual Environments” allow Python packages to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see Installing stand alone command line tools .

Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded.

Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.

Also, what if you can’t install packages into the global site-packages directory? For instance, on a shared host.

In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments.

Currently, there are two common tools for creating Python virtual environments:

• venv is available by default in Python 3.3 and later, and installs pip and setuptools into created virtual environments in Python 3.4 and later.
• virtualenv needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and pip , setuptools and wheel are always installed into created virtual environments by default (regardless of Python version).

The basic usage is like so:

python3 -m venv source /bin/activate

Источник

use «pip install/uninstall» inside a python script [duplicate]

how, inside a python script can I install packages using pip? I don’t use the os.system, I want to import pip and use it.

6 Answers 6

pip.main() no longer works in pip version 10 and above. You need to use:

from pip._internal import main as pipmain pipmain(['install', 'package-name']) 

For backwards compatibility you can use:

try: from pip import main as pipmain except ImportError: from pip._internal import main as pipmain 

Important to know: this will break if you call pip several times from your script, or if you first call it like this from your script and then call it in any other way (personally I used flit ). This is because pip will set os.environ[‘PIP_REQ_TRACKER’] to a temporary directory name which gets deleted afterwards, but environment is not cleared. So it is better to call pip in a subprocess using os.system or any other method available.

The precise reason for the name «_internal» is to be a clear indicator that you should NOT be using pip from within a script like this. see @Samizdis response above for a proper guide.

I think those answers are outdated. In fact you can do:

import pip failed = pip.main(["install", nameOfPackage]) 

and insert any additional args in the list that you pass to main(). It returns 0 (failed) or 1 (success)

It’s not a good idea to install packages inside the python script because it requires root rights. You should ship additional modules alongside with the script you created or check if the module is installed:

try: import ModuleName except ImportError: print 'Error, Module ModuleName is required' 

If you insist in installing the package using pip inside your script you’ll have to look into call from the subprocess module (» os.system() » is deprecated).

There is no pip module but you could easily create one using the method above.

what if using pip inside a virtualenv? it still might be possible without root permissions isn’t it ??

I used the os.system to emulate the terminal installing a pip module, (I know os.system is deprecated, but it still works and it is also the easiest way to do it), E.G I am making a Game Engine which has multiple python scripts that all use Pygame, in the startup file I use this code to install pygame onto the user’s system if they don’t have it:

import os os.system('pip install pygame') 

Unfortunately, I don’t know how to install pip if they don’t have it so this script is dependent on pip.

You can use ensurepip module which is available on all newer python versions: import ensurepip; ensurepip.bootstrap()

If you are behind a proxy, you can install a module within code as follow.

import pip pip.main(['install', '--proxy=user:password@proxy:port', 'packagename']) 

This is a comment to this post that didn’t fit in the space allotted to comments.

Note that the use case of installing a package can arise inside setup.py itself. For example, generating ply parser tables and storing them to disk. These tables must be generated before setuptools.setup runs, because they have to be copied to site_packages , together with the package that is being installed.

There does exist the setup_requires option of setuptools.setup , however that does not install the packages.

So a dependency that is required both for the installation process and for the installed package will not be installed this way.

Placing such a dependency inside install_requires does not always work as expected. Even if it worked, one would have to pass some function to setuptools.setup , to be run between installation of dependencies in setup_requires and installation of the package itself. This approach is nested, and thus against PEP 20.

So the two flat approaches that remain, are:

1. run setup.py twice, either automatically (preferred), or manually (by notifying the user that the tables failed to build prior to setuptools.setup .
2. first call pip (or some other equivalent solution), in order to install the required dependencies. Then proceed with building the tables (or whatever pre-installation task is necessary), and call setuptools.setup last.

Personally, I prefer No.2, because No.1 can be confusing to a user observing the console output during installation, unless they already know the intent of calling setuptools.setup twice.

Besides, whatever rights are needed for installation (e.g., root, if so desired), are certainly present when setup.py is run (and exactly then). So setup.py could be considered as the «canonical» use case for this type of action.

Источник