Well I do, and I like the idea of something that’s pip.conf-able but… I think it’ll make it even worse. If package foo thinks it depends on package bar but doesn’t realise that it needs bar[thedefaultgroup] then pip install foo would be broken with the flag. Similarly, if bar had no recommended dependencies then decided to move a mandatory to a recommended one, thinking this would not be an incompatible change, then anyone who uses the flag again receives a potentially broken package. To mitigate this, I think we’d end up having to standardise the recommended name then get into the habbit of always writing foo[recommended] when specifiying dependencies. It’s puts quite a burden on package developers to always test a --no-default-extras built setup.
But if we’re going into pip details then does anyone have a plan for how
pip install package[minimal]
pip freeze > requirements.txt
# In a new environment
pip install -r requirements.txt
is going to avoid pulling in package’s recommended dependencies?
Yeah, you can argue it either way. Either a getting started page can say run pip install package[accelerator] then explain what benefits you’d get with the accelerator bit or it can say run pip install package or pip install package[minimal] and again explain the difference. (I’d prefer the explicitness of the first but I know that’s just a preferences thing.)
A lot of packages that have optional cython/rust extensions tend to treat the opt out users as second class citizens (in both documentation and testing). I suspect that pip install package[minimal] users will end up the same.