Split extras into multiple outputs?

[bollwyvl]

Comment:

Having multiple outputs might be useful for downstreams to be more confident about their requirements.

conda-forge/selenium-feedstock#50 (review)

[sethmlarson]

Is this the only mechanism on Conda for optional dependencies? If so we can create separate feedstocks for this purpose.

[ocefpaf]

Is this the only mechanism on Conda for optional dependencies?

At the moment and probably in the future (based on the community discussion on the topic)? Yes.

If so we can create separate feedstocks for this purpose.

No need. We can use multiple outputs as @bollwyvl mentioned above and keep everything in a single feedstock.

The decision we need to make is:

• we keep the urllib3 name with all extras and create urllib3-core (no extras), urllib3-socks, urllib3-secure and have urllib3 depend on all 3.
• we make urllib3 the no-extras and folks will need to specify urllib3-socks and urllib3-secure when they want the extras.

The former won't break the current setup but the latter has a 1-1 mapping to PyPI. I kind of prefer the former.

[sethmlarson]

I kind of prefer the latter since we're trying to move away from urllib3[secure] so having it as a default wouldn't help that case. What are your thoughts on this?

[ocefpaf]

I kind of prefer the latter since we're trying to move away from urllib3[secure]

Do you mean upstream? If so we can reflect that here when that happens there. If not upstream I'm not sure I understand the context. Or maybe upstream plans on keeping that a a legacy extras option?

[sethmlarson]

Yeah upstream we're deprecating the urllib3[secure] extra: urllib3/urllib3#2680

So if possible would like to move away from installing pyOpenSSL, etc as they'd no longer be recommended (and eventually not needed for any functionality).

[ocefpaf]

Cool. That would be relatively easy on conda land b/c the urllib3 package would not change. We would only remove the secure output from the feedstock. However, if that is happening "now," we may never even create that output b/c we are a bit slow here and when we finally implement them it is probably already gone upstream 😄

[sethmlarson]

The functionality that's unlocked by installing [secure] isn't going away anytime soon, just trying to push people away from that and towards using Python's own ssl module.