What pipenv needs more than anything is a proper back tracking dependency resolver. With that it would instantly become my package installer of choice for python.
Pipenv: promises a lot, delivers very little
41–50 of 229 posts
Re: Pipenv: promises a lot, delivers very little
#42Our organization uses four primary languages (Ruby, Python, JS and Elixir). The package management situation for Python is by far the weakest. We’ve been using Pipenv, but it is atrociously slow and flawed at dependency resolution. An alternative is extremely welcome, E.g. Poetry which was mentioned above.
I can't speak to elixir but Ruby seems reasonable, JavaScript is a total clusterfuck. Python is dead simple.
Re: Pipenv: promises a lot, delivers very little
#43Pipenv is a really interesting development for Python, and I'm glad that someone was working to improve dependency locking for Python. However, Kenneth abused his position with PyPA (and quickly bumped a what is a beta product to version 18) to imply Pipenv was more stable, more supported and more official than it really was. And worse still, for anyone saying "but ts open source, you get what you pay for", Kenneth a…
Sometimes, improvements don't happen in a straight line. There's been a lot of work on Pipenv over the the last 6 months, predominantly by Dan Ryan and Tzu-Ping Chung, and it's getting stronger and stronger with each release. If you've gone back to using pip I'd encourage you to give Pipenv another try. Introducing a lockfile is a big step forward for Python dependency management, and the team working on Pipenv are c…
Pipenv tries to upgrade all the versions of everything in your lockfile whenever you add a new package (not just dependencies of the package), and there's no way to disable this behavior. Right now. That's the tip of the iceberg.
Re: Pipenv: promises a lot, delivers very little
#44Pipenv is a really interesting development for Python, and I'm glad that someone was working to improve dependency locking for Python. However, Kenneth abused his position with PyPA (and quickly bumped a what is a beta product to version 18) to imply Pipenv was more stable, more supported and more official than it really was. And worse still, for anyone saying "but ts open source, you get what you pay for", Kenneth a…
Sometimes, improvements don't happen in a straight line. There's been a lot of work on Pipenv over the the last 6 months, predominantly by Dan Ryan and Tzu-Ping Chung, and it's getting stronger and stronger with each release. If you've gone back to using pip I'd encourage you to give Pipenv another try. Introducing a lockfile is a big step forward for Python dependency management, and the team working on Pipenv are c…
Pipenv is designed solely for packaging applications, per the maintainers' admission. It's not suited for libraries and is not designed to be. If you want to replace pip, you should have a look at Poetry.
Re: Pipenv: promises a lot, delivers very little
#45Earlier quoted context omitted.
Sometimes, improvements don't happen in a straight line. There's been a lot of work on Pipenv over the the last 6 months, predominantly by Dan Ryan and Tzu-Ping Chung, and it's getting stronger and stronger with each release. If you've gone back to using pip I'd encourage you to give Pipenv another try. Introducing a lockfile is a big step forward for Python dependency management, and the team working on Pipenv are c…
Pipenv tries to upgrade all the versions of everything in your lockfile whenever you add a new package (not just dependencies of the package), and there's no way to disable this behavior. Right now. That's the tip of the iceberg.
You might want to check out https://github.com/pypa/pipenv/pull/3304, which Dan is actively working on to solve that.
Re: Pipenv: promises a lot, delivers very little
#46I really like pipenv, but I understand these complaints, especially the time calculating the hashes for the locks. Why is it so much slower than npm!??! But pipenv sync, and pipenv --venv Have made my deployments much easier.
Re: Pipenv: promises a lot, delivers very little
#47Re: Pipenv: promises a lot, delivers very little
#48I've long freed myself from the exhausting pipenv/virtualenv/pienv/conda rat-race by using docker. The only downside is some annoying IDEs refuse to acknowledge the existence of interpreter in a container.
Why is it a rat race? I've been using pyenv+virtualenv to isolate project environments for years now and it works just fine.
Re: Pipenv: promises a lot, delivers very little
#49I've long freed myself from the exhausting pipenv/virtualenv/pienv/conda rat-race by using docker. The only downside is some annoying IDEs refuse to acknowledge the existence of interpreter in a container.
can you get VSC code completion to use a python interpreter in a Docker container?
Re: Pipenv: promises a lot, delivers very little
#50Earlier quoted context omitted.
Sometimes, improvements don't happen in a straight line. There's been a lot of work on Pipenv over the the last 6 months, predominantly by Dan Ryan and Tzu-Ping Chung, and it's getting stronger and stronger with each release. If you've gone back to using pip I'd encourage you to give Pipenv another try. Introducing a lockfile is a big step forward for Python dependency management, and the team working on Pipenv are c…
Pipenv is designed solely for packaging applications, per the maintainers' admission. It's not suited for libraries and is not designed to be. If you want to replace pip, you should have a look at Poetry.
> It's not suited for libraries and is not designed to be.
That's kind of the problem. Why on earth are libraries and apps getting a different treatment? The JS ecosystem manages to have one tool for apps and libraries. One too for installing and publishing. All of it with lockfile support, workspace/"virtualenv" support, etc. And somehow, it's not confusing.
Adding one more tool to the stack is a really funky step forward. Yes, it brings lockfiles. Cool, although we already kind of had those (--freeze). Packaging in Python is a mess and I'm more and more in the camp that as long as Pipenv keeps flouting itself as "the better solution", all the while not covering all the basic use cases, we've gone backwards and are in even more of a mess.