5 ms·

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-Pin

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 committed and doing a great job.

devnonymous 8y ago
> Sometimes, improvements don't happen in a straight line. I don't think that the parent disagreed with that. The point, as I understood it, was that this beta stage improvement was marketed as being ready. IOW, if pipenv was not Kenneth's project, it likely would have evolved in, to use your phrase, a straighter line.
rendaw 8y ago
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.
- greysteil 8y ago
  You might want to check out https://github.com/pypa/pipenv/pull/3304 https://github.com/pypa/pipenv/pull/3304, which Dan is actively working on to solve that.
- cellularmitosis 8y ago
  Poor control over this sort of behavior makes Cocoapods very frustrating to deal with.
sprt 8y ago
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.
- scrollaway 8y ago
  > 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.
  - gizmo385 8y ago
    And it isn't only Javascript that manages to have a single tool for this. Clojure has a single tool. Java has a single tool. Rust has a single tool. This is a solved problem across a variety of popular and mainstream programming languages. I don't mean to suggest that the problem isn't complicated, but this isn't a problem that doesn't have a wealth of previously written solutions to look at for inspiration.
    - scrollaway 8y ago
      Right, exactly! It bugs me that we have a wealth of examples and could have just said: "Look. Here's yarn. Do that, but for Python. Don't try to be too creative." Poetry looks like it did just that though and I'm warming up to it at a very high speed.
    - bobbyi_settv 8y ago
      What's the "one tool" for Java? Is it Maven? Ivy? sbt? Gradle? You may say some of those are "build tools" rather than dependency tools, but I don't see how it's different than what we are discussing in Python. My Java app declares its dependencies in a build.sbt file using Scala syntax and has them cached in an Ivy directory. Yours declares them in a pom file using XML syntax and has them cached in a Maven directory. Neither of us even tries to do lockfiles and instead just has the CI server build an "uber jar" with all the dependencies bundled in.
legostormtroopr 8y ago
> Sometimes, improvements don't happen in a straight line. I don't deny that, what I am (and the article is) saying is that we were sold on Pipenv being "the officially recommended Python packaging tool from Python.org". And PyPA didn't refute it, and Heroku didn't refute it, so the community bought it. Yes, introducing a Lockfile is huge, and it was massively needed, and thats why when we were told "heres the official way to do it", we got excited. Then we got daily breaking updates, rude issue close messages, and a giant backtrack of "its free and still under development, why do you expect so much from us?"
- emptysea 8y ago
  Another reason Heroku didn't refute Pipenv is that Pipenv's creator leads Python related things at Heroku.
  - warmblanket 8y ago
    Not anymore, I don’t believe.
weberc2 8y ago
We’re giving it an honest try, but we still get burned regularly. I’m pretty disappointed.
circles_for-day 8y ago
I just switched away today. It still sucks
vmchale 8y ago
> Introducing a lockfile is a big step forward for Python dependency management Huh? I'm not really familiar with the state of dependency management for Python/dynamic languages but... there's much more out there beyond just lockfiles. I'm a bit appalled Python is so far behind.
- IvanAnishchuk 8y ago
  Much more for what? In this context, "lockfile" means a file listing all your project dependencies with exact versions pinned. (Not semaphore-files or anything like that. It's not even a python-specific term, e.g. npm uses package-lock.json for the same purpose.) The need for something to store all dependencies with exact versions pinned exists in any language and infrastructure, are there any better solutions than store them in a file? Files are nice, they are VCS-friendly and everything.
  - vmchale 8y ago
    > Much more for what? Much more in the field of build tooling/package management. Pinning versions is fine, but dependency resolution is another legitimate choice.
GauntletWizard 8y ago
I already managed my python deps with a lockfile - requirements.txt and requirements-frozen.txt, which about three lines of shell script took care of for me. From the article, it doesn't sound like pipenv buys me much on top of that.
- pas 8y ago
  It's a "standard" way to do those scripts. It gives you the NodeJS + NPM way's "npm i", by creating a virtualenv and pip installing into it. It helps with specifying prod and dev dependencies too - if I remember correctly.

devnonymous 8y ago

> Sometimes, improvements don't happen in a straight line. I don't think that the parent disagreed with that. The point, as I understood it, was that this beta stage improvement was marketed as being ready. IOW, if pipenv was not Kenneth's project, it likely would have evolved in, to use your phrase, a straighter line.

rendaw 8y ago

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.

greysteil 8y ago
You might want to check out https://github.com/pypa/pipenv/pull/3304 https://github.com/pypa/pipenv/pull/3304, which Dan is actively working on to solve that.
cellularmitosis 8y ago
Poor control over this sort of behavior makes Cocoapods very frustrating to deal with.

sprt 8y ago

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.

scrollaway 8y ago
> 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.
- gizmo385 8y ago
  And it isn't only Javascript that manages to have a single tool for this. Clojure has a single tool. Java has a single tool. Rust has a single tool. This is a solved problem across a variety of popular and mainstream programming languages. I don't mean to suggest that the problem isn't complicated, but this isn't a problem that doesn't have a wealth of previously written solutions to look at for inspiration.
  - scrollaway 8y ago
    Right, exactly! It bugs me that we have a wealth of examples and could have just said: "Look. Here's yarn. Do that, but for Python. Don't try to be too creative." Poetry looks like it did just that though and I'm warming up to it at a very high speed.
  - bobbyi_settv 8y ago
    What's the "one tool" for Java? Is it Maven? Ivy? sbt? Gradle? You may say some of those are "build tools" rather than dependency tools, but I don't see how it's different than what we are discussing in Python. My Java app declares its dependencies in a build.sbt file using Scala syntax and has them cached in an Ivy directory. Yours declares them in a pom file using XML syntax and has them cached in a Maven directory. Neither of us even tries to do lockfiles and instead just has the CI server build an "uber jar" with all the dependencies bundled in.

legostormtroopr 8y ago

> Sometimes, improvements don't happen in a straight line. I don't deny that, what I am (and the article is) saying is that we were sold on Pipenv being "the officially recommended Python packaging tool from Python.org". And PyPA didn't refute it, and Heroku didn't refute it, so the community bought it. Yes, introducing a Lockfile is huge, and it was massively needed, and thats why when we were told "heres the official way to do it", we got excited. Then we got daily breaking updates, rude issue close messages, and a giant backtrack of "its free and still under development, why do you expect so much from us?"

emptysea 8y ago
Another reason Heroku didn't refute Pipenv is that Pipenv's creator leads Python related things at Heroku.
- warmblanket 8y ago
  Not anymore, I don’t believe.

weberc2 8y ago

We’re giving it an honest try, but we still get burned regularly. I’m pretty disappointed.

circles_for-day 8y ago

I just switched away today. It still sucks

vmchale 8y ago

> Introducing a lockfile is a big step forward for Python dependency management Huh? I'm not really familiar with the state of dependency management for Python/dynamic languages but... there's much more out there beyond just lockfiles. I'm a bit appalled Python is so far behind.

IvanAnishchuk 8y ago
Much more for what? In this context, "lockfile" means a file listing all your project dependencies with exact versions pinned. (Not semaphore-files or anything like that. It's not even a python-specific term, e.g. npm uses package-lock.json for the same purpose.) The need for something to store all dependencies with exact versions pinned exists in any language and infrastructure, are there any better solutions than store them in a file? Files are nice, they are VCS-friendly and everything.
- vmchale 8y ago
  > Much more for what? Much more in the field of build tooling/package management. Pinning versions is fine, but dependency resolution is another legitimate choice.

GauntletWizard 8y ago

I already managed my python deps with a lockfile - requirements.txt and requirements-frozen.txt, which about three lines of shell script took care of for me. From the article, it doesn't sound like pipenv buys me much on top of that.

pas 8y ago
It's a "standard" way to do those scripts. It gives you the NodeJS + NPM way's "npm i", by creating a virtualenv and pip installing into it. It helps with specifying prod and dev dependencies too - if I remember correctly.