Determine before installation whether a port can be installed

[Ryan Schmidt]

> On Aug 4, 2016, at 2:36 PM, Clemens Lang wrote:
> 
> Hi,
> 
> On Thu, Jul 28, 2016 at 03:21:56AM -0500, Ryan Schmidt wrote:
>> However, as I've said, there are other reasons why a port might not be
>> able to install. Should we really modify MacPorts base and create new
>> variables to accommodate each of those reasons? Is there a specific
>> objection to what I consider the easiest and most flexible of the
>> options I suggested: implement a new preflight phase, in which the
>> port can run any logic to determine if the port can be installed?
> 
> I have a specific objection: If this is a phase and does not use
> declarative syntax, you absolutely must open and run the code in the
> Portfile to determine whether a port will build on your OS.
> 
> Opening a running Portfiles is (a) already where our dependency
> management spends most time, (b) hard to optimize in the absence of a
> interpreter-fork-like behavior in Tcl with our current approach, (c)
> completely breaks the idea of using SAT-solving for dependency
> resolution or any other modern method, because those methods depend on
> having accurrate information about *all* available ports (which would
> mean we'd have to run all ports).
> 
> So in short: The phase cannot be put in the port index, which is a bad
> idea in my opinion. Declarative approaches like the platform statement
> can.

Thanks for the explanation! These are good points that I hadn't considered.


> On Thu, Jul 28, 2016 at 01:02:15PM +0200, Rainer Müller wrote:
>> On 2016-07-28 09:06, Artur Szostak wrote:
>>>  macosx >= 10.9
>>>  macosx < 10.10
>> 
>> https://trac.macports.org/ticket/15712
> 
> I like this approach. Remember the brew uses a similar approach to
> blacklisting, which is basically
>  platforms >= :lion
> (please excuse any butchering of Ruby syntax). This is very simple to
> get right, and I'd prefer a similar approach.
> 
> Ryan: Which other cases can you think of? I think we can handle most of
> them with a similar approach. Why not have a field that contains
> identifiers which reference well-known tests for a feature? Here's an
> idea:
> 
>> constraints java-1.0
> 
> uses _resources/port1.0/constraints/java-1.0.tcl to determine whether
> the constraint is fulfilled, but does this once for all ports, rather
> than once per port. Similarly, we could have
> 
>> constraints {platform-1.0 >= lion}
> 
> which could load _resources/port1.0/constraints/platform-1.0.tcl and run
> a proc from there with the ">=" "lion" arguments (again, without running
> the complete Portfile and loading all files in port1.0).

This could work. Does this mean that we drop all pretense of compiling on other operating systems? Or, if we continue to allow it, do we need a way to distinguish between 1) a port that works on any OS but if built on macOS needs a particular version, 2) a port that only works on macOS and need a particular macOS version, and 3) a port that only works on macOS but works on any version?


> That would also allow you to implement manual download checks:
> 
>> constraints {manual-download-1.0 "${targetfile}" "${downloadurl}"}
> 
> Whether that field is now called "platform" or "constraints" doesn't
> really matter. We could make them aliases.

Very interesting idea for declaring the need for manual downloads.



> What do you think?