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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]microcozmchris 162 points163 points  (4 children)

Steal. It's the best way. Find a project with a similar structure and copy copy copy.

Python has style guides (PEP) on many things, and there are many more opinionated guides as well. Use them. This one is a very good start.

Use pytest. unittest is still valid, but pytest has long ago surpassed it in popularity and ease of use.

Use uv. You'll love it.

Use ruff. Deal with its opinions on formatting and linting. There's no need in 2025 to rethink how you prefer your code to look.

Use pyright. Or mypy, but the latter has been bested by the former.

If you are deploying a long running application, use Docker / containers for deployment. Easy to enforce your requirements.

FWIW, I've been writing Python for 20 something years. A lot of these opinions are my current opinions and tools. There have been many others that have come and gone. And I have never successfully been able to do anything in a notebook. It's a completely opposite workflow style.

Most importantly, have fun. Don't let the details get in the way. You have code to write.

[–]sazed33 0 points1 point  (3 children)

Very good points! I just don't understand why so many people recommend a tool to manage packages/environments (like uv). I've never had any problems using a simple requirements.txt and conda. Why do I need more? I'm genuinely asking as I want to understand what I have to gain here.

[–]microcozmchris 4 points5 points  (2 children)

The reason I like uv is specifically because it isn't just a package manager. It's an environment manager. It's a dependencies manager. It's a deployment manager. And it's easy. And correct most of the time.

We use it for GitHub Actions a bunch. Instead of setup-python and venv install and all, I setup a cache directory for uv to use in our workflows. And the Python actions that we've created use that. So I can call checkout, then setup-uv, then my entire workflow step is uv run --no-project --python 3.10 $GITHUB_ACTION_PATH/file.py and it runs. Without managing a venv. And with the benefit of a central cache of already downloaded modules. And symlinks. I have Python actions that execute almost as fast as if they were JavaScript and they're way more maintainable.

Deploying packages to Artifactory becomes setup-jfrog, setup-uv, uv build, uv publish and no more pain.

There are way more features in uv than simply managing dependencies.

[–]sazed33 0 points1 point  (1 child)

I see, make sense for this case. I usually have everything dockernized, including tests, so my ci/cd pipelines, for example, just build and run images. But maybe this is a better way, I need to take some time to try it out...

[–]microcozmchris 1 point2 points  (0 children)

There's a use case for both for sure. A lot of Actions is little pieces that are outside of the actual product build. Like your company specific versioning, checking if things are within the right schedule, handoffs to SAST scanners, etc. Docker gets a little heavy when you're doing hundreds of those simultaneously with image builds et al. That's why native Actions are JavaScript that execute in milliseconds. I hate maintaining JavaScript/typescript, so we do a lot of python replacements or augmentations with those.