On Sun, Dec 11, 2016 at 02:28:14PM +0100, René J.V. Bertin wrote: > > A Portfile should not should not print anything in response to it > > simply being opened. (Think about it, does a user really want to see > > this message whenever they run 'port info' > > Yes they are supposed to! Cf. #52981
No, you even said that in the ticket: """ the information shouldn't be printed unconditionally because then it most certainly would show up at inappropriate times like when running portindex """ Your change made the information show up at an inappropriate time. Remember that even though a user runs 'port info', they might limit the output of that, e.g. using 'port -q info --line --subports'. There is no way to get this right from a Portfile; you must declare the information you want to be printed in a field and implement support for printing this field in the port client, rather than attempting to hack around this in the Portfile. > This message should ideally be delivered before a user starts trying > to install the port, or else when a build failure occurs. Two options: 1. Modify port(1) to print notes before installation of a port 2. Add the information to the long_description of a port, which will be visible on 'port info'. > > The script that finds out which subports exist has to open the port > > to do so, and prints the list of subports to stdout. > > but why would it consider the output from a ui_msg statement as a list > of subports? It's never done that for me, and I'd call that a bug, no > matter how not-done it is to use ui_msg in a port's common code. Because it runs 'port -q info --line --subports' and parses the result. The flags to info guarantee that only the list of subports is printed. You violate this assumption by printing more output in ports. Don't. -- Clemens
