On 01.03.2019 20:27, Ivan Pozdeev wrote:
> The fact that this feature is mixed up with and often supplements 
> "real packages" that a program would explicitly use is actually 
> incidental: a package with a .pth does not need to have any 
> functionality intended for explicit use.
>
Eureka! So, there are actually two kinds of packages: "functional 
packages" to be used explicitly and "environment packages" to customize 
the execution environment. The infrastructure just doesn't distinguish 
between them and allows a package to combine both types of functionality 
for convenience.

By this logic, pywin32's .pth is effectively a private import hook to 
allow for its nonstandard structure. It could be in a separate 
"environment package" that would be a dependency but that would 
complicate things for no real gain.

The caveat with "environment packages" is that there are no predefined 
dependencies between them and between them and "functional packages". 
Their required execution order rather depends on user's needs. E.g. the 
order of import hooks' registration would matter if more than one can 
serve a specific name, and the user may prefer any of the options; 
whether some import hook is required to import some installed packages 
depends on the way they are installed.

This is the same with any other plugin functionality, too. And I'm not 
aware of any general solution because a solution is very situational. 
The best we can do here that I see is to allow the user (or, you guessed 
it, yet another "environment package" for manageability) to specify load 
order dependencies between .pth's.