port "cask" -- installing prebuilt binaries

[Lothar Haeger]

> Am 07.08.2020 um 01:13 schrieb Ken Cunningham <ken.cunningham.webuse at gmail.com>:
> An example: let’s take the port MacVIM, which is ripe for this treatment.
> 
> We can build and install the current macvim on some newer systems - let’s say 10.12 to current.
> 
> port -v install macvim gets you that.
> 
> We will all know what that port represents, without trouble, if there is a ticket.
> 
> Now say on 10.7 to 10.11, we want to install a binary version of macvim. macvim won't build on those systems, but there is a binary that works.

Good example, really. If we can handle this case of a hybrid port properly, the case where a port is totally binary only and won't build from source ever is covered as well.

> We need a clear, identifiable port name to install the macvim binary. It should not be called macvim, that is just a *crazy* recipe for trouble. You’d never be able to keep up with what was what. We need the port to clearly be recognizable as the macvim binary. We need a new name. 


Totally disagree here, though. If we have two ports with different names that provide the same application *that* is exactly the point where the confusion begins. I'd rather have one port that handles both cases properly. Think of two port files in one, sharing the equalities but differentiation where required. A couple of ports do that already and Portfile syntax already allows that today.

In case of trouble, a look at the Portfile (the only one existing, thus correct one) shows where the if/then/else forks and which version is installed which way. Verbose mode during install would also print all the info required to see what's happening as well.

And if we can do this depending on macOS version, we can differentiate based on other criteria as well. So a single port could theoretically provide both install modes for all macOS versions (provided the port builds on all versions and a binary is available for all versions as well). All we'd need to make it possible would be a way for the user to tell the port command which route to choose. 

Here's where I see a variant as an option as this is an already existing mechanism through which a user can select which kind of final binary he wants to be installed. Each variant results in a different binary (being compiled by MacPorts) already, so using another variant as a way to choose a pre-built binary where available seems a simple and logical extension of what we already have and use.
Ports that are always built from sourec to not implement that variant, ports that always use a binary implement it and define it as the default variant. Hybrid ports implement it - possibly for a few older macOS versions - and defaults to building from source where possible. If a port can be build from source or be installed from binary in a certain environment, the user has the option of requesting "+pre-built" and will just get that.