Section on entrypoint extras could use clarification

the extras field related part of the entrypoints data model description currently states:

Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools’ model of managing ‘egg’ packages, but newer tools such as pip and virtualenv use a different model.

a text-related question would thus be: what is that 'different model'.

my practical question is: how should i implement modules that contain entrypoints that are supposed to be only loaded when a certain extra (dependency) has bee installed upon installation? afaict, pkg_resources.Distribution.extras contains all defined extras from the metadata, not just the installed ones. so for now i can only think of designing a module that contains entrypoints like this:

# the example assumes a console_script was defined w/o tying it to an extra as recommended
# the requests module was only installed when a certain extra (for dependencies) was selected

try:
    import requests 
except ImportError:
    def my_console_script():
        raise RuntimeError("Though I'm available, I can't help you due to a missing dependency.")
else:
    def my_console_script():
        pass  # functional code here

please note that i'm not a native tongue english speaker and might miss some subtleties.

Iniziate dalla sezione extras nella descrizione collegata del modello di dati degli entry points e esaminate i riferimenti dell'issue a setuptools, pip, virtualenv e pkg_resources.Distribution.extras. Chiarite cosa significa il modello più recente e spiegate come devono essere gestiti gli entry points associati a dipendenze opzionali, compreso se sia necessario rivedere la formulazione attuale.