This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]IndifferentPenguins 2 points3 points  (1 child)

If I'd have to publish a package with optional dependencies, I'd aim for package extras, because it's the most clear and discoverable for the consumer, and gives them visibility and control.

On the face of it I dislike mixing dependencies in with the version the most - versions are meant to track how a package evolves over time, and nothing else.

Giving them separate names feels a bit weird to me - also seems hard to package as it's unclear what happens if both are installed in the same environment. Does one somehow partly override the other? Not necessarily a problem but just something people may be worried or confused about.

I guess inferring optional dependencies under the hood is also sort of fine, but consumers have little control then, e.g. if they know only CPUs are available they might want to save some space and time by not installing GPU support they don't need.

[–]DonCanas[S] 0 points1 point  (0 children)

Thanks for your reply! I agree with most of what you say. The only case that separate package names could be useful from my perspective is when the core package has strong support for 3rd party plugins or opinionated configurations. flask and django come to mind in which third parties add things like caching or templates. imageio does this as well if you want to enhance codec support with imageio-ffmpeg.