Ship Poetry releases with pinned dependencies

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the FAQ and general documentation and believe that my question is not already covered.

Feature Request

I propose that Poetry itself is distributed with locked/pinned dependencies for each release. This makes each Poetry release reproducible and consistent for all users. This treats Poetry more like an application than a library/package, which is how users interact with it.

Currently Poetry gets installed as a Python package with bounds on its dependencies rather than being pinned/locked. This means that if User A installs Poetry version X, and later User B installs version X, and User C upgrades to version X from version W, all three of these users can result in different Poetry installations with subtly different dependencies.

This can lead to some hard to undderstand/fix issues such as:

• #7344

Within teams, it can also make it harder to debug why one developer's Poetry is acting in an odd way with the same version of Poetry than anothers, because their transitive dependencies Poetry is riding on top of are different.

I've noticed that if you simply run poetry update to update Poetry as described in the docs, then your dependencies tend to lag behind what you'd get if you did a fresh install or instead ran the more verbose poetry self lock && poetry self update.

I believe this could also help make triaging tickets better, as maintainers could know that if a user reports an issue with Poetry version X, the maintainer can reproduce the exact transitive dependencies that user has.

In this idea, we could remove poetry self lock, poetry self install, etc. and simply use poetry update to look for a new Poetry version, and install it and it's locked dependencies into the environment.

Start with the official installer documentation and the current poetry update, poetry self lock, and poetry self update workflows mentioned in the issue. Compare how a fresh install, an upgrade, and a locked update resolve dependencies. Done would mean each Poetry release installs reproducibly with pinned transitive dependencies and the proposed self-management commands are no longer needed.