Dependency Extras Are Unnecessary & Illogically Removed After Adding #2494

• I am on the latest Poetry version.

• I have searched the issues of this repo and believe that this is not a duplicate.

• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: MacOS Catalina 10.15.4

• Poetry version: 1.0.5

Issue

Hello, I am working on a project that is experiencing odd "extra" dependency removals. At a high level, I have noticed "extras", that are explicitly written within the pyproject.toml file, are removed whenever I add a new dependency. For security/privacy purposes, I will only be pasting in some sections of the code.

pyproject.toml:

...
[tool.poetry.dependencies]
package-a = {version = "^1", extras = ["app", "boto"]}
...

poetry.lock contains package-a and both app and boto as dependencies. I was happy with this initial state.

When I go to add a new dependency, e.g. Django (could be anything for that matter), I am seeing this within the poetry output:
poetry add django -vv

Package operations: 4 installs, 0 updates, 8 removals

  - Installing asgiref (3.2.7)
  - Installing pytz (2020.1)
  - Installing sqlparse (0.3.1)
  - Installing django (3.0.7)
  - Removing boto (2.49.0)
...

It has no logical reason to remove boto, but it does and does not explain anything related to boto within the very verbose output.

Surprisingly, when I lock down the version of package-a to NOT use caret specification (like so):
pyproject.toml:

...
[tool.poetry.dependencies]
package-a = {version = "1.0.0", extras = ["app", "boto"]}
...

And I proceed to add django the same way I did above. It doesn't remove boto! It respects the extra when I don't use carets to note the applicable package version updates.

For what its worth, this issue also holds when I use multiple requirements like so:
pyproject.toml:

...
[tool.poetry.dependencies]
package-a = {version = ">= 1.2, < 1.5", extras = ["app", "boto"]}
...

--

In summary, I can't understand why package extras are deemed removable when I use caret specification. I find this to be somewhat similar to the other issues, but certainly with its unique set of characteristics.