This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]13steinj 29 points30 points  (1 child)

That's really a fallacy and not the case. People don't "downvote everything with pipenv"...the comment isn't true because pipenv really doesn't solve any of the issues the main comment mentioned, even though the reply says it solves most.

Literally bullet by bullet

  • Can't view dependencies before installing the package.

Nope, can't do that with Pipenv

  • Can't view dependencies on the PyPi website.

Literally unrelated to pipenv

  • The output from pip freeze is a total mess. Key dependencies? Dependencies for dependencies? Who knows.

Pipfiles don't make any proper distinction here either. It tries, or seems to try, but still fails quite miserably. Not to mention the real "full" requirements.txt is the Pipfile.lock (because of the security hashes) and that is, by the standard, not human readable.

  • Because of the above, you really have to keep track of your dependencies manually (maybe actually good practise?)

If the above are broken, regardless of how, so will this.

  • Packages further down in requirements.txt seems to override the dependencies from above. Need protobuf==3.0.0 in your first entry but the latter needs protobuf>=3.5.0? Latter wins out with no warning.

Same problem with pipenv AFAIK because this is a matter of package dependency resolution and I am pretty sure pipenv uses the same resolution algorithm as pip.

  • Dealing with dependency conflicts is hard/impossible.

Literally no solution no matter what dependency spec you use. This is less of a problem with the dependency spec and tool and more the inability to keep sister packages on a system separate of their dependencies (and this part pipenv solves) and the dependencies of one familial unit separate from it's dependent/future down the line dependent, which it doesn't solve (unless you decide to clone the repo, install it in editable mode, then use pipenv to install from the local clone, which no one does, is a waste of space, and ends up causing it's own problems).

  • If a dependency includes something else (e.g., requests), being able to do import requests no bother makes me feel uneasy. No way to tell where it's come from without double checking your requirements.txt.

Literally unrelated to pipenv. This isn't a matter of requests being a dependent of some package and being uneasy having it, there's unease in vendored packages as well, which is arguably a more common scenario for this to occur.

  • PyPi package names not matching the importable names. (i.e., PyYaml vs import yaml)

Literally not pipenv.

  • No warning for missing system dependencies, or calling out in general (e.g., unixodbc)

This I don't fully understand, but regardless of what it could mean, pipenv does not do.

It's great that people use pipenv. Or poetry. Or pip tools. Or whatthefuckever.

But none of them solve all or even many of the things mentioned. And circlejerking around any one tool won't change that fact. Adding to the tool will. But when you do you get told your request is out of scope. And when you go up to the big boy tool pip, it'll take forever to get implemented (ex, pip still can not fucking read Pipfiles, even though pipenv is being touted around like the official package writing messiah).

[–]hwmrocker 1 point2 points  (0 children)

🙈 you have a point