Dependencies on non-default variants (was: GSoC 2019 [Collect build statistics])

[Craig Treleaven]

> On Mar 24, 2019, at 4:05 PM, Mojca Miklavec <mojca at macports.org> wrote:
> 
> On Sun, 24 Mar 2019 at 19:55, Craig Treleaven wrote:
>>> On Mar 24, 2019, at 1:09 PM, Mojca Miklavec wrote:
>>> On Sun, 24 Mar 2019 at 01:06, Craig Treleaven wrote:
>>>> 
>>>> There are a number of ports that require a dependency to be installed with a non-default variant in order to build successfully.  A short-coming of MacPorts is that this cannot be done progammatically
>>>> 
>>>> When this is rolled out, we don’t want to make users think that a port will fail to build on their system when it is just a case of needing a non-default variant.
>>>> 
>>>> However, I don’t know how to handle this cleanly.   Perhaps we could parse the build log looking for the message that informs the user how to install the required variant.  If found, instead of saying the build failed, we could indicate that the build was not attempted as the buildbot configuration could not support a successful install.
>>> 
>>> I totally agree with your request, but this is completely out of scope
>>> of the proposed app. This either needs a proper extension in the base,
>>> or a workaround in mpbb, preferably the former. I believe a much
>>> bigger general issue is reporting failure of port builds on OSes which
>>> are know not to be supported (like: attempting to build the latest Qt
>>> on 10.5). Again, this needs to be addressed elsewhere.
>>> 
>> This issue hits very close to home for me.  None of my MythTV ports, nor the hdhomerun-gui port, will build successfully on the buildbots.  They never have.  They *will* build successfully (on supported OS versions) if the proper variants are specified.
>> 
>> If an unknowing potential user came to page for any of these ports and found nothing but failure messages for all of the buildbots, why on earth would they want to proceed to install the port?
> 
> […]
>> If we won’t expand the scope to handle this relatively common issue, we should at very least add some static text to the web page explaining that buildbot failures don’t mean necessarily mean the port will fail for a particular user.  Even so, that is a very poor workaround.
> 
> You could equally argue that users will see that ports don't fail, but
> then they are buffled when they cannot install those ports on their
> own machine. We should really really fix the situation in MacPorts.
> 
Not the same at all.  Now, if a user doesn’t specify the right variants they get a message that tells them what to do.  Of course it would be better if that didn’t happen but this is the way things work, now.

> I would say: Don't kill the messenger. Just because one application
> exposes some issues with MacPorts, it doesn't mean that the
> application needs to be endlessly tweaked to hide those problems away.
> We should no have failing builds on the buildbot, end of story. We
> need to do everything to avoid failing builds, not to implement
> explanations and workarounds on the wrong level. Note that we'll
> probably have another student apply for a different project which
> would, if selected, expose the exact same problem on a different page.
> Should we implement those workarounds ten times?
> 
As you said, people have looked at this problem and not found a workable solution.  It may be a _long_ time before a “proper” solution is implemented.  In the meantime, reporting these as failed builds *actively misinforms* users.  When you say there will be the same problem “on a different page”, I don’t know what you mean.  And if we can implement a workaround, why can’t we share it with this other page?  Why would we have different pages reporting the same information?

As I see it, all we have to do is search the appropriate log for the message that the active_variants PortGroup spits out when it detects a dep with the wrong variants.  If found, we replace the text “Failed” with something like “Build not attempted”.  And probably add a link to a page that explains why not.  Clean and elegant?  No.  Hard to do?  Again, no.

> My argument is that we need to fix ports and base to avoid those
> failures, not to explain them away.

I don’t disagree.  I guess I’m not as optimistic that this will be done quickly.

Craig