Should packaging understand platforms?

[kknechtel (Karl Knechtel)]

@effigies

if B is cross-platform, then they are presumably testing across platforms and will have adapted their code to tolerate the absence of C. They can then include an environment marker in their dependency list… Now anybody who includes B as a dependency does not need to worry about pulling in C on Windows. If B is not cross-platform, then the author of A should do the same dance, but with B…

I think this leaves the question of why environment markers are apparently standardized even though the platform string is not; and also the question of what/where the specification actually is.

@BrenBarn

Right, but the question is what does C do if they want to say “this package, C itself, is not available on Windows”?

I think the answer is “don’t provide a Windows wheel and don’t upload an sdist”… The problem is that there is no way to say “pip, this is an sdist, but for resolution purposes you should treat it as a wheel with the following set of platform tags, and ignore it if the platform doesn’t match those”.

Presumably one could also rely on a fake dependency designed to communicate the platform information in the same way - analogous to the unsupported-python package described in another thread.

@BrenBarn

but the only reason that happens here with xattr is that pip thinks “install” actually means “install, or maybe try to build”.

The model here assumes that building is a legitimate component of installation, when given something unbuilt to install.

@petersilva

instead of C having in it’s own metadata "platform != ‘windows’, your suggestion is that every developer depending on C in their package puts a conditional dependency in theirs (B.) Why isn’t specifying it in C enough?

There are two possibilities:

1. There is no feasible alternative to C on Windows. In this case, the dependency on C causes B not to work on Windows; therefore, of course B should be expected to specify that it doesn’t work on Windows - because it doesn’t.

2. There is a feasible alternative. In this case, the build process for B needs to communicate to Pip what to use (C) on non-Windows, and what to use (some other D) on Windows. It’s not as if Pip can just know the Windows equivalent to C, after all. And that’s, well, exactly what a conditional dependency is. (This includes cases where the “feasible alternative” is “nothing; just give a runtime error if the user tries to do impossible-on-Windows things on Windows”. In these cases, Pip needs to know to install C when appropriate, and not try to install it otherwise.)