Often on Windows, we want to turn off packages we depend on because they do not link well with external libraries. Macro allows us to change the code for each OS
{% if flag?(:linux) %}
# Linux
{% elsif flag?(:darwin) %}
# Mac
{% elsif flag?(:win32) %}
# Windows
{% end %}
However, in shard.yml, macros do not work.
If you have shard.win.yml, you have to manually replace shard.yml with shard.win.yml.
I think one alternative would be having a shard.linux.yml file and shard.win.yml file then having shard.yml execute one of the two in postinstall but even that is a bit problematic. Out of curiosity, how would platform-specific dependencies be defined in a shard.yml file if it were to be supported?
we can extend shard.override.yml to make it deal with platform specific problems.
so in this case, dependencies defined in shard.override.yml only override default shards on certain conditions (like on some certain platforms)
I think the general idea is that shards are portable and shouldn’t care about platform requirements.
Of course, this doesn’t hold because sometimes you’ll need some specific dependency on some platform but not on another.
So this could be a feature request for shards.
A possible implementation would be to have a target field for each dependency which specifies the dependency is only required on matching target platforms.
However: ignoring dependencies can lead to issues with the dependency resolution because it would lead to different results depending on platform. So I think we could only ignore such dependencies entirely when installing without resolving the graph (i.e. with --frozen option).
And frankly, I think installing a dependency despite being not actually needed on the current target platform is not a big deal. The savings from not installing it are pretty limited.
When building the program, macro expressions can control which shards are actually used in the build.