…could be misused AND is superficially an extremely attractive option with large ramifications that aren’t obvious until it’s way too late (and sometimes never to the people who get to make that decision). That’s the key. Otherwise, yeah I’d agree anything can be misused.
We’re in an unusually privileged position with this proposal in that we don’t need to speculate how it’ll pan out. We’ve already got extras which bring a lot of the same issues. Rust, Debian, Fedora already demonstrate what recommended dependencies are like. The concerns we’re raising here aren’t guesses – they’re what’s already happened.
Adding “you may also want” dependencies willy-nilly? Try dnf install fedpkg in Fedora[1]. Try setting up any environment in a Ubuntu Docker container with and without --no-install-recommends, observe the differences in size[2] and see if you can figure why even one of those unused recommendations are recommended. Or just look at the “yes I can’t wait to do this!” comments in these threads despite the surrounding conversation being about precisely not doing that[3].
Giving packages an easy way out of good scoping? Take the astropy example from the PEP. If you’re looking for a minimal installation and are only using the bit of astropy that doesn’t use their recommended dependencies, are you really going to be content to carry the entirety of astropy? I know I wouldn’t.
I would contest any claims that just pick one is a good answer for repackagers. I have to make these calls fairly regularly. It’s horrible. It takes a lot of research and usually results in “hmm, bloated or broken? Well both options suck!”. The bloat that Conda has to accept is real. Yes, they accept it[4]. That doesn’t stop people from complaining how big and slow Conda gets. And It’ll be worse for Linux distros that are more likely to be used in a lambda server have much stronger focus on avoiding dead weight.
How would you know which packages chose not to scope creep because of lack of this feature? I know I tried to make that mistake several times in my early packages before I’d done enough deployment work to appreciate just how valuable an unambiguous dependency tree is. I’m so glad I was forced to split things up.
This one’s more about interchangeable dependencies than optional ones. If A depends on requests or httpx and then B depends on A and also needs an HTTP client then B has to make an awkward decision about preserving the requests/httpx optionality. It’s maybe not the end of the world if two HTTP packages end up being used redundantly provided the output of one never becomes an input to the other. It is the end of the world however if say multiple Qt variants are imported[5].