@@CarberraI tested Rye this week and it seems to be a good replacement for pyenv, pipx, poetry, etc And it's an actual executable so you don't need python to install it
I looked it up after someone else commented about it, and it honestly seems really good! Will have to give it a try, though I'm wary about it conflicting with Pyenv in some way. I'm not sure it would but we use Pyenv at work and would rather it not interfere.
@knolljo Well, this Rye could be the answer if it's as good as people say. I think it still uses venvs under the hood but honestly Pyenv has been good to me and that abstracts it all away from you.
We may argue whether the syntax is more or less convenient for this and that, but having a unified way of managing dependencies which can be improved over time is going to be a big win for use Pythoneers.
That is not why people use poetry. This is like saying pip will have a cleaner `--version` switch, which is wonderful, but not like a reason for changing anything, to use a bad metaphor. Early pip used to let every project uninstall the dependencies of deps installed just seconds ago, leading to nondeterministic venv creation. That led to both pipenv, poetry, which have incredibly complex solver and lock file creation algos. Pip has been playing catchup and the PEPs, which are well meaning, are going off in some other random direction to ensure that the landscape remains balkanized for at least another decade.
I honestly don't get all the fuss about package managers, I do use pipenv to simplify vertualenv management (yes I am lazy), the lock files and the rest of the stuff are just an extra. How many packages do you people have to use in project?
I love the simplicity of conda. A more modern version like pixi seems awesome, its not feature complete yet. But I love that its a single binary and can manage other languages as well. Its also great thag it can now somewhat manage pypi packages not just conda packages. I also really love the ability to install global packages. I really dont like Python project managers that rely on python to work. Poetry for example needs soooooooooooooooooo many libraries.
Let‘s hope they include syntax for environment markers. Otherwise this will just be garbage again for any project, which should be developed on multiple platforms. I want proper lock files with hashes and environment markers. I’m going insane otherwise.
I wonder how this differs from poetry. I've been using poetry over the last year, and it pretty much handles all these cases, including dependency groups (you can create arbitrary groups), editable install, and it handles them well. I guess poetry in the past only had "dev" dependencies, but this was in an older version. I know that because it shows that this command is deprecated. To be honest though, in my experience for some packages, the dependency resolver can be a bit slow with specific packages, like apache beam.
Poetry's implementation of dependency groups is pretty horrible in my opinion, definitely feels bolted on. This PEP feels a lot less arbitrary, though that's probably down to personal opinion rather than objective fact.
Not sure about the include syntax. You can already do this with the “extras” syntax. If your project.name is “analytics-workspace”, you can define project.optional-dependencies.docs and include it from project.optional-dependencies.dev with “analytics-workspace[docs]”, as though it were a published package. I guess the include is there because these specifically aren’t published, but it seems a little silly. Also, AFAIK pdm and poetry and everyone else in every other language tool chain calls these “dev dependencies”. “Dependency groups” is what optional dependencies already do. So, this name seems easy for PEP authors and confusing for end users.
I think it's supposed to be an all-in-one solution to put everything under a single category, which I like tbf. I think Poetry uses both iirc -- they have their dev dependencies syntax, then a separate dependency groups syntax. Can't comment on other package managers though.
pip.pypa.io/en/stable/cli/pip_install/ for some more references. Note …[…,…] is viable as well. Can se the value of allowing {include=…}. But please keep to the current path with optional-dependencies imgs.xkcd.com/comics/standards_2x.png
I think they'll keep that standard for backwards compatibility. Or at least deprecated it, which will give you 2 years to swap if it's anything like Python version deprecation.
The python community still has no standard lockfile format, and the comments here suggesting more alternatives to poetry make me want to run away from Python as fast as I can. I've been pushing for Go and Rust at work and using have been using Go as much as possible for standalone applications/scripts where python would have been used otherwise. For the python packages I've had to write, I've been using protocols/duck typing and DI to avoid explicitly importing third party dependencies as much as possible, and I'm maximally conservative about the APIs I use to maximize the version ranges of the libraries that it may work with. That way, injecting a Pydantic model, a dbapi compliant connection object, or a callback that the user defines is something I let the user do, and I avoid the dependency mess as much as possible myself since I don't want to touch that ****.
Maybe this is the final nail in the coffin! I used Poetry for a while a few years ago but moved away from it cos it took them forever to support 3.10, and just never went back.
You could probably set up an alias of some sort if you were to pipe the output of the compile through xargs (maybe `| xargs -L1`? I'm trying to get better with it but still not sure what everything does).
This works but I've also spent entire work days trying to resolve dependency conflicts especially if you can't just replace the package with a package that doesn't cause the conflict
python packaging is still a mess, sometimes i wish python had something similar to cargo as a standard
Yeah same honestly. Poetry's probably the closest to that but it's a bit of a mess imo. Would be nice to have something as standard.
@@CarberraI tested Rye this week and it seems to be a good replacement for pyenv, pipx, poetry, etc
And it's an actual executable so you don't need python to install it
I didn’t enjoy using poetry either, I’m still thinking if python could have something better than venvs
I looked it up after someone else commented about it, and it honestly seems really good! Will have to give it a try, though I'm wary about it conflicting with Pyenv in some way. I'm not sure it would but we use Pyenv at work and would rather it not interfere.
@knolljo Well, this Rye could be the answer if it's as good as people say. I think it still uses venvs under the hood but honestly Pyenv has been good to me and that abstracts it all away from you.
We may argue whether the syntax is more or less convenient for this and that, but having a unified way of managing dependencies which can be improved over time is going to be a big win for use Pythoneers.
That is not why people use poetry. This is like saying pip will have a cleaner `--version` switch, which is wonderful, but not like a reason for changing anything, to use a bad metaphor. Early pip used to let every project uninstall the dependencies of deps installed just seconds ago, leading to nondeterministic venv creation. That led to both pipenv, poetry, which have incredibly complex solver and lock file creation algos. Pip has been playing catchup and the PEPs, which are well meaning, are going off in some other random direction to ensure that the landscape remains balkanized for at least another decade.
I honestly don't get all the fuss about package managers, I do use pipenv to simplify vertualenv management (yes I am lazy), the lock files and the rest of the stuff are just an extra. How many packages do you people have to use in project?
Thoughts on rye for package and python version management?
Having just looked it up, it actually looks really cool! Might have to give it a whirl.
I love the simplicity of conda. A more modern version like pixi seems awesome, its not feature complete yet. But I love that its a single binary and can manage other languages as well. Its also great thag it can now somewhat manage pypi packages not just conda packages. I also really love the ability to install global packages. I really dont like Python project managers that rely on python to work. Poetry for example needs soooooooooooooooooo many libraries.
Let‘s hope they include syntax for environment markers. Otherwise this will just be garbage again for any project, which should be developed on multiple platforms. I want proper lock files with hashes and environment markers. I’m going insane otherwise.
I wonder how this differs from poetry. I've been using poetry over the last year, and it pretty much handles all these cases, including dependency groups (you can create arbitrary groups), editable install, and it handles them well.
I guess poetry in the past only had "dev" dependencies, but this was in an older version. I know that because it shows that this command is deprecated.
To be honest though, in my experience for some packages, the dependency resolver can be a bit slow with specific packages, like apache beam.
As far as I can tell it's just cleaner. Back when I last used Poetry it only had required and dev, it's added groups since (imo somewhat messily).
@@Carberra Could you elaborate a bit on what you mean when you say 'cleaner'? No offence at all, just curious :)
Poetry's implementation of dependency groups is pretty horrible in my opinion, definitely feels bolted on. This PEP feels a lot less arbitrary, though that's probably down to personal opinion rather than objective fact.
I like these pep videos
Nice!!
Not sure about the include syntax. You can already do this with the “extras” syntax. If your project.name is “analytics-workspace”, you can define project.optional-dependencies.docs and include it from project.optional-dependencies.dev with “analytics-workspace[docs]”, as though it were a published package.
I guess the include is there because these specifically aren’t published, but it seems a little silly.
Also, AFAIK pdm and poetry and everyone else in every other language tool chain calls these “dev dependencies”. “Dependency groups” is what optional dependencies already do. So, this name seems easy for PEP authors and confusing for end users.
I think it's supposed to be an all-in-one solution to put everything under a single category, which I like tbf. I think Poetry uses both iirc -- they have their dev dependencies syntax, then a separate dependency groups syntax. Can't comment on other package managers though.
pip.pypa.io/en/stable/cli/pip_install/ for some more references. Note …[…,…] is viable as well.
Can se the value of allowing {include=…}. But please keep to the current path with optional-dependencies
imgs.xkcd.com/comics/standards_2x.png
I think they'll keep that standard for backwards compatibility. Or at least deprecated it, which will give you 2 years to swap if it's anything like Python version deprecation.
The python community still has no standard lockfile format, and the comments here suggesting more alternatives to poetry make me want to run away from Python as fast as I can. I've been pushing for Go and Rust at work and using have been using Go as much as possible for standalone applications/scripts where python would have been used otherwise.
For the python packages I've had to write, I've been using protocols/duck typing and DI to avoid explicitly importing third party dependencies as much as possible, and I'm maximally conservative about the APIs I use to maximize the version ranges of the libraries that it may work with. That way, injecting a Pydantic model, a dbapi compliant connection object, or a callback that the user defines is something I let the user do, and I avoid the dependency mess as much as possible myself since I don't want to touch that ****.
2024 but still using config files instead of code as config
setup.py is the predecessor to pyproject.toml, you can still use it but imo declarative configs are a bit less of a hassle
@@squishy-tomatothen create another dsl, lol
poetry has been going downhill for a while now
Maybe this is the final nail in the coffin! I used Poetry for a while a few years ago but moved away from it cos it took them forever to support 3.10, and just never went back.
from 00:00 all I hear is bla bla bla... man you need to work on how you sound.
Poetry just makes me swear, a lot. Good riddance, hopefully.
I'm trying out uv and have gotten this to work:
```toml
[project.optional-dependencies]
linting = ["jupyter-black"]
testing = ["tox"]
formatting = ["ruff"]
dev = ["sql_pg[linting]", "sql_pg[testing]", "sql_pg[formatting]"]
```
$ uv pip compile pyproject.toml --extra dev > requirements.txt
Soooooo nice!
The build-system I use is setuptools BTW.
You could probably set up an alias of some sort if you were to pipe the output of the compile through xargs (maybe `| xargs -L1`? I'm trying to get better with it but still not sure what everything does).
venv + requirements.txt 👍 simple and straight forward
This works but I've also spent entire work days trying to resolve dependency conflicts especially if you can't just replace the package with a package that doesn't cause the conflict
environment.yaml 😎
whats that?