快来测试 Python 开发工具 pipenv 的新版本
Python pipenv
![](/data/attachment/album/202008/22/104612gfgllhf85mahvm3j.jpg)


[pipenv](https://github.com/pypa/pipenv) 是一个可帮助 Python 开发人员维护具有特定一组依赖关系的隔离虚拟环境，以实现可重新复制的开发和部署环境的工具。它类似于其他编程语言中的工具如 bundler、composer、npm、cargo、yarn 等。


最近发布了新版本的 pipenv 2020.6.2。现在可以在 Fedora 33 和 Rawhide 中使用它。对于较旧的 Fedora，维护人员决定打包到 [COPR](https://copr.fedorainfracloud.org/coprs/g/python/pipenv/) 中来先进行测试。所以在他们把它推送到稳定的Fedora版本之前，来试试吧。新版本没有带来任何新颖的功能，但是经过两年的开发，它解决了许多问题，并且在底层做了很多不同的事情。之前可以正常工作的应该可以继续工作，但是可能会略有不同。


### 如何获取


如果你已经在运行 Fedora 33 或 Rawhide，请运行 `$ sudo dnf upgrade pipenv` 或者 `$ sudo dnf install pipenv`，你将获得新版本。


在 Fedora 31 或 Fedora 32 上，你需要使用 [copr 仓库](https://copr.fedorainfracloud.org/coprs/g/python/pipenv/)，直到经过测试的包出现在官方仓库中为止。要启用仓库，请运行：



```
$ sudo dnf copr enable @python/pipenv

```

然后将 `pipenv` 升级到新版本，运行：



```
$ sudo dnf upgrade pipenv

```

或者，如果尚未安装，请通过以下方式安装：



```
$ sudo dnf install pipenv

```

如果你需要回滚到官方维护的版本，可以运行：



```
$ sudo dnf copr disable @python/pipenv
$ sudo dnf distro-sync pipenv

```

*COPR 不受 Fedora 基础架构的官方支持。使用软件包需要你自担风险。*


### 如何使用


如果你有用旧版本 `pipenv` 管理的项目，你应该可以毫无问题地使用新版本。如果有问题请让我们知道。


如果你还不熟悉 `pipenv` 或想开始一个新项目，请参考以下快速指南：


创建一个工作目录：



```
$ mkdir new-project && cd new-project

```

使用 Python 3 初始化 `pipenv`：



```
$ pipenv --three

```

安装所需的软件包，例如：



```
$ pipenv install six

```

生成 `Pipfile.lock` 文件：



```
$ pipenv lock

```

现在，你可以将创建的 `Pipfile` 和 `Pipfile.lock` 文件提交到版本控制系统（例如 git）中，其他人可以在克隆的仓库中使用此命令来获得相同的环境：



```
$ pipenv install

```

有关更多示例，请参见 [pipenv 的文档](https://pipenv.pypa.io/en/latest/install/)。


### 如何报告问题


如果你使用新版本的 `pipenv` 遇到任何问题，请[在 Fedora 的 Bugzilla中 报告问题](https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pipenv)。Fedora 官方仓库和 copr 仓库中 `pipenv` 软件包的维护者是相同的人。请在报告中指出是新版本。




---


via: <https://fedoramagazine.org/come-test-a-new-release-of-pipenv-the-python-development-tool/>


作者：[torsava](https://fedoramagazine.org/author/torsava/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
** Pipenv** is a tool that helps Python developers maintain isolated virtual environments with specifacally defined set of dependencies to achieve reproducible development and deployment environments. It is similar to tools for different programming languages, such as bundler, composer, npm, cargo, yarn, etc.

A new version of pipenv, 2020.6.2, has been recently released. It is now available in Fedora 33 and rawhide. For older Fedoras, the maintainers decided to package it in [COPR](https://copr.fedorainfracloud.org/coprs/g/python/pipenv/) to be tested first. So come try it out, before they push it into stable Fedora versions. The new version doesn’t bring any fancy new features, but after two years of development it fixes a lot of problems and does many things differently under the hood. What worked for you previously should continue to work, but might behave slightly differently.

## How to get it

If you are already running Fedora 33 or rawhide, run *$ sudo dnf upgrade pipenv* or *$ sudo dnf install pipenv* and you’ll get the new version.

On Fedora 31 or Fedora 32, you’ll need to use a [copr repository](https://copr.fedorainfracloud.org/coprs/g/python/pipenv/) until such time comes that the tested package will be updated in the official place. To enable the repository, run:

$ sudo dnf copr enable @python/pipenv

Then to upgrade pipenv to the new version, run:

$ sudo dnf upgrade pipenv

Or, if you haven’t installed it yet, install it via:

$ sudo dnf install pipenv

In case you ever need to roll back to the officially maintained version, you can run:

$ sudo dnf copr disable @python/pipenv

$ sudo dnf distro-sync pipenv

*COPR is not officially supported by Fedora infrastructure. Use packages at your own risk.*

## How to use it

If you already have projects managed by the older version of pipenv, you should be able to use the new version in its place without issues. Let us know if something breaks.

If you are not yet familiar with pipenv or want to start a new project, here is a quick guide:

Create a working directory:

$ mkdir new-project && cd new-project

Initialize pipenv with Python 3:

$ pipenv --three

Install the packages you want, e.g.:

$ pipenv install six

Generate a Pipfile.lock file:

$ pipenv lock

Now you can commit the created Pipfile and Pipfile.lock files into your version control system (e.g. git) and others can use this command in the cloned repository to get the same environment:

$ pipenv install

See [pipenv’s documentation](https://pipenv.pypa.io/en/latest/install/) for more examples.

## How to report problems

If you encounter any problems with the new pipenv version, please [report any issues in Fedora’s Bugzilla](https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pipenv). The maintainers of the pipenv package in official Fedora repositories and in the copr repository are the same. Please indicate in the text that the report is regarding this new version.

## Artur

The eternal war: pipenv vs virtualenv

## PatM

Hello! FWIW I enjoy using pyenv in conjunction with the pyenv-virtualenv plugin… since I can granularly control both python version and virtualenv from a single interface… https://fijiaaron.wordpress.com/2015/06/18/using-pyenv-with-virtualenv-and-pip-cheat-sheet/

## batisteo

For me it’s virtualenv vs Poetry.

pipenv is totally out of the equation, it’s very bad, buggy and miss a lot a convenient features.

## BigD

And also:

with a pip requirements file.

## DMH

Isn’t it risky to have people install Python packages with dnf instead of using

or

? Life is easier when you use pip for all things Python except the interpreter itself, in my experience. (Using pipenv when you want dependency-managed virtual environments, of course.)

## sloshy

It’s only risky if you do system-wide installs using pip. The problem with using pip exclusively for system wide python modules is that it isn’t really feasible, because an unrelated package might pull a python module as a dependency, so you can’t really avoid installing python modules from dnf, unless you completely avoid anything written in python. That’s why IMO you should install system wide utilities (like jupyter) with dnf even though you can use pip, and use pip install –user or a virtual environment for anything else. I don’t think you’ll run into conflicts using pip install –user, because it lives in your home directory.

## FeRD (Frank Dana)

nodWhat Sloshy said. Usingpipin the system directory is actually themorerisky proposition, because it risks trampling on what DNF is already doing in there.Basically, as long as you

neverrunpipwithsudo(so, IOW, you never let it mess around in/usr/{lib,lib64}/python3.x/site-packages/), then you’ll be OK. DNF will manage all of the system site-packages contents, and you can usepipto manage either/both of your$HOME/.local/lib/python3.x/site-packages/and whatever’s installed into any virtualenvs you create.## Miro Hrončok

Note that 2020.8.13 got out recently and we plan to update the packages in Fedora 33+ as well as in the copr repo to that version soon.

## Weverton

I’ve using poetry for a while and I don’t miss pipenv…

## Svetlozar Argirov

Yeah, pipenv is really terrible. Easily one of the worst package managers I’ve used.

## Géraud

That’s a very harsh judgment. Why would you recommend against pipenv?

## Sergey

https://github.com/pipxproject/pipx

## Sergey

It’s my personal opinion that after containerization all these things have lost their meaning. In Fedora, they even went from collections to modules.

## FeRD (Frank Dana)

Well… I mean, virtualenvs aren’t just for production, they’re also useful when setting up development environments. Or do you suggest even doing development work (or at least development testing/debugging) from within shells running inside container images as well?

(I’m honestly asking, I’d never even really considered that, so I have no immediate position on it one way or the other.)

## Bart

Containerization does not solve dependency resolution for Python.

## FeRD (Frank Dana)

@Bart

From what people are saying, neither does pipenv, really.

But I think Sergey was holding up containerization as a substitute for Python virtualenvs, which is definitely at least somewhat plausible. You’d still need to do dependency management within the container, of course, but you wouldn’t need that tool to do any of the venv-management tasks that have been rolled into so many tools like pipenv.

(Heck, there’s currently an open thread on the Python Discourse where someone is proposing that pip itself DEFAULT to installing packages into a virtualenv, and complain about attempts to use it outside of one.)

## Prediksi skor

I just now wanted to thank you one more time for this amazing web site you have produced here.

It’s full of useful tips for those who are seriously interested in this

kind of subject, primarily this very post. You’re really

all actually sweet plus thoughtful of others in addition to the fact that reading your website posts is an excellent delight if you ask me.

And that of a generous treat! Dan and I will certainly

have enjoyment making use of your suggestions in what we need to

do in the near future. Our listing is a kilometer long and simply put tips is going to be put

to beneficial use.

## Oshan Wisumperuma

https://github.com/python-poetry/poetry

## Bart

Pipenv is so slow and buggy that it is unusable.

Poetry is has a few bugs too but it’s fast and works most of the time.