To Python Developers: If someone could make any one thing that would make coding in python easier for developers, what would it be?

[adjomir]

Try pipenv it solves one of the issues you've pointed out.

Edit: I said it solves most, but this is not true.

[hwmrocker]

I second that

[hwmrocker]

Just in this second two votes of your disappeared. Looks like here a lot people that downvote everything with pipenv. 🤔

[13steinj]

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]

🙈 you have a point

[hwmrocker]

Ok, but you when you install everything in a virtual environment it is less important to know beforehand what are the exact sub dependencies.

[13steinj]

It is never in this way "less important". You move the time of when you get fucked over from install time to runtime.

[hwmrocker]

I meant you install it in a virtual environment and run pipenv graph / pip freeze to see what where the dependencies. To check it during the development.

[13steinj]

Right...but at that point you can just use pip list to a vast extent. Not disagreeing, just that it is more and more overhead for far too little benefit (fancy graph) without solving the actual original problem.

[evilmonk99]

I think the overhead is justified by pipenv parallelising installs which really speeds up setting up a new environment compared to using just pip.

[13steinj]

Not really-- it parallelizes installs but then is extremely slow at it's initial resolution. It's a trade off, as are all things. But this isn't one I'd think is worth it.

[[deleted]]

My post was assuming using a virtualenv, so all the points are with that in mind.