I will never use Python-poetry [video](youtube.com)
youtube.com
I will never use Python-poetry [video]
https://www.youtube.com/watch?v=Gr9o8MW_pb0
7 comments
Yes, pip + virtualenv is sufficient.
Poetry's 50 dependencies is a bit much. I also found it confusing how Poetry hides the Python dependencies path to somewhere outside of the project directory.
Poetry's 50 dependencies is a bit much. I also found it confusing how Poetry hides the Python dependencies path to somewhere outside of the project directory.
I haven’t encountered anything Poetry-related outside of my project directories. Maybe that’s because I have set `virtualenv.in-project` to `true` in my `poetry.toml`.
I like Poetry, it made my life easier.
The 5% of failure is odd... But whatever.
50 deps for a tool is really common, not ideal but no problem.
The 5% of failure is odd... But whatever.
50 deps for a tool is really common, not ideal but no problem.
Adding a random chance of failure for a deprecated feature, is pretty interesting decision!
I actually quite like the idea, personally.
I use Poetry at work and I thoroughly enjoy it.
I work primarily on applications so I think the default constraint of carets is good because my app's not going to break when a dependency is bumped a major version with breaking changes, and I don't care about 50 dependencies (because it's not shipped in our production Docker image, so meh).
A 5% brownout on installing is a great idea to the alternatives. I recently went on a dependency updating spree and also happened to update Poetry so already updated our build process and so didn't come across this brownout, but I think I'd prefer it. If it was a plain old print statement and continued to pass our builds I'd never read any deprecation message (my dev env is already setup and if I get green ticks in CI I don't view the logs), and if it was a 100% failure then I'm forced to upgrade it and modify the build process then and there. At least with a brown out I'll be temporarily annoyed, but see the deprecation and then set the temporary skip flag and then plan to make the change to the build process a short time later when sprint commitments allow...
I use Poetry at work and I thoroughly enjoy it.
I work primarily on applications so I think the default constraint of carets is good because my app's not going to break when a dependency is bumped a major version with breaking changes, and I don't care about 50 dependencies (because it's not shipped in our production Docker image, so meh).
A 5% brownout on installing is a great idea to the alternatives. I recently went on a dependency updating spree and also happened to update Poetry so already updated our build process and so didn't come across this brownout, but I think I'd prefer it. If it was a plain old print statement and continued to pass our builds I'd never read any deprecation message (my dev env is already setup and if I get green ticks in CI I don't view the logs), and if it was a 100% failure then I'm forced to upgrade it and modify the build process then and there. At least with a brown out I'll be temporarily annoyed, but see the deprecation and then set the temporary skip flag and then plan to make the change to the build process a short time later when sprint commitments allow...
I'm always baffled when people say the opposite. There's the matter of pure personal preference, which I accept. The bigger issue I have is with people who have been doing it their own way and will find any number of little reasons to reject anything new.
This guy finds three bugs when he first used it, but all of them look like minor things to me. Complaining about 50 dependencies in 2022 seems silly. Caret versioning as default is personal preference and not an unreasonable choice.
His argument about the 5% chance of failure is the only thing that I find as a strong point. I don't agree with the developer's decision, but it's a deprecated way to install poetry, so I understand.