why I will never use python-poetry

Summary

In this video, the speaker explains why they prefer not to use Poetry for managing Python dependencies. They highlight issues like Poetry's complexity and the challenges it poses with dependency conflicts due to its versioning defaults. They also address a recent breaking change in Poetry, where a deprecation led to sudden failures without proper notice, eroding trust. Despite the improvements in Poetry, the speaker prefers using pip and pip tools, which provide a simpler and more reliable solution for managing dependencies and versioning.

Takeaways

• 😀 The speaker has received numerous requests to explain why they don't use Poetry and is addressing the technical reasons in this video.
• 😀 One of the main issues with Poetry is that it’s often unnecessary for managing dependencies, especially with pip's modern features.
• 😀 Poetry's default versioning system, which uses the 'carrot' (^) to define dependency versions, can lead to frequent conflicts when working with libraries like 'requests'.
• 😀 Poetry pulls in around 50 dependencies to function, which the speaker finds overly complicated compared to simpler alternatives like pip.
• 😀 The speaker prefers pip tools, like 'pip freeze' and 'pip-tools', to handle dependencies rather than Poetry's approach, as it is simpler and less bloated.
• 😀 A recent change in Poetry, related to deprecation, caused a loss of trust, as it involved breaking functionality without adequate notice or a proper deprecation strategy.
• 😀 Poetry's decision to break the 'get-poetry.py' script in version 1.2.0 Alpha 1, without clear warning, added instability, especially when running in CI environments.
• 😀 In CI environments, Poetry's approach added flakiness by randomly failing 5% of the time, which is unacceptable in a production setting.
• 😀 The speaker criticizes Poetry for not providing enough time for users to adapt to changes, as the breaking changes were immediate rather than gradual.
• 😀 Although Poetry has reverted the changes, the speaker feels that the damage to trust was significant, especially with how it was proposed and executed by core developers.

Q & A

Why does the speaker not use Poetry for dependency management?

The speaker does not use Poetry because it introduces unnecessary complexity with a large number of dependencies and has inconvenient default versioning, which can lead to frequent dependency conflicts.

What is the problem with Poetry's versioning system?

Poetry uses a 'carrot versioning' system (e.g., >= 3.8, < 4.0) which can cause conflicts, especially with libraries like 'requests'. This versioning system creates complications when different libraries require different versions of the same dependencies.

How does pip's dependency management compare to Poetry's?

Pip, along with tools like `pip-tools`, offers a simpler and more efficient way to manage dependencies and resolve conflicts. The speaker finds that pip's dependency resolver and the ability to freeze requirements into a `requirements.txt` file are more straightforward than Poetry's approach.

What is the issue with Poetry’s default dependencies?

Poetry requires around 50 dependencies, which the speaker finds excessive for what Poetry actually needs to do. This can complicate projects unnecessarily.

What does the speaker think about Poetry's `poetry.lock` file?

While Poetry uses the `poetry.lock` file for dependency management, the speaker believes that pip's functionality, including the use of `pip freeze` to generate a `requirements.txt` file, achieves the same outcome with fewer dependencies and complexity.

Why does the speaker mention the `get.poetry.py` script?

The speaker discusses the deprecation of the `get.poetry.py` script as an example of a trust issue with Poetry. The script was commonly used to bootstrap Poetry, and the abrupt removal of this method caused problems for users without proper notice or a transition period.

What happened with Poetry's handling of the `get.poetry.py` script in version 1.2.0?

In version 1.2.0, Poetry started deprecating `get.poetry.py` by making it fail randomly in CI environments and outright fail in non-CI environments. This sudden change without any notice or a migration plan created frustration among users.

How did Poetry’s deprecation approach affect users, according to the speaker?

The sudden breaking change, where the functionality stopped working immediately without warning or a gradual transition, left users with no time to adapt. This approach was seen as damaging to trust in Poetry.

What is the speaker's preferred method for handling dependencies and versioning?

The speaker prefers using pip with tools like `pip-tools`, which offer a simpler way to manage dependencies. This method allows for generating a `requirements.txt` file and resolving conflicts with fewer dependencies and no need for Poetry's extra layers of complexity.

What lesson does the speaker want to convey regarding the deprecation of features?

The speaker stresses that deprecations should be handled with caution, providing adequate warning and a grace period for users to transition. Abrupt and unannounced changes, especially breaking changes, can damage user trust in a tool.