Add 'optional' or 'recommended' metadata tags to portfile spec.

[c.herbig@…]

There are certain programs that are not actually required for a program to run, but provide additional functionality. I don't think that simply adding them as 'depends_run' ports is a good solution, #39880. For example, Yelp provides a help browser for many Gnome apps, but has many dependencies that, if any are broken, will appear to be problems with the main port to the user. Instead of forcing the user to install yelp as a dependency, it might be better to inform them at install or upgrade time that yelp is a recommended secondary install.

Another example is gnome-themes-standard. Again, it is not at all necessary, but people will expect gnome apps to look a certain way, after seeing screenshots or working with linux systems. Even though this example is more trivial to simply append as a runtime dep, perhaps some people feel that it is not wanted, or are using a different theme.

As such, my proposal is to add one or other of the aforementioned metadata tags, so it would look like this:

recommended_ports   yelp \
                    gnome-themes-standard

and show up to the user after installation is complete as

Recommended supplementary ports:
    yelp                    ${description of yelp}
    gnome-themes-standard   ${description of port}

and let the user decide for themselves.

[cooljeanius (Eric Gallager)]

(for cross-referencing purposes, this is split off from #39886 btw)

[cooljeanius (Eric Gallager)]

Cc Me!

[c.herbig@…]

Replying to egall@…:

(for cross-referencing purposes, this is split off from #39886 btw)

I'm starting to think that just using a variant isn't really the right solution.

[ryandesign (Ryan Carsten Schmidt)]

I like the idea of allowing ports to recommend additional ports. I can think of numerous places where this could be employed. mysql55 could recommend installing mysql55-server. php55 could recommend installing php55-apache2handler. graphviz could recommend installing graphviz-gui.

Presumably the recommendation would not be printed if the recommended port is already installed.

I would like for each recommendation to be accompanied by an explanation. Users would want to know why a port is being recommended. For example, if they were told that yelp is used for accessing help content, and the user has no plans to access the help content, then the user will know they don't need to install it.

[c.herbig@…]

Replying to ryandesign@…:

Presumably the recommendation would not be printed if the recommended port is already installed.

Yeah, that's pretty much what I had in mind.

I would like for each recommendation to be accompanied by an explanation. Users would want to know why a port is being recommended. For example, if they were told that yelp is used for accessing help content, and the user has no plans to access the help content, then the user will know they don't need to install it.

Do you think that simply using the ${description} tag from each recommended port would be satisfactory? It would require that authors use good descriptions. Alternatively, I suppose a description {} keyword could be added to each recommends port line, like variant description {} already does. Or it could be implemented such that if a description {} is not provided, then it defaults to the portfile's description tag.

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

I would like for each recommendation to be accompanied by an explanation. Users would want to know why a port is being recommended. For example, if they were told that yelp is used for accessing help content, and the user has no plans to access the help content, then the user will know they don't need to install it.

If suppressing recommendations for already-installed ports isn’t terribly important, can’t this just be handled with notes?

[c.herbig@…]

Replying to larryv@…: Thanks for that, I didn't realize it would be messy without putting it in the brackets (and I forgot to preview it first).

[c.herbig@…]

Replying to larryv@…:

If suppressing recommendations for already-installed ports isn’t terribly important, can’t this just be handled with notes?

It is (in my opinion at least) mainly a matter of convention and tidiness. In my portfile for gnome-chemistry-utils I included a notes section as follows:

notes \
"Recommended supplementary ports:
    gnome-themes-standard  provides the default Gnome Adwaita theme"

Although it accomplishes the task of informing the user that there is an additional recommended port, I think it would be better in the end for a standardized method to communicate this information. Additionally, using a data tag would allow things like comment 4, or in the future for MacPorts to offer to proceed with installation of recommended ports if the user agrees, similar to what is done in certain linux distributions. It may also prove useful to search through ports and dependencies based on what they were recommended by.

The reason that I don't think variants are a good solution to this problem is that variants get passed down to dependencies, and later trying to change to a different variant can cause lots of errors with those dependencies who were installed with, and insist on having the previous variant. It can turn into a matter that a user may decide to simply not bother with altogether.

[cooljeanius (Eric Gallager)]

The way Homebrew does it is that dependencies of their equivalent of default variants get listed as "recommended" dependencies, while the dependencies of their equivalent of non-default variants get listed as "optional" dependencies. While this is slightly different than what the OP is asking for, I think something like that could still be useful, to more easily see all the dependencies pulled in by different variants without having to actually specify all of those variants.

[larryv (Lawrence Velázquez)]

I don’t think this is worth the development effort if all it does is display a list of maybe-useful ports. That’s what notes are for—to provide a single place to define information that should be displayed after a port has been installed. It’s not the most structured solution, but defining a wholly new Portfile option with special syntax (“description” fields and the like) seems needlessly complex.

Likewise, simply giving “recommended” and “optional” labels to different dependencies based on the variants that require them would add complexity without commensurate utility.

As far as I’m concerned, the only functionality that merits this is the ability to operate on recommended ports in the same way that we can currently operate on dependencies and dependents. (As you mentioned, many package managers allow for this.) It would probably require a great deal more work than simply adding a new option. The dependency engine would have to be made aware of this new relationship, and the semantics of the relationship would have to be thoroughly discussed.

[c.herbig@…]

A downside with using notes is that they don't show up in port info NAME, so if the user misses the notes section after it is installed, they might not know how to get back to see what it was. This can happen when they are installing a chain of ports and the notes gets buried behind a lot of other messages, like the way that the notes for dbus do.

[larryv (Lawrence Velázquez)]

Replying to c.herbig@…:

A downside with using notes is that they don't show up in port info NAME, so if the user misses the notes section after it is installed, they might not know how to get back to see what it was. This can happen when they are installing a chain of ports and the notes gets buried behind a lot of other messages, like the way that the notes for dbus do.

Admittedly true. There’s been a ticket on this, as well as at least one ​absurdly convoluted mailing list discussion.

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

I like the idea of allowing ports to recommend additional ports. I can think of numerous places where this could be employed. mysql55 could recommend installing mysql55-server. php55 could recommend installing php55-apache2handler. graphviz could recommend installing graphviz-gui.

Also along these lines, Python could recommend installing py-tkinter and py-gdbm ^{(this recently came up in IRC because a user had installed python33 and was confused why IDLE wasn't starting)}, and qt4-mac could recommend installing one of the qt4 database plugins ^{(like the sqlite3 one: see #39803 for more on that)}.

[nonstop.server@…]

Cc Me!

[jfilippidis@…]

Cc Me!