Determine before installation whether a port can be installed

[Clemens Lang]

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.


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).

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.

What do you think?
-- 
Clemens