Support dependencies groups

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

Feature Request

As @mozartilize stated in this comment, groups from Ruby’s gemfile could be a great addition and a solution to our complex workflows and different environments (local, production, ci, docs, etc.).

Instead of supporting more tool.poetry.*-dependencies sections, we could add support for a groups property on dependencies. It would be more flexible than rigid sections.

I also understand there is the extras functionality, but using extras changes the behavior of poetry install, as one needs to now specify the extras to install all the dependencies. Also, extras are opt-in only, and often times we need opt-out.

[tool.poetry.dependencies]
python = "^3.6"
requests = "*"

[tool.poetry.dev-dependencies]
bandit = { version = "^1.5", groups = ["ci"] }
black = { version = "*", allows-prereleases = true, groups = ["ci"] }
coverage = { version = "=5.0a8", allows-prereleases = true, groups = ["ci"] }
flake8 =  { version = "^3.6", groups = ["ci"] }
ipython =  { version = "^7.2", groups = ["local"] }
isort = { version = "^4.3", extras = ["pyproject"], groups = ["ci"] }
jinja2-cli =  { version = "^0.7.0", groups = ["local"] }
pylint = { git = "https://github.com/PyCQA/pylint", groups = ["ci"] }
pytest =  { version = "^4.3", groups = ["ci"] }
pytest-cov =  { version = "^2.8", groups = ["ci"] }
pytest-sugar =  { version = "^0.9.2", groups = ["ci"] }
pytest-xdist =  { version = "^1.26", groups = ["ci"] }
recommonmark =  { version = "^0.6.0", groups = ["docs"] }
safety =  { version = "^1.8", groups = ["ci"] }
sphinx =  { version = "^1.8", groups = ["docs"] }
sphinx-rtd-theme =  { version = "^0.4.2", groups = ["docs"] }
toml =  { version = "^0.10.0", groups = ["docs"] }

Also:

• default group would be attributed to dependencies without groups (requests in the above example)
• each dependencies would be attributed its own group as well, something like /bandit for bandit, etc.

Then we would have the following options for the poetry install command:

• --groups: explicitely specify which groups to install (these and only these groups, no implicit default group)
• --with-groups or --with: default group plus the specified groups
• --without-groups or --without: all groups minus the specified groups

Usage would be:

# in CI
poetry install --groups ci

# or in specific CI jobs
poetry install --groups /bandit  # bandit reads the code, we don't need anything else
poetry install --with /safety    # safety needs production dependencies to be installed

# locally, all three lines are equivalent
poetry install  # installs everything, as usual
poetry install --with local,ci,docs
poetry install --groups default,local,ci,docs

# on readthedocs
poetry install --with docs  # sphinx-autodoc needs production dependencies to be installed

#1007 could then probably be closed in favor of this issue.

[matthijskooijman]

Great to see this feature is now available, thanks. Also great that this neatly generalizes the dev-dependencies in a compatible way 😃

I’ve read through the documentation, and am left with a few questions:

1. After reading this section, I wonder: What’s the difference between poetry install --default and a plain poetry install? Does the former install only dependencies, and the latter also the package itself? Or is there another reason for --default to exist?
2. How do dependency groups interact with extras? From the docs, it seems that these two features now coexist but are completely separate? Wouldn’t it be possible to also integrate these? Essentially, AFAICS, extras are just optional dependency groups, so it would be nice if they could be treated (and specified) as such? That would mean that --with and --extras become essentially the same option (--extras could be deprecated maybe), and extras could be specified using the new dependency group syntax (and the [tool.poetry.extras] section and optional attribute on individual dependencies could also become deprecated, I think). I might be missing some subtle differences that prevent this, though?

[adriangb]

Thank you for getting this done @sdispater !

Any plans to release another pre-release with the feature? My team has a pretty convoluted setup (not using Poetry) that could be simplified greatly with this feature, I’d love to migrate to Poetry.