# Adding a default extra\_require environment

**URL:** <https://discuss.python.org/t/adding-a-default-extra-require-environment/4898>\
**Category:** Packaging\
**Created:** [August 3, 2020, 6:51pm UTC](https://discuss.python.org/t/adding-a-default-extra-require-environment/4898 "2020-08-03T18:51:56Z")\
**Posts on this page:** 1\
**Showing post:** 33

<div class="post-metadata">

**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\
**Post date:** [August 5, 2020, 8:46pm UTC](https://discuss.python.org/t/adding-a-default-extra-require-environment/4898/33 "2020-08-05T20:46:49Z")

</div>

Sure, the expanded options get way more complicated (which is why I proposed [Idea: selector packages](https://discuss.python.org/t/idea-selector-packages/4463)), but even using extras you are still going to have to create those packages. And if you want to provide `project[lib]` for your users, then the interface of that matters as much (more?) than the interface of just `project`. Or else your `project[lib]` users are going to have to carry your entire GUI implementation as well, even though they don’t get the dependencies needed to make it work.

Extras are just that - extra dependencies. Everything else is architecture 😉 (and yes, it’s complicated, which is why we avoid doing it for free).

I like the idea of explicitly specifying default extras though. Doesn’t solve the bigger problem of users needing to know what they need before they know that they need to know, but at least it smooths off one of the current issues.

---

_[View the full topic](https://discuss.python.org/t/adding-a-default-extra-require-environment/4898)._
