The tl;dr is using Package URL, a language-independent standard, to declare non-Python dependencies, such as compilers, or shared C libraries. The PEP does not mandate what your tools will actually do with this information – one tool might try to go out and install all those using a system package manager, another might just test for presence and error out, etc. – but the hope is that standardizing how to specify this data about a package will improve the situation for complex packages that do require compilers/non-Python packages/etc.
The only departure from PURL is the introduction of a concept of a “virtual” package which lets you specify, say, that you want a C compiler without naming any particular package it has to come from.
The tl;dr is using Package URL, a language-independent standard, to declare non-Python dependencies, such as compilers, or shared C libraries. The PEP does not mandate what your tools will actually do with this information – one tool might try to go out and install all those using a system package manager, another might just test for presence and error out, etc. – but the hope is that standardizing how to specify this data about a package will improve the situation for complex packages that do require compilers/non-Python packages/etc.
The only departure from PURL is the introduction of a concept of a “virtual” package which lets you specify, say, that you want a C compiler without naming any particular package it has to come from.