== optional?
This topic is in response to:
More dependency categories (and properly supporting ones we actually have): Recommends (optional, installed by default), default extras dependencies , Provides , Obsoletes
6 posts were merged into an existing topic: PyCon US Packaging Mini-Summit 2019
@njs I think you are replying in the wrong thread.
2 Likes
Whoops, so that’s what happened. For some reason Discourse has suddenly decided that I can’t log in from my phone, so I was replying through email, and then I guess it decided to route the emails over here… I think I fixed it now. (Though I’m still confused at why Discourse won’t let me log in on my phone.)
1 Like
I think there are two use cases here. One is optional requirements (install it by default if possible, otherwise don’t bother) that applies to speedup modules (eg Cython). The other is default extra (install it unless explicitly excluded by the user) that is useful for an umbrella project, in which case it’d probably be a good idea to error when recommended packages fail to install.
1 Like
Things like Cython can also be optional build dependencies. So it’s probably the third use-case, right? I’m currently solving this by having a custom PEP517 build backend which tries to install such optional build deps, ignores the outcome and then proxies things to PEP517 build backend of setuptools…
Yes, although the context is a bit different IMO. The original suggestion is about package metadata (dist-info), and top-level build dependencies are not handled by it. Packages depended by top-level build dependencies listed in pyproject.toml can be handled the same as case 1.