[virtualritz]

> There’s no shortage of package management alternatives available for Python [...]

> How someone is meant to pick between these as a new developer is a mystery.

This.

Every time I get booked to look at some Python project hours are usually wasted initially figuring out what dependency mgmt solution was used how. And with what 'special sauce' the resp. developers deemed to be 'the right way' (or some library required because ... it just does)

As the author wrote: it seems common to omit the dependency setup in the Readme for Python projects.

I can understand why one would not mention this 'step' in a Rust or Node project but for Python it seems very much necessary.

[ilyt]

I outright look for alternatives for something when the search comes with something written in python; the well-accepted strategy for deploying Python seems to be "abandon all hope of deploying it yourself in a way where updating is easy and hope docker container someone did that dealt with this mess will be enough.

[Spivak]

Huh? What stack? Python and Ruby take the same (I think better) approach of being written web server agnostic which requires you do some packaging work with your preferred wsgi/asgi server but after that it’s like everything else. In your container, copy all your shit over, install deps, pass envs to talk to external services like postgres/redis, run migrations, run server. Updates are just build the container again with the new version and run it.

I’m too lazy for that so in my own stuff I embed the web server in the project itself and start it programmatically (same with the migrations) so there’s less setup.

If the issue is the Docker container then that’s not really much to do with Python but that pretty much all software is written with that deployment strategy in mind. Those single file no libc statically compiled binaries are that way to run on a from scratch container.

[ziml77]

I appreciate the tools that release a self-contained executable using something like PyInstaller. I don't have to worry about dependency issues and it runs without needing a whole Docker container.

[ploxiln]

python3 includes "venv". If you don't have an existing preference, use that.

   python3 -m venv ../my-venv-dir # wherever you like
   . ../my-venv-dir/bin/activate
   pip install whatever

you can close your terminal and "rm -r" the venv dir, and no trace will be left. (or you can just "deactivate" and use it again later)

[virtualritz]

I was talking about the situation where you have to work on an existing codebase not where you start a Python project by yourself.

[mshockwave]

The author mentioned venv in the article. Also I believe the parent comment is talking about the difficulties of choosing between different dependencies management solutions, venv among them, rather than the lack of (a good) one

[blandcoffee]

Why cause yourself difficulty by drifting towards optionality vs. using the ops suggestion and using venv?

This topic gets posted to HN far too often - I'm starting to think people are deliberately avoiding venv for some reason, because otherwise it's a perfectly capable system for package management.

[wheelerof4te]

Yeah, many people here are suggesting poetry.

First (and last) time I've tried it, it was a complicated mess when compared to

python3 -m venv <venv_name>

[ploxiln]

Yes the article mentioned venv. And the parent said it's hard to choose. But the choice is easy: just use the basic built-in one. (Until you have a reason to use something else.)

It's a good general philosophy for software engineering: don't add stuff without good reason. There really is the potential to add infinite stuff these days - "awesome tools" and "best practices", without end. Individually they can help with particular problems you may have, but together they make a mess, and distract focus from the particular purpose of your software.

[pbalau]

I feel mischievous

    python -m venv node_modules

[Spivak]

To me there’s no mystery. Just use pip and then when you hit a specific problem see if any existing tools solve it.

The game of, “blank project immediately needs 12 different tools I read about on a blog post” is silly.

[qbasic_forever]

The official python packaging documentation basically says, "here are 12 different tools that can do it, figure it out!" https://packaging.python.org/en/latest/tutorials/managing-de...

[hnfong]

>> While pip alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it’s a higher-level tool that simplifies dependency management for common use cases.

There are many, but it recommends one. I don't think any reasonable person will actually go out and try all 7(?) of them.

[Spivak]

Which is basically the same advice. If you don’t already know what you want start with pip and requirements.txt and when you hit pain points: wanting to soft lock transitive dependencies, automate venv setup for onboarding, locking packages by hash, package caching, bundling Python itself with your code, etc. then there’s probably a tool out there tailored to your use-case.

[wheelerof4te]

People are making it seem harder than necessary.

Just create a virtual environment and install your packages there.

Done.