Having more than one obvious way is unpythonic
Python
Welcome to the Python community on the programming.dev Lemmy instance!
π Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django π¬)
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
π Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
π Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
β¨ Python Ecosystem:
π Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- PythΓΆrhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API
Feeds
Unfortunately, pip, the obvious way, kind of sucks. So I use poetry, which seems to work nicely.
I'm using Poetry as well. But I really hope Rye works out so we can finally end this madness.
Interesting. I just learned about Rye today. Has anybody tried it? Does it live up to the promise?
Haven't tried Rye but I have used uv
(which Rye uses to replace pip). Pip install time went down from 58s to 7s. Yes really. Python is fucking slow!
I tried it a little - being able to run rye sync
and not even having to worry about Python versioning is sooooo nice.
Check "uv". Builds on top, is coming good.
I don't know what the solution is but like 50% of everything on github that's in python is broken from dependencies and of those, half of them are fixable if you put a substantial amount of effort into it. It sucks. I've spent 2 entire days trying to get any AI tts to work and have gotten nowhere. I've tried 'em all, just about. None of them work on Debian.
... except for the part where the dependency definition doesn't follow the latest approved PEP, and the default constraint with ^ add an upper limit that causes problems.
I moved to PDM.
Eh, by the time I get everyone on board and convert all of our repos, poetry will probably have support for the latest PEP.
Given the glacial pace I've been seeing, I would't be so sure... But understandable if you have many repos and need to reach consensus.
You can reduce some impacts adding explicit >= constraints instead of ^.
The thing is, things are working reasonably well right now, so updating to be in sync with the latest PEP isn't super impactful, whereas switching from requirements.txt -> poetry and pyproject.toml was a big change. So we'll probably switch eventually, but since we have over a dozen repos and several teams across timezones, it isn't a priority.
I'll certainly take a look though.
Wait, whatβs wrong with pip?
(Disclaimer: I grade my Python proficiency slightly above beginner. I used it for some research in college and grad school, and Iβve made a few helpful scripts at work, but I am not anything approaching an expert)
It does its job well, but it doesn't do much more than that.
The main workflow w/ Pip is:
- install whatever you need to get your app working
pip freeze > requirements.txt
so the next person can justpip install -r requirements.txt
instead of figuring out the requirements- either edit
requirements.txt
manually to do updates, orpip freeze
again later
There are some issues with this:
- dependencies that are no longer needed tend to stick around since they're in the requirements.txt
- updating dependencies is a manual process and pretty annoying, especially when different packages have different dependencies
- requirements.txt doesn't have any structure, so to do something like separating dev vs prod dependencies, you need two (or more) requirements.txt files
It's totally fine for one-off scripts and whatnot, but it gets pretty annoying when working across multiple repositories on a larger project (i.e. what I do at work with microservices).
Poetry improves this in a few ways:
- poetry.lock - similar to requirements.txt, in that it locks all dependencies to specific versions
- pyproject.toml - lists only your direct dependencies and certain exceptions (i.e. if you want to force a specific dependency version)
- package groups - we tend to have local (linters and whatnot), test (deps for unit tests), and the default group (prod deps), so you can install only what you need (e.g. our CI uses test, prod uses no groups, and local uses everything)
There's a simple command to update all dependencies, and another command to try to add a dependency with minimal impact. It makes doing package updates a lot nicer, and I can easily compare direct dependencies between repositories since there's minimal noise in the pyproject.toml (great when doing bulk updates of some critical dependency).
TL;DR - pip is fine for small projects, alternatives are nice when dealing with large, complex projects because it gives you nicer control over dependencies.
Good to know, thank you for educating me!
and Conda takes 20 minutes to do anything these days... π send help
Mamba is much faster!
Might want to look at Pixi - written in Rust, BTW, but effectively seems to be a drop-in replacement that's at least faster than Conda.
edit: link: https://prefix.dev/
This article is an excellent update on the state of Python package management tools.
I agree, although it undersells hatch and has a title that made me roll my eyes. Very well researched, none of the usual hot takes and clichΓ©s.
Iβve tried several and all of them left be disappointed eventually.
What did you end up using for your workflow?
Not OP. I ended up using hatch to make packages because itβs simple and does everything without feeling like a jumbled mess of tools like Poetry. It feels unix-like and didnβt prevent from doing my job.
Hatch is great. It's easy to get started but I wouldn't call it simple. Flit is simple, because it's limited.
Hatch is complex enough to allow you to override everything, which makes it not simple, but also not complicated.
I landed on hatch. The way it handles venvs and python versioning is awesome, and can also use UV. I haven't used UV yet tho.
Unfortunately, PEP 582 was rejected, so PDM has deprecated the functionality. But it does support PEP 621, which can't be said for Poetry. There's a PR.
Poetry's compatibility with PEP 621 is underway, but it'll likely be delayed to version 2.
Poetry provides a lot of the same functionality for quite some time now, which complicates the quick adoption, but it'll happen.
and it used to be worse (at the time that XKCD was published)
That means it's improving! I hope the pace of improvement can accelerate.
I just pip in a venv
I would love similar movement with regards to doc comment standards. My company uses numpy and its too verbose, and the style guide makes zero mention of type hints so we keep winging it. And with not many tools for enforcing the standards (like what type to actual write for a parameter) its an ongoing battle among the team.
I'd rather have too many options than the bullshit situation C/C++ has and has had for decades. Open any C++ project and try to get all the dependencies easily using the standard tooling. It'll vary on every distro and OS.
By the creator of Flask and many other things
It comes with built-in ruff
and uv
, and can handle Python versioning for you!
Not sure if they want to eventually dissolve Rye
into uv
or what, but for now it's one of the best (better than Poetry, IMO)
edit: it also uses the pypoetry.toml standard, something Poetry doesn't (because Poetry predates pyproject.toml becoming a standard).
One possible downside: I've heard Rye doesn't honor XDG, which means it has its own location for its config. I don't mind, but perhaps you do.
A second possible downside is that Rye doesn't let you centralize your venvs, so each .venv
goes into each project folder, so no using virtualenvwrapper
with workon
to jump between projects. zoxide can alleviate that problem, or presuming you have a ~/dev
folder or similar, you could write a bash function that ls
' that folder and lets you select a folder via fzf
? Go ask ChatGPT about it or something.
edit2: link: https://rye.astral.sh/guide/installation/
Pip-tools!
You can use uv now and have Rust speeds for the same functionality.
Interesting. I might have a look. Actually I don't have a problem with speed though. I spend most time not dealing with pip and pip-tools but reading docs, programming and fixing the weirdest bugs
I'm hoping uv is able to make itself to Python what Cargo is to rust.
Seems like Pixi is close but confined to the Conda ecosystem.
@chaospatterns "Fingers crossed, though, I hope uv takes off and the Python community can one day coalesce around a single standardized tool!"
This!
.. and every one of them destroys single source of truth for installed state. Most of them have no validation potential, and most of them are imperfect upgrades/downgrades.
If you don't know why all that's important, just remember why fired all our mentor types 20 years ago after the Y2K bust and so you had noone to teach you why. Mistakes like lennart's Cancer didn't grow in the light of rich knowledge sharing.