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 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 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 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. 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)
nod What Sloshy said. Using pip in the system directory is actually the more risky proposition, because it risks trampling on what DNF is already doing in there.
Basically, as long as you never run pip with sudo (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 use pip to 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.