Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pipenv: Promises a Lot, Delivers Little (2020)

chriswarrick.com

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#31

Post by bamboozled »

greut wrote: post #2

It's a bit of an old post, and yes Pipenv is not the go-to tool anymore. pip-tools is okay for people that really, really love their requirements.txt; otherwise we tend to go with Poetry at work. Any folks having a good experience with PDM https://github.com/pdm-project/pdm ?

PDM is based on PEP-582, which is only a draft and you will hit edge cases where it's not supported, or projects refuse to support it because of this. I'd avoid it for that reason personally.

virtualenvs are a much more supported.

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#32

Post by bamboozled »

gooseyard wrote: post #20
greut wrote: post #2

It's a bit of an old post, and yes Pipenv is not the go-to tool anymore. pip-tools is okay for people that really, really love their requirements.txt; otherwise we tend to go with Poetry at work. Any folks having a good experience with PDM https://github.com/pdm-project/pdm ?

After a series of bad experiences with Poetry, I switched the packages I maintain to PDM. Although I have hit a few minor snags, the maintainer and other users in the project's github discussions have never failed to help with a fix, workaround, or advice. It's pleasant to use, and I think the only feature I cared about which was in Poetry but not PDM (a publish-to-pypi command), has proven easier to do with the Twin…

See my above comment, something to be aware of.

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#33

Post by bamboozled »

strbean wrote: post #6
greut wrote: post #2

It's a bit of an old post, and yes Pipenv is not the go-to tool anymore. pip-tools is okay for people that really, really love their requirements.txt; otherwise we tend to go with Poetry at work. Any folks having a good experience with PDM https://github.com/pdm-project/pdm ?

How is the maturity/stability of Poetry these days? I despise Pipenv, and was hoping to push for a switch to Poetry at my place of work a couple years ago, but I ran into blocking bugs across multiple versions (latest N versions affected by bug A, prior M versions affected by bug B). Had to chock it up to "not yet mature enough" and resign myself to the absurd lock times and countless terrible behaviors of Pipenv.

Seems very good, except they do seem to have some long running per-releases going which seems troubling. Just ship it already!

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#34

Post by nickjj »

traverseda wrote: post #17
throwaway234232 wrote: post #15

Earlier quoted context omitted.

You don't need virtual environments when using npm or composer or cargo. They also create lock files with hashes by default. pip still doesn't use lock files. It's subpar compared to other ecosystems.

I worry that the inclusion of lockfiles will make semver less relevant. You shouldn't need to use lock files if you're using semver properly. If your ecosystem is healthy than pinning exact versions with lock files shouldn't be done. Making it so that every dev uses the latest patch or minor when they run your program. Using lock files for libraries should absolutely never happen, you should at most fix your dependen…

> You shouldn't need to use lock files if you're using semver properly.

I think this issue is unrelated to semver.

I've had so many issues over the years with Python packages, even very polished libraries like Flask and Celery.

For example, you could install something like Flask 2.0 but end up with a major difference in versions of its sub-dependencies depending on when you installed it.

That's because Flask has its own dependencies defined like this:

        "Werkzeug >= 2.2.0a1",
        "Jinja2 >= 3.0",
        "itsdangerous >= 2.0",
        "click >= 8.0",
The above means installing Flask 2.0 could one day in the future install Jinja 4 or Click 10 unless you lock your entire dependency tree.

I've also had all sorts of things break because Flask installed Jinja 3.1 which wasn't a problem 6 months ago when Jinja 3.0 was the latest release. I've also had cases where installing a specific version of Celery in the past worked but failed in the future because it didn't lock one of its sub-dependencies down well enough (vine) which caused a breaking change.

This stuff happens all the time and it's a nuisance. I never experienced issues like this with Ruby and other languages that have the idea of a lock file built into their package manager. IMO it's a desperately needed feature that should be built into pip.

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#35

Post by raverbashing »

drekipus wrote: post #5

I'm really sorry, but I can never quite understand what the deal is with these tools are. I understand that virtual environments are important, but how are these tools any better than python3 -m venv .venv --prompt="foobar" . .venv/bin/activate pip install -r requirements.txt ? Whenever I see all these other tools I just get the feeling like there's some big elephant in the room that everyone is battling against, but…

I think the same

Some tools, like poetry do add value to your development process (namely, better management of dependencies)

pipenv really does sound like something for people that are too lazy to activate their envs before running stuff

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#36

Post by plonk »

pen2l wrote: post #28
DanielVZ wrote: post #24

Earlier quoted context omitted.

First of all some years ago pip wasn't really solving dependencies. Then even with the new dependency resolving improvements it's way worse than poetry's in my experience. Also the requirements.txt file tends to get cluttered with non top level dependencies that make upgrading your dependencies an herculean task. Instead on poetry you define your top level dependencies in your pyproject.toml and all the actual pinned…

Are you guys actually using either poetry or venv on production? Separately, I'm curious to hear examples of where dependency-clutter actually caused a problem.

Venv, yes. My Dockerfile's build stage creates a venv and installs all our dependencies (some of which need compilers because they are source wheels that need to link with C++ libraries). Then I copy the venv over to the release stage and install only the release dependencies.

Maybe that could work with a `pip --user` install, but at least the venv guarantees that all Python packages and data will be in one self-contained folder.

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#37

Post by gh02t »

wodenokoto wrote: post #10

Is there a reliable source that tells what the current recommended way of doing this in Python is? I’ve been using Anaconda and been finding that it install incompatible versions of jupyter and ipython dependencies and that a lot of tools I need only work from pip, so I’ve been wondering if maybe I should just switch to the “pythonic way of doing it” and have absolutely no idea what that is.

Slight digression, but I'm always baffled by how unbelievably slow Conda is at resolving dependencies as soon as you have more than a handful of packages installed. Mamba basically proves it's a solvable issue, but you'd think the Anaconda folks would be prioritizing it.

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#38

Post by akvadrako »

donarb wrote: post #29

I've started to get away from virtual environments and just use Docker containers where all the pip dependencies can live as first class citizens. Also eliminates having to source the activate file or wonder if I'm calling the correct version of Python when I want to ssh in and run some code by hand in the container.

Containers are basically language agnostic virtual environments done right. Having python or js specific solutions is really a hack.

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#39

Post by plonk »

mirashii wrote: post #23
traverseda wrote: post #19

Earlier quoted context omitted.

That's a feature, you should be using the latest minor/patch release when developing. If you really need to lock a dependency to a specific version it is possible, but you shouldn't be doing it. If a dependency is constantly breaking on minor/patch releases you shouldn't be using it. I think it's a lot of javascript developers who end up having this problem, and all I can say is that the python package ecosystem is n…

I really couldn’t disagree with this more. Reproducibility is far more important than integrating unknown bug fixes, and upgrading dependencies should be a manual process during which you review the changes and verify that they don’t break your system. My time and the time of my peers is too valuable to be debugging minor incompatibilities between a library 5 layers down the transitive dependency stack because versio…

> My time and the time of my peers is too valuable to be debugging minor incompatibilities between a library 5 layers down the transitive dependency stack because versions aren’t pinned. It’s too important that if I go back to a 3 year old checkout of the code that it still runs and isn’t a wild goose chase of running down bugs and library incompatibilities.

That happens very rarely with our dozens of transitive dependencies. What are these packages that cause trouble often?

Re: Pipenv: Promises a Lot, Delivers Little (2020)

#40

Post by js2 »

(May 2020) so this piece is out of date.

I use pipenv on one of my projects, including (in combination with direnv) for setting up my local dev environment on macOS and as part of CI/CD for deploying into a Docker container based on one of the Python images. The project doesn't have a huge number of dependencies, but pipenv has worked well. The only time I fought with it was over its PyUp safety checks, but "pipenv check" is opt-in anyway.

For most of my other projects, I install from either a setup.py or requirements file using pip, often driven by a Makefile. Again, deploying into Linux, but using macOS for local development, again with direnv.

In 20 years of professional Python development on mostly small-to-medium size projects, I've never had any issues I can recall getting packages installed.

Conversely, I semi-regularly fight with cocoapods, npm and gems.

Post reply on HN