Re: execute compressed PHP command-line application

From: Date: Sat, 27 Jul 2013 09:38:01 +0000
Subject: Re: execute compressed PHP command-line application
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
On 07/26/2013 04:56 AM, Ferenc Kovacs wrote:

check out http://us1.php.net/phar and



http://www.php.net/manual/en/**wrappers.phar.php<http://www.php.net/manual/en/wrappers.phar.php>
currently this is the preferred method



Preferred by whom, thank you very much?  Who is it that has set
himself/itself up as The Authority on this subject?



the pear installer is shipped as a phar file, phpunit also provides phar
releases, composer also provided as a phar file, phpdocumentor also
available as a phar file, etc.
I only talking about my personal experience, but it seems to me that
currently phar is the preferred method for shipping single file php
applications out there.


So by "preferred" what you really meant was "most widely used".  Okay, I can accept that.  Of course what is widely used is often simply what is available, rather than what one would really prefer if other options were available.



  for shipping an application in a

single file, as it is allows you to work those files and directories in
the
phar via most php functions as those would be normal files/directories on
the disk so stuff like __LINE__ would point a valid path.



The objective is not to perpetuate the idiocy of includes but to obviate
it.



I fail to see how includes are an idiocy in general, similarly there is no
clear winner in the dynamic linking vs static linking,  but depends on your
usecase.


The world of the conceptual is a very large place, and those of us who work in the software arena are often confused by the sheer multiplicity of options and approaches while being simultaneously frustrated that most of them amount to workarounds that create as many problems as they solve.  More below.


 From your primary comment I missed that your main reason for bundling
everything into one file was for portability, depending on your userbase I
would say that some dependency management tool (composer comes to mind)
would serve that goal better, see:
http://www.phptherightway.com/#dependency_management



Thank you for the link.  I really am not interested in a package manager that will conveniently download even more packages and add to the ever-increasing clutter, but thank you for the consideration.

I started this thread with what I thought was a fairly simple technical question about PHP, under the impression that others might know of some functionality that is even more poorly documented than the usual and thus mostly unknown to the general user community.  Terry Ellison pointed out that this list is specifically for discussion of PHP language modifications, and as such my initial question (and of course all subsequent discussion) was misplaced.

As such it would probably be best not to extend the discussion indefinitely.  I will leave you with a few comments:

1. If the purpose of an application is to restore the operating system from a backup, or install an operating system onto a virgin machine, or any of a host of other similar functions, external dependencies are deadly because if any is imperfectly "installed" the whole falls apart and the user has nothing.

2. The concept of include files was a bad one from the start, but in those days (mostly the 1960s and early 1970s) there were no better alternatives and not much available to build them with.  Interpreters were toys because of hardware limitations, and includes were compile-time artifacts which quickly became even more detrimental than they were to begin with once conditional compilation was added to the picture.  Every time a new condition was added in an include file, the number of regression tests required to validate the resulting executables was multiplied.  Since full regression testing is a drag on profits, the approach of stopping when the few most common configurations had been tested became the "preferred" approach within most of the industry.

Perhaps that will provide some perspective to the approach that I am taking here.  Any further discussion should not appear in this mailing list, and FFS not in my personal email; perhaps the newsgroup "comp.lang.misc" would be a reasonable venue if anyone cares to pursue the general topic.

Thank you all for your patience, farewell.

Thread (11 messages)

« previous php.internals (#68328) next »