Improve display of installed variants

[yan12125]

Homebrew collects the number of installations with various options. For example, in https://formulae.brew.sh/formula/wget, there are wget, wget --HEAD, wget --with-debug and so on. Seems there is nothing similar in https://frozen-falls-98471.herokuapp.com/port/wget/?

Homebrew developers use such statistics to determine what kind of options should be the default. I believe port maintainers can enjoy similar benefits from such statistics, too.

[jmroot]

Variant information is already collected, it just needs to be displayed.

[yan12125]

Great to know that!

[arjunsalyan]

Thank you. Variants shall be soon added.

https://frozen-falls-98471.herokuapp.com/port/wget/ is now outdated. The latest version runs on ec2 now:

http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com

[yan12125]

Thanks for clarification! Mind to update the link for this GitHub repository?

[mojca]

Done, thanks. In any case we hope to be able to deploy it soon.

[yan12125]

Thanks for the update! Here are some ideas:

(from https://ports.macports.org/port/wget/?tab=stats&days=30&days_ago=0)

• Does the first row indicate wget without any variants? If so, it might be better to write something like "(no variants)" in the first row.
• +gnutls, +ssl might be better than gnutls +, ssl +

[mojca]

I agree with both and also wrote both down to the long document with minor pending issues.

Yes, the trailing + should go.

Quoting myself on the other point:

For variants we should distinguish between NULL (variants unknown) and in that case write (unknown) and an empty string and in that case write (none). If no variants are the most popular case, also make sure that (none) is written in the above suggested table entry. We should not count unknown (NULL) values to determine the most popular variants.

The empty field doesn't necessarily mean "no variants", but mostly "no data", for the following reasons:

• we didn't have the required field in the table until you opened this issue
• we did not record the raw submission data during a certain period of time
• we do have some raw data from before we introduced another field, but we did not run the sql query which would extract those data (for cases of existing raw data and missing variants)
• NULL values are currently not properly distinguished from empty strings.

We need to fix the issues and probably rerun the query to fill in (fix) the data from raw submissions (for every single submission where raw data existing; where it doesn't, make sure that NULL gets filled).

[yan12125]

Thanks for clarification! By the way, the document for pending issues is awesome.