phpstylist should use MacPorts PHP

[face@…]

phpstylist uses the Mac OS X version of PHP

The patch file (see Revision 79013, 314 bytes (checked in by ryandesign@…, 30 hours ago) adds

#!/usr/bin/php

to the code. Wouldn't it be more in keeping with MacPorts to make that

#!/usr/bin/env php

[ryandesign (Ryan Carsten Schmidt)]

I thought about that. On the other hand, it apparently works with Mac OS X's version of PHP. Would bringing MacPorts PHP with all its dependencies add any value to phpstylist?

[rudloff@…]

phpStylist requires PHP 4.4.2, so it works perfectly with /usr/bin/php (4.4.9).
Installing the php port and all its dependencies seems like overkill for such a small utility.

[face@…]

fine by me - just noticed it and wondered why.

Seems odd that "installing the php port" would be overkill. Macports to get a php styling utility, but only using the Apple version of php.

[rudloff@…]

Is there a way to use the port if it is installed and the Mac OS version if not ?

[ryandesign (Ryan Carsten Schmidt)]

Yes; the proposal in the ticket description would do that (i.e. just change "#!/usr/bin/php" in the script to "#!/usr/bin/env php" without adding any dependency). Would that be beneficial? I'm worried it would introduce greater uncertainty. Currently, there are three possible PHP versions phpstylist in MacPorts might use: those provided by Snow Leopard, Leopard, and Tiger. If we let it use the php5 port, that makes two additional possible versions: those provided by php5 and php5-devel. Indeed, the greatest consistency can be had by requiring the use of MacPorts PHP, as is our usual policy, but I agree it is a heavy dependency, especially since by default it would bring apache2 with it.

[rudloff@…]

phpStylist is not a very complex program and the readme says it has been tested with PHP from 4.4.2 to 5.2.2. I don't think letting people use a different version of PHP will cause problems. But if someone finds a problem with PHP 5.3, I don't mind writing a patch.

However, I totally understand if you want to add the php port as a dependency.

[rudloff@…]

Patch

[rudloff@…]

Here is a patch that adds php as a dependency and changes the shebang.

[ryandesign (Ryan Carsten Schmidt)]

Replying to rudloff@…:

Here is a patch that adds php as a dependency and changes the shebang.

Does making this change fix some problem? Does using the OS X version of php no longer work, for example because newer versions of OS X include newer versions of php?

Since your proposed patch changes the files the port installs, the port's revision must be increased.

The patch is not correct: it adds a port:php52 dependency and changes the shebang line to "#!/usr/bin/env php", but the php52 port does not provide a program called php; it provides a program called php52. (This has changed in the years since this ticket was filed.) If you're declaring a hard dependency on the php52 port, then you should make sure the program installed by the php52 port is the one that gets used, by making the shebang line "#!${prefix}/bin/php52".

php52 is end of life, as is php53. If phpstylist will work with later versions of php, those should be used instead. But if not—if the whole purpose of this change is to prevent newer incompatible versions of php from being used by this 8-year-old software—then using php52 is fine.

[pmetzger (Perry E. Metzger)]

Given the number of years that have passed, should this be closed out?

[ryandesign (Ryan Carsten Schmidt)]

Why? Nobody has yet answered the question yet, specifically: would adding the proposed dependency help? If it would, then do it. If not, don't. Then close the ticket.

[pmetzger (Perry E. Metzger)]

"Why?"

First, because the submitter and the owner haven't replied in years, and thus are unlikely to every reply again without someone actively soliciting input from them.

But, more generally: because if you make your tracking system into a graveyard of dead requests that will never be acted on, you end up with it being very difficult for someone to look through it and find things that actively need fixing.

The function of a ticket system is to allow people to keep track of open issues and to direct their work so that those issues get resolved. This requires that most tickets contain actionable information, so that someone looking through the tickets can easily find tasks that they can quickly perform.

(There is a second category of things that can validly be left open indefinitely: tickets can be used to record projects that are important but might not be acted on for quite some time. This allows for tracking of projects that are of interest. But, generally, there are fairly few such things that one tracks compared to the number of defects and issues reported by users, so they don't generally get in the way of using the ticket system to track problems because the nature of such tickets is obvious in the description.)

If a ticket system gets overly clogged up with things that cannot be acted on and likely never will be acted on, the things that do need attention get lost in the fog. You end up with people waiting years on things that could be acted on because no one can see that they're in need of attention. Then people get depressed that the problem keeping them from getting their work done has been ignored, and wander off, never to return.

New people looking at the tickets system also get immensely depressed when they see that it is not uncommon for people to report an issue and have it sit for many years without action. It is, of course, vastly easier to clear out actionable requests when you can find them. (And thus, again, it is best not to have a lot of things in the system that cannot be acted on, because otherwise you need a lot of effort to find the actionable items amidst the unactionable ones, with most effort going not to fixing problems but to finding the problems that can be fixed.)

[chrstphrchvz (Christopher Chavez)]

phpstylist was set to nomaintainer: [d1f0ca7288/macports-ports]