Pipenv install python version

Pipenv: Sacred Marriage of Pipfile, Pip, & Virtualenv¶

Pipenv — the officially recommended Python packaging tool from Python.org, free (as in freedom).

Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses Pipfile, pip, and virtualenv into one single toolchain. It features very pretty terminal colors. Windows is a first–class citizen, in our world.

It automatically creates and manages a virtualenv for your projects, as well as adds/removes packages from your Pipfile as you install/uninstall packages. The lock command generates a lockfile ( Pipfile.lock ).

The problems that Pipenv seeks to solve are multi-faceted:

• When using Pipenv, you no longer need to use pip and virtualenv separately. They work together.
• Managing a requirements.txt file can be problematic, so Pipenv uses the upcoming Pipfile and Pipfile.lock instead, which is superior for basic use cases.
• Hashes are used everywhere, always. Security.

Install Pipenv Today!¶

If you have excellent taste, there’s also a fancy installation method.

User Testimonials¶

Jannis Leidel, former pip maintainer— Pipenv is the porcelain I always wanted to build for pip. It fits my brain and mostly replaces virtualenvwrapper and manual pip calls for me. Use it. Jhon Crypt— Pipenv is the best thing since pip, thank you! Isaac Sanders— Pipenv is literally the best thing about my day today. Thanks, Kenneth!

☤ Pipenv Features¶

• Enables truly deterministic builds, while easily specifying what you want.
• Automatically generates and checks file hashes for locked dependencies.
• Automatically finds your project home, recursively, by looking for a Pipfile .
• Automatically generates a Pipfile , if one doesn’t exist.
• Automatically generates a Pipfile.lock , if one doesn’t exist.
• Automatically creates a virtualenv in a standard location.
• Automatically adds packages to a Pipfile when they are installed.
• Automatically removes packages from a Pipfile when they are un-installed.
• Also automatically updates pip and itself, when asked.

The main commands are install , uninstall , and lock , which generates a Pipfile.lock . These are intended to replace $ pip install usage, as well as manual virtualenv management (to activate a virtualenv, run $ pipenv shell ).

Basic Concepts¶

• A virtualenv will automatically be created, when one doesn’t exist.
• When no parameters are passed to install , all packages [packages] specified will be installed.
• To initialize a Python 3 virtual environment, run $ pipenv —three .
• To initialize a Python 2 virtual environment, run $ pipenv —two .
• Otherwise, whatever virtualenv defaults to will be the default.

Other Commands¶

• graph will show you a dependency graph, of your installed dependencies.
• shell will spawn a shell with the virtualenv activated.
• run will run a given command from the virtualenv, with any arguments forwarded (e.g. $ pipenv run python ).
• check asserts that PEP 508 requirements are being met by the current environment.

Further Documentation Guides¶

• Pipenv & Virtual Environments
  • ☤ Make sure you’ve got Python & pip
  • ☤ Installing Pipenv
  • ☤ Installing packages for your project
  • ☤ Using installed packages
  • ☤ Next steps
  • ☤ Example Pipfile & Pipfile.lock
  • ☤ Importing from requirements.txt
  • ☤ Specifying Versions of a Package
  • ☤ Specifying Versions of Python
  • ☤ Fancy Installation of Pipenv
  • ☤ Pragmatic Installation of Pipenv
  • ☤ Crude Installation of Pipenv
  • ☤ Environment Management with Pipenv
  • ☤ Configuration With Environment Variables
  • ☤ Custom Virtual Environment Location
  • ☤ Testing Projects
  • ☤ Pipfile.lock Security Features
  • ☤ Shell Completion

  Источник

  Specifiers¶

  You can specify versions of a package using the Semantic Versioning scheme (i.e. major.minor.micro ).

  To install a major version of requests you can use:

  $ pipenv install requests~=1.1

  Pipenv will install version 1.2 as it is a minor update, but not 2.0 .

  To install a minor version of requests you can use:

  $ pipenv install requests~=1.0.1

  Pipenv will install version 1.0.4 as it is a micro version update, but not 1.1.0 .

  This will update your Pipfile to reflect this requirement, automatically.

  In general, Pipenv uses the same specifier format as pip. However, note that according to PEP 440, you can’t use versions containing a hyphen or a plus sign.

  To make inclusive or exclusive version comparisons you can use:

  $ pipenv install "requests>=1.4" # will install a version equal or larger than 1.4.0 $ pipenv install "requests2.19" # will install 2.19.1 but not 2.19.0

  The use of double quotes around the package and version specification (i.e. «requests>2.19» ) is highly recommended to avoid issues with Input and output redirection in Unix-based operating systems.

  The use of ~= is preferred over the == identifier as the latter prevents pipenv from updating the packages:

  $ pipenv install "requests~=2.2" # locks the major version of the package (this is equivalent to using >=2.2, ==2.*)

  To avoid installing a specific version you can use the != identifier.

  For an in depth explanation of the valid identifiers and more complex use cases check the relevant section of PEP-440.

  Specifying Versions of Python¶

  To create a new virtualenv, using a specific version of Python you have installed (and on your PATH ), use the —python VERSION flag, like so:

  When given a Python version, like this, Pipenv will automatically scan your system for a Python that matches that given version.

  If a Pipfile hasn’t been created yet, one will be created for you, that looks like this:

  [[source]] url = "https://pypi.python.org/simple" verify_ssl = true name = "pypi" [dev-packages] [packages] [requires] python_version = "3.11"

  The inclusion of [requires] python_version = «3.11» specifies that your application requires this version of Python, and will be used automatically when running pipenv install against this Pipfile in the future (e.g. on other machines). If this is not true, feel free to simply remove this section.

  If you don’t specify a Python version on the command–line, either the [requires] python_full_version or python_version will be selected automatically, falling back to whatever your system’s default python installation is, at time of execution.

  Editable Dependencies ( -e . )¶

  You can tell Pipenv to install a path as editable — often this is useful for the current working directory when working on packages:

  $ pipenv install --dev -e . $ cat Pipfile . [dev-packages] "e1839a8" = .

  All sub-dependencies will get added to the Pipfile.lock as well. Sub-dependencies are not added to the Pipfile.lock if you leave the -e option out.

  VCS Dependencies¶

  VCS dependencies from git and other version control systems using URLs formatted according to the following rule:

  The only optional section is the @ section. When using git over SSH, you may use the shorthand vcs and scheme alias git+git@:/@#egg= . Note that this is translated to git+ssh://git@ when parsed.

  Note that it is strongly recommended that you install any version-controlled dependencies in editable mode, using pipenv install -e , in order to ensure that dependency resolution can be performed with an up-to-date copy of the repository each time it is performed, and that it includes all known dependencies.

  Below is an example usage which installs the git repository located at https://github.com/requests/requests.git from tag v2.20.1 as package name requests :

  $ pipenv install -e git+https://github.com/requests/requests.git@v2.20.1#egg=requests Creating a Pipfile for this project. Installing -e git+https://github.com/requests/requests.git@v2.20.1#egg=requests. [. snipped. ] Adding -e git+https://github.com/requests/requests.git@v2.20.1#egg=requests to Pipfile's [packages]. [. ] $ cat Pipfile [packages] requests = 

  Valid values for include git , bzr , svn , and hg . Valid values for include http , https , ssh , and file . In specific cases you also have access to other schemes: svn may be combined with svn as a scheme, and bzr can be combined with sftp and lp .

  You can read more about pip’s implementation of VCS support here __. For more information about other options available when specifying VCS dependencies, please check the Pipfile spec _.

  Specifying Package Categories¶

  Originally pipenv supported only two package groups: packages and dev-packages in the Pipfile which mapped to default and develop in the Pipfile.lock . Support for additional named categories has been added such that arbitrary named groups can utilized across the available pipenv commands.

  The name will be the same between Pipfile and lock file, however to support the legacy naming convention it is not possible to have an additional group named default or develop in the Pipfile .

  By default pipenv lock will lock all known package categorises; to specify locking only specific groups use the —categories argument. The command should process the package groups in the order specified.

  # single category pipenv install six --categories prereq # multiple categories pipenv sync --categories="prereq packages" # lock and uninstall examples pipenv lock --categories="prereq dev-packages" pipenv uninstall six --categories prereq

  The packages / default specifiers are used to constrain all other categories just as they have done for dev-packages / develop category. However this is the only way constraints are applied – the presence of other named groups do not constraint each other, which means it is possible to define conflicting package versions across groups. This may be desired in some use cases where users only are installing groups specific to their system platform.

  Specifying Basically Anything¶

  If you’d like to specify that a specific package only be installed on certain systems, you can use PEP 508 specifiers to accomplish this.

  Here’s an example Pipfile , which will only install pywinusb on Windows systems::

  [[source]] url = «https://pypi.python.org/simple» verify_ssl = true name = «pypi» [packages] requests = «*» pywinusb =

  Here’s a more complex example::

  [[source]] url = «https://pypi.python.org/simple» verify_ssl = true [packages] unittest2 = =1.0,= ‘3.0’ and python_version

  Markers provide a ton of flexibility when specifying package requirements.

  Stay Informed

  Other Projects

  Useful Links

  Table of Contents

  Related Topics

  Источник