Brae

Hi, I am also experiencing with Poetry 1.4.0 that `poetry add package@version` just updates (and installs) the specified package(s) in poetry.lock, but `poetry add --lock package@version` performs a full poetry.lock...

The order of `self.installer.whitelist` does not appear to matter. However one difference I see is `locked_repository = self._locker.locked_repository()` is called both for `add` and `lock --no-update`, resulting in `locked_repository` being...

@finswimmer @radoering @dimbleby The folllowing achieves the behaviour I desire and expect. Thoughts? Specifically does this cause any issue for `poetry lock`? `poetry lock --no-update` is not affected since it...

This change causes two tests to fail. ``` test_lock_with_invalid_lockfile[False] test_lock_with_incompatible_lockfile[False] ``` Both tests employ the same reasoning. https://github.com/python-poetry/poetry/blob/0e72a55c43a993ec0258facec23416c9212964ba/tests/console/commands/test_lock.py#L281-L292 https://github.com/python-poetry/poetry/blob/0e72a55c43a993ec0258facec23416c9212964ba/tests/console/commands/test_lock.py#L311-L318 A lock file is not required `if self._lock is True`? But...

Interesting suggestion. Keep in mind your proposed fix will cause `poetry add --lock` to have the same printing behaviour that `poetry update --lock` has. See https://github.com/python-poetry/poetry/issues/7588 It also causes two...

The `dbeaver --connect` parameter seems like *not* a solution, because of the following behaviour I am observing (on 24.1.1): In order to use the `password` connection parameter, you cannot specify...