Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24943
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <06c801c6af4a$442c1c20$6602a8c0@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: <internals@lists.php.net>
References: <2a9adcf0607240752k12eb8f32sd753eaadaac6e8cc@mail.gmail.com> <064e01c6af3b$685f86e0$6602a8c0@foxbox> <2a9adcf0607241006m102e0f3eu9dd562cd40eac004@mail.gmail.com> <2a9adcf0607241018o3afce85dk28b3fa794a2442fd@mail.gmail.com>
Date: Mon, 24 Jul 2006 19:54:51 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New Installer for PHP 5.2
From: steph@zend.com ("Steph Fox")

Hi John

>> 1) I didn't notice anywhere to choose the path for the install. (This 
>> might
>> be because I only tested with cli?) That makes it kinda hard to figure 
>> out
>> where the installed version went :) I eventually found it in PROGRA~1, 
>> which
>> might be the default for registry-based installations but was (perhaps
>> strangely) not where I'd have immediately expected it to be from a 
>> desktop
>> test install.
>> 2) Same goes for the php.ini, the whereabouts of which can be fairly
>> critical depending on the setup.
>> (Those two I think are probably important.)
>
> On the page where you choose the components to install, you'll see the
> location underneath the tree widget, with a browse button to locate
> where to put it. It's somewhat non-obvious though, I'm not sure how
> much of an issue it is ( I know many MSI based installers are laid out
> in the same fashion ).

Too much information on that page, is why I didn't notice it. I think it 
probably
needs a design rethink, but see what other feedback you get - it's been a 
long
day here ;)

>> 3) is there some way to have (version-compatible) components 'install on
>> demand', rather than download the whole lot at one go?
>> (Would be useful if...)
>
>
>
>> 4) enabling extensions via the installer at present simply means adding 
>> them
>> to the end of the existing php.ini, i.e. the same module can be listed
>> twice, once disabled and once enabled. Is there no way to do a search and
>> replace on the existing string or simply write that part of the file from
>> scratch? - because at present, people will still need to make manual
>> modifications to their .ini following installation, and it's confusing.
>
> What I'll probably do is remove the extension directives from where
> they normally are and keep them at the bottom; this is in line with
> how many packages that edit the php.ini file work.

Yep good - note a few minor problems with layout though:

; Local Variables:
; tab-width: 4
; End:
[PHP_JSON]
extension=php_json.dll

- it shouldn't be after vi settings (simply write them last?), and
'extension' is not a PHP_JSON directive - it's a [PHP] directive and should
be part of the main clause.

>> 5) is there - or will there be - a way to update components via the
>> installer? or even the core? (would mean disabling/deleting 
>> non-compatible
>> components)
>
> It will support upgrading from one PHP version to another, and will
> upgrade the included components that come with that version.

That's very cool, but it also needs to check the version compatibility of
whatever PECL-only extensions happen to be loaded... otherwise there's a
chance they'll mysteriously stop working.

>> 6) is there - or will there be - any way to set up the chosen server
>> configuration via the installer (for all servers or even just for 
>> Apache?) -
>> again, I didn't test with a server install so this might be in place
>> already.
>
> IIS CGI and Xitami will be configured automatically ( and we could add
> Sambar to that list if there is interest ), but Apache uses a wierd
> config file format that I don't have a good tool to edit.

httpd.conf's weird? It's only a text file :) the complication's in the fact
that there's more than one way to set it up. But you could offer automated
basic CGI setups pretty easily using the paths you've already been given for
php.exe and php.ini, and the module setup actually isn't that complicated
either, assuming you already know it's an apache module setup that's
required.

>> 7) how about further php.ini modifications? - remembering that the 
>> existence
>> of many directives depends on the extensions installed.
>> (These come under 'would be sweet if...')
>
> We do many of these, such as enabling cgiforceredirect,
> upload_tmp_dir, and session.save_path, along with adding Registry Keys
> and Enviroment variables that are needed under Windows ( after install
> try typing 'php -v' at the command line and it should find the PHP
> install correctly ). I also register .php files to open with
> php-win.exe if you install the 'Script Program' option.

Actually typing php -v and php -m was how I found out it was registered :)
Didn't know you'd set some of those options because I only tested a couple
of odd extensions to see how it was set up. That said, gd was one of those
extensions, and I didn't see an option to reset gd.jpeg_ignore_warning - did
you only look at directives involving paths for now?

>> Further comment: I personally think it creates more problems than it 
>> solves
>> to differentiate between core and PECL extensions. IMHO it'd be better to
>> throw them all together in alphabetical order and simply have everything
>> 'already on' that is enabled by default. This'll also help when items get
>> shifted around, as they inevitably do... components shipped with the core
>> that aren't yet in PECL would need to be downloaded with the core anyway
>> because there's no other way to reach them individually, so there _is_ 
>> that
>> difference, but that 'core list' is not writ in stone and changes quite
>> frequently.
>
> I agree and disagree. While it will be simplier to install the
> extensions, it would also be helpful to know which ones *are*
> supported and which ones *are not*. I'd welcome any suggestions here.

Well, since there's no way to get that information anyway until you try to
download a .dll that doesn't exist or is incompatible with the version of
PHP you're running, I'd suggest trying to download a .dll and producing
error messages in those cases. Everything in PECL (that is released at all)
has a package.xml file that contains all sorts of useful information
regarding versioning, requirements and maintenance status... perhaps ask
Edin to supply that file via a channel that also supplies the .dll (where it
exists)?  (Note: my understanding of channels is very, very hazy and I'm
probably sending you the wrong direction by even using the term, but Edin'll
know what I mean...)

>> oh ps - PEAR install yes/no doesn't appear to work - you get .phar either
>> way. Is that intentional for now?
>
> WFM, can anyone else confirm this?

My bad, I didn't spot that it's enabled by default. Back to the TMI thing...
I honestly think you should split that page into separate serial pages for
a) the actual PHP install, b) the server stuff, c) the extensions, d)
peripherals (aka PEAR and docs). I'm not a naive user by any stretch of the
imagination, but I'm missing things all over the shop on that page.

- Steph

> Thanks for the feedback....
>
> -- 
> Later,
>
> John Mertic
> "Explaining a joke is like dissecting a frog: you
> jmertic@gmail.com                                       understand it
> better, but the frog dies in the
>
> process."
>
>                                             -Mark Twain