Are all "extras" installed by default?

[Harvie]

What is the default behaviour? Will extras install when not explicitly requested during pip install?

I am working on setup.py for package, which has optional dependency on OpenCV for webcam support, but it can work even without webcam.

Problem is that on ARM systems, there is no OpenCV package available in PyPI. So i would like my package to install without it. I've understood, that i can add it to extras_require={}, but i am not sure how this will work.

When people do pip install mypackage i want webcam support to install if available, but to be silently ignored if not available. But i am afraid that it will install only if people will do pip install mypackage[webcam].

What is the default behaviour? Will extras install when not explicitly requested during pip install?

[Harvie]

If extras are not installed by default, can you please add some feature for this usecase?
Eg. some "NOFAIL" flag for the requirements, so that pip will try it's best to install that requirement, but will not fail the installation if that's not possible to install.

[jriddy]

I don't think you want extras_require. That is always required to be explicit, and as far as I know there's no way to make it silently fail.

When people do pip install mypackage i want webcam support to install if available, but to be silently ignored if not available.

If you really want this, you probably need to do some architecture detection in setup.py and conditionally add it to the install_requires list. And I wouldn't be totally silent. I'd warn when you detect that you can't install webcam, and warn again in the inevitable try/except thing you use to feature-gate your webcam support:

try:
    import cv2
except ImportError:
   warnings.warn("OpenCV not installed: webcam support disabled")

...or whatever you do to detect it.

[Harvie]

try: import cv2

We already do this. But people complain that they cannot install out app using pip on raspberry pi, because opencv-python can't be installed by pip install on ARM.

you probably need to do some architecture detection in setup.py

I am not aware of any reliable way to detect architecture ARM vs PC. Also this might need some requirements that are not installed.

Maybe we can try to run pip install opencv-python in setup.py, but i would call that ugly hack. Also it's not easy to call pip from python script. If you call it as os command it might be in PATH as pip or pip2 and you will never know which one is the right one (because pip sometimes refer to pip3). And calling pip as method internally is not officialy supported and is prevented.

[pganssle]

As far as I know there is no real way to do this, and it's a shame. You could possibly do some funkiness with setup.py, but that will obviously not work if you provide any binary distribution.

It's also not something we can fix in setuptools for the same reason. setuptools is a build backend and as such can only create the package and the metadata that goes with it. We need to fix the standardized dependency metadata to allow for "soft-failing" dependencies and several other unconventional dependencies as well (including the unfortunately ill-fated "default extras_require: #1139).

For the moment, I think you have the following options:

1. If possible, use environment markers to remove the opencv dependency for any platform that can't handle it.
2. Add an option to setup.py that removes the cv2 requirement, users on ARM would need to then do pip install mypkg --install-option="--no-cv2" or something to this effect. If possible, I would use environment markers and provide this option as an "escape hatch" in case your environment markers don't work well
3. Make cv2 an optional dependency for everyone, and everyone has to opt-in by installing mypkg[cv2]. This is the simplest but unfortunately gives the wrong default.
4. Do not release a binary distribution for platforms that do not support opencv (or don't release a binary distribution at all), and do some sort of hack in setup.py to detect whether opencv can be installed on your platform.

As for the correct solution, I suggest we take that up on the packaging problems repository, because this is not a problem that can be solved in setuptools alone. I've created an issue there, pypa/packaging-problems#214.