Having slept on the discussion about people today expecting users each
to have their own environment, I came to the something of an impasse.
How many Linux installations run a package manager that allows
individual users to install their own versions of
Apache/PHP/Database/Git/Hg and so on. The whole point being that the
machine has a consistent framework that everybody knows. Even adding
extensions to PHP they will be added to the single version, which is why
I expect extensions like 'composer' to be installed centrally so when I
run it I know it's the same version that every other tech is using.
Now I have no problem with each user pulling their own clone of the code
via Git or Hg and creating their own 'play area' to check out bugs and
there is nothing to stop them running multiple copies of the PHP code
against the central web services. They are testing in parallel with the
live code in an identical environment. But obviously it would be safer
to have a second mirror machine installed with the same version of
distribution on which to test, and in an ideal world one would update
the development machine, run all the test and ensure there are no
problems before allowing the production machine to roll over. I did say
ideal ;) Most sites will skip whole major versions of updates simply
becuase their production system IS working ...
Back to PEAR ... what happens if I simply install a copy of composer
centrally and rename it 'PEAR'. composer.phar simply gets installed
centrally and any new tech has access without having to install their
own copy. As with Git/Hg users can have their own play areas USING
composer, but to be honest from a safety point of view one knows that
the version of composer being run has not been infected with some
injection mechanism. We keep going on about validating the PHP code
against malicious attack, but the whole framework is open to that?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2016-09-09 10:39 GMT+02:00 Lester Caine lester@lsces.co.uk:
Having slept on the discussion about people today expecting users each
to have their own environment, I came to the something of an impasse.
How many Linux installations run a package manager that allows
individual users to install their own versions of
Apache/PHP/Database/Git/Hg and so on.
Package managers using the central repositories usually don't allow this.
But it's only possible because the distribution team carefully watches that
the packages in the repository are compatible. The same might not be true
for two different PHP apps deployed on the same server. They could have
conflicting dependency version constraints. It's not possible in PHP to
load two different versions of a class at a time.
The whole point being that the
machine has a consistent framework that everybody knows.
That's exactly what Composer provides: A consistent state that pins
dependencies to commits. Everyone will get the same environment, even on
other machines.
Even adding
extensions to PHP they will be added to the single version, which is why
I expect extensions like 'composer' to be installed centrally so when I
run it I know it's the same version that every other tech is using.
Composer isn't an extension. It's pure userland code. But you can and often
it is indeed installed globally, e.g. in /usr/local/bin/composer. If you
use Ubuntu, there it's even included in the main repositories since 16.04:
sudo apt-get install composer.
But note: We're talking about installing the package manager globally here,
not the dependencies per project. Dependencies per project should be
installed per project and not globally.
Now I have no problem with each user pulling their own clone of the code
via Git or Hg and creating their own 'play area' to check out bugs and
there is nothing to stop them running multiple copies of the PHP code
against the central web services. They are testing in parallel with the
live code in an identical environment. But obviously it would be safer
to have a second mirror machine installed with the same version of
distribution on which to test, and in an ideal world one would update
the development machine, run all the test and ensure there are no
problems before allowing the production machine to roll over. I did say
ideal ;) Most sites will skip whole major versions of updates simply
becuase their production system IS working ...
Which is usually fine as long as the old major still receives support in
form of security updates. If the old major is no longer maintained, you
should switch, otherwise you risk being exposed to known security
vulnerabilities. But not upgrading doesn't have anything to do with HOW the
dependencies are managed. Except that it's pretty easy to consume semver
updates with Composer.
Back to PEAR ... what happens if I simply install a copy of composer
centrally and rename it 'PEAR'.
Why rename it to PEAR? It's a different tool. Just call it Composer as it's
named.
composer.phar simply gets installed
centrally and any new tech has access without having to install their
own copy.
That's entirely fine as said. New tech should still install their own
version of the repository and install the dependencies there.
Regards, Niklas
As with Git/Hg users can have their own play areas USING
composer, but to be honest from a safety point of view one knows that
the version of composer being run has not been infected with some
injection mechanism. We keep going on about validating the PHP code
against malicious attack, but the whole framework is open to that?--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Back to PEAR ... what happens if I simply install a copy of composer
centrally and rename it 'PEAR'.
Why rename it to PEAR? It's a different tool. Just call it Composer as it's
named.
My point was just that as has already been established. composer can do
the same thing as PEAR. All that matters is that everybody is working
from the same global installation. The composer.json/composer.lock that
controls a particular installed application is secure to that
application not an individuals account.
composer.phar simply gets installed
centrally and any new tech has access without having to install their
own copy.That's entirely fine as said. New tech should still install their own
version of the repository and install the dependencies there.
Then you have never had a full security audit of your systems! A new
user should NEVER install their own version of anything relating to the
running system. THAT is a potential hole in the security of the system.
The new user should simply be given access to the locked down code
already installed.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Back to PEAR ... what happens if I simply install a copy of composer
centrally and rename it 'PEAR'.
Why rename it to PEAR? It's a different tool. Just call it Composer as
it's
named.My point was just that as has already been established. composer can do
the same thing as PEAR. All that matters is that everybody is working
from the same global installation. The composer.json/composer.lock that
controls a particular installed application is secure to that
application not an individuals account.
usually what's best it that you learn the new tool and apply it to your use
case instead of trying to make it work the same way as your previous tool
blindly.
composer.phar simply gets installed
centrally and any new tech has access without having to install their
own copy.That's entirely fine as said. New tech should still install their own
version of the repository and install the dependencies there.Then you have never had a full security audit of your systems! A new
user should NEVER install their own version of anything relating to the
running system. THAT is a potential hole in the security of the system.
The new user should simply be given access to the locked down code
already installed.
not sure I understand who is a user in that example.
are you arguing that your developers shouldn't ever be allowed to change
code? (allowing them to install dependencies is basically the same as
allowing them to change code)
if that's true why would you have developers in the first place?
changing code is fine, as long as you can audit those changes before it
goes to production and if you can make sure that the audited code will be
the same that goes to production.
the current industry best practice is to separate the build and deployment
steps, so you can inspect and verify your application before those two
steps.
with composer that usually means that you won't ever execute composer
install on your production machines, but installing your dependencies is
part of your build process which results in an artifact (which can be
anything from a directory of files, or a debian package, a docker container
or an amazon AMI) which then can be inspected, installed in isolation, put
through automated testing or manual QA then you can release it without any
chance that it will be different from what you ispected.
I'm not saying that everybody needs such complex release workflow, but you
sounded as secure system would be only possible with a system wide PEAR
install but not with composer or application specific dependency
installation in general.
but please, this is really offtopic on this list.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
but please, this is really offtopic on this list.
See my other reply ...
and composer global mode as provided out of the box is NOT an
alternative to installing the sort of production and development -
command line - tools that PEAR currently manages happily. I AM trying to
learn composer, and I can see now how it can be used, but simply passing
the buck to getcomposer is not the way to use it for a default PHP
installation.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
but please, this is really offtopic on this list.
See my other reply ...
and composer global mode as provided out of the box is NOT an
alternative to installing the sort of production and development -
command line - tools that PEAR currently manages happily. I AM trying to
learn composer, and I can see now how it can be used, but simply passing
the buck to getcomposer is not the way to use it for a default PHP
installation.
composer is proven to be capable managing those use-cases but it isn't our
duty to write out the detailed migration guides for every usecase between
PEAR and composer.
our duty as the php-src group is that we provide a way which allows the
management of the pecl extensions (pickle install and maybe providing an
alternative for pecl package) and tell people how can they install PEAR if
they still need it (https://pear.php.net/manual/en/installation.php)
for the record most distributors already decouple PEAR from the base php
install (php-pear is a separate optional package on debian/ubuntu, the
windows binaries doesn't have PEAR at all, you have to manually install it
there, etc.) and from the php-src point of view we only use it to provide a
way of installing pecl extensions, which will be solved with pickle so
while educating people to migrate their workflows from PEAR to composer is
a noble goal, but it isn't our responsibilities and we don't have to solve
that to be able to replace our php c extension management tool shipped with
the core.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hello,
For myself I have adopted the "vagrant vm per project" workflow. I never
mix projects, because while some are "primitive" and do not require
anything beyond a standard install, others have a custom provisioning and
setup stuff. And specific options on the software that can interfere with
other projects.
Not to mention that I do really juggle between 5.5, 5.6 and 7.0 versions
right now (and moving things to 7.0 as I'm able to).
Even for Laravel I do a per project install of homestead. And I also work
under Windows, many of my colleagues do Linux or Mac OS. Having a fully
self-contained projects helps to avoid issues between our systems.
I also do cleanup wm's that I do not need for some time, that clears out
the space on the disks, especially when databases are several GB big.
but please, this is really offtopic on this list.
See my other reply ...
and composer global mode as provided out of the box is NOT an
alternative to installing the sort of production and development -
command line - tools that PEAR currently manages happily. I AM trying to
learn composer, and I can see now how it can be used, but simply passing
the buck to getcomposer is not the way to use it for a default PHP
installation.composer is proven to be capable managing those use-cases but it isn't our
duty to write out the detailed migration guides for every usecase between
PEAR and composer.
our duty as the php-src group is that we provide a way which allows the
management of the pecl extensions (pickle install and maybe providing an
alternative for pecl package) and tell people how can they install PEAR if
they still need it (https://pear.php.net/manual/en/installation.php)
for the record most distributors already decouple PEAR from the base php
install (php-pear is a separate optional package on debian/ubuntu, the
windows binaries doesn't have PEAR at all, you have to manually install it
there, etc.) and from the php-src point of view we only use it to provide a
way of installing pecl extensions, which will be solved with pickle so
while educating people to migrate their workflows from PEAR to composer is
a noble goal, but it isn't our responsibilities and we don't have to solve
that to be able to replace our php c extension management tool shipped with
the core.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
but please, this is really offtopic on this list.
See my other reply ...
and composer global mode as provided out of the box is NOT an
alternative to installing the sort of production and development -
command line - tools that PEAR currently manages happily. I AM trying to
learn composer, and I can see now how it can be used, but simply passing
the buck to getcomposer is not the way to use it for a default PHP
installation.composer is proven to be capable managing those use-cases but it isn't our
duty to write out the detailed migration guides for every usecase between
PEAR and composer.
our duty as the php-src group is that we provide a way which allows the
management of the pecl extensions (pickle install and maybe providing an
alternative for pecl package) and tell people how can they install PEAR if
they still need it (https://pear.php.net/manual/en/installation.php)
for the record most distributors already decouple PEAR from the base php
install (php-pear is a separate optional package on debian/ubuntu, the
windows binaries doesn't have PEAR at all, you have to manually install it
there, etc.) and from the php-src point of view we only use it to provide a
way of installing pecl extensions, which will be solved with pickle so
while educating people to migrate their workflows from PEAR to composer is
a noble goal, but it isn't our responsibilities and we don't have to solve
that to be able to replace our php c extension management tool shipped with
the core.
I'd forgotten the official windows packages no longer had PEAR anyway.
Does make the discussion on that somewhat academic? We have been
installing Linux servers as replacements to the windows boxes so the
need to actually load newer windows builds as been rather rare, and I
was using a stacked version when I did ... which is another alternative
to distributions on windows.
Now that I have got composer under control I can see that it is not
something that fits my own audited security model but I can see how to
provide it as an alternative if I ever get time to update
http://lsces.co.uk/wiki/FWAP64+Setup ... That is at least an area where
I will continue to try and contribute to PHP.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I'd forgotten the official windows packages no longer had PEAR anyway.
Does make the discussion on that somewhat academic? We have been
installing Linux servers as replacements to the windows boxes so the
need to actually load newer windows builds as been rather rare, and I
was using a stacked version when I did ... which is another alternative
to distributions on windows.
Doing some digging I've found the conversations on this back in 2011. At
that time the statement was made that 'php project does not provide
binary builds' and 'if the user can't install a compiler they should not
be using php'. I'll not name the source ... it was a thread on this list
in 2011.
The problem that we were discussing at the time was availability not
only of PHP on windows but also Apache, and the fact that neither
project provides official builds on windows. While there were 'free'
paths to do your own builds on windows and I had documented my own
process at that time. These were NOT acceptable by government agencies
to provide audited installations. Windows applications come pre-compiled
and while I think that the more modern build paths can be download for
free they are not free for commercial use? An 'official' compiled build
is a requirement for windows. Although that does not necessarily need to
be provided by PHP. Apachelounge is an approved source amongst my customers.
I think I am right in saying Pierre originally needed pickle so that
PEAR could be dropped in the windows? So the only element left is
bundling PEAR with the source distribution. I've not had to worry about
PHP7 on windows as yet as the few sites were are allowed to use it are
linux servers, but it will come a point when we need to audit a PHP7
windows installation, along with a web server. And it looks as if while
5 years ago nginx was ahead of apache, the commercialization of the
former is taking it off the play list :( Just when I've got it working
nicely as a background to testing multiple copies of PHP on the same
code. This is about making PHP easily available across the board and
while windows may now be confined to the desktop machine, it is still
more popular than linux on commercial and government systems?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I'd forgotten the official windows packages no longer had PEAR anyway.
Does make the discussion on that somewhat academic? We have been
installing Linux servers as replacements to the windows boxes so the
need to actually load newer windows builds as been rather rare, and I
was using a stacked version when I did ... which is another alternative
to distributions on windows.Doing some digging I've found the conversations on this back in 2011. At
that time the statement was made that 'php project does not provide
binary builds' and 'if the user can't install a compiler they should not
be using php'. I'll not name the source ... it was a thread on this list
in 2011.
interesting, could you direct me to the thread at least?
I couldn't find anything with those exact quotes and I'm subscibed to the
list longer than 2011.
the only platform we provide binaries is windows,but we provide official
windows binaries since like forever (and least as I can go back in history,
php 3.0.11 at least), so that quote is either incorrect, or comes from
somebody uninformed, or have some specific context you are not quoting with
it.
The problem that we were discussing at the time was availability not
only of PHP on windows but also Apache, and the fact that neither
project provides official builds on windows.
as I mentioned before (and mentioned in every release announcement) php
does indeed provide official windows binaries, you are correct that apache
http project does not.
While there were 'free'
paths to do your own builds on windows and I had documented my own
process at that time. These were NOT acceptable by government agencies
to provide audited installations. Windows applications come pre-compiled
and while I think that the more modern build paths can be download for
free they are not free for commercial use?
I'm not sure what do you mean by this, but this probably depends on your
own policies and the distributions you decide to grab your builds from.
An 'official' compiled build
is a requirement for windows. Although that does not necessarily need to
be provided by PHP. Apachelounge is an approved source amongst my
customers.
yeah, Apache Lounge is one of the available option to grab apache http
binaries for windows, and also endorsed by the apache httpd team:
https://httpd.apache.org/docs/current/platform/windows.html
I think I am right in saying Pierre originally needed pickle so that
PEAR could be dropped in the windows?
Not sure why did you get that idea, as mentioned before the windows team
already unbundled PEAR from the core since 5.3 or so (which imo makes sense
as pecl wasn't really an option for building and installing pecl extensions
on windows).
So the only element left is
bundling PEAR with the source distribution. I've not had to worry about
PHP7 on windows as yet as the few sites were are allowed to use it are
linux servers, but it will come a point when we need to audit a PHP7
windows installation, along with a web server. And it looks as if while
5 years ago nginx was ahead of apache, the commercialization of the
former is taking it off the play list :( Just when I've got it working
nicely as a background to testing multiple copies of PHP on the same
code. This is about making PHP easily available across the board and
while windows may now be confined to the desktop machine, it is still
more popular than linux on commercial and government systems?
sorry, can't really decipher this part, maybe it's just me.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Doing some digging I've found the conversations on this back in 2011. At
that time the statement was made that 'php project does not provide
binary builds' and 'if the user can't install a compiler they should not
be using php'. I'll not name the source ... it was a thread on this list
in 2011.
I must clarify that as I was quoting from memory since I'd failed to
bookmark the thread and apologise I over egged it ...
http://develissimo.com/forum/topic/104953/?page=5
So the correct quotes are
"I don't consider it our job to do binary builds for people."
and
"If people are building critical
systems that rely on binary-only releases, they really should reconsider
how they do things and at the very least install a compiler on their
platform of choice and learn how to build stuff themselves."
While that sentiment is practical for Linux based systems, until
recently it was an expensive investment to create the same environment
on Windows? I have not yet tried to check out a build stack on Windows
10, but for the vast majority of PHP users it is not a practical option?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Doing some digging I've found the conversations on this back in 2011. At
that time the statement was made that 'php project does not provide
binary builds' and 'if the user can't install a compiler they should not
be using php'. I'll not name the source ... it was a thread on this list
in 2011.I must clarify that as I was quoting from memory since I'd failed to
bookmark the thread and apologise I over egged it ...http://develissimo.com/forum/topic/104953/?page=5
So the correct quotes are
"I don't consider it our job to do binary builds for people."and
"If people are building critical
systems that rely on binary-only releases, they really should reconsider
how they do things and at the very least install a compiler on their
platform of choice and learn how to build stuff themselves."While that sentiment is practical for Linux based systems, until
recently it was an expensive investment to create the same environment
on Windows? I have not yet tried to check out a build stack on Windows
10, but for the vast majority of PHP users it is not a practical option?
Despite the rather common myth, building PHP on Windows nowadays is not
really harder than on Linux. Detailed instructions are available on
https://wiki.php.net/internals/windows/stepbystepbuild.
--
Christoph M. Becker
Despite the rather common myth, building PHP on Windows nowadays is not
really harder than on Linux. Detailed instructions are available on
https://wiki.php.net/internals/windows/stepbystepbuild.
http://lsces.co.uk/wiki/Compile+PHP7+Build+on+Windows+10
But while the licensing is fairly loose for individual developers, I
doubt that any government IT department could get passed the
'enterprise' restrictions on use ... which was the block on earlier
options for building windows versions as well.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Despite the rather common myth, building PHP on Windows nowadays is not
really harder than on Linux. Detailed instructions are available on
https://wiki.php.net/internals/windows/stepbystepbuild.
Wrt. concrete build problems, I suggest asking on an appropriate mailing
list or support forum, such as php-windows@lists.php.net.
But while the licensing is fairly loose for individual developers, I
doubt that any government IT department could get passed the
'enterprise' restrictions on use ... which was the block on earlier
options for building windows versions as well.
The licensing of Visual Studio doesn't appear to be a PHP issue.
Support for other toolchains may be added; patches are welcome! :-)
--
Christoph M. Becker
Despite the rather common myth, building PHP on Windows nowadays is not
really harder than on Linux. Detailed instructions are available on
https://wiki.php.net/internals/windows/stepbystepbuild.Wrt. concrete build problems, I suggest asking on an appropriate mailing
list or support forum, such as php-windows@lists.php.net.
I have already debugged the problems and will tidy up the notes later
when I cross check things. This is the sort of support I've always
provided to the PHP project. The pages relating to the compile process
on the php wiki need bringing up to date but I don't think I have access
to do that with my wiki login. One key element which a newcomer may miss
is the 'command prompt' needs to be the special command prompt VS15
generates rather than 'just a command prompt'. I'd actually managed to
pick up the wrong link because of the ARM tools install. It's also
confusing if one has come from a Linux base and are used to a command
prompt just working :) I will pad that out on my wiki page ... when time
permits.
But while the licensing is fairly loose for individual developers, I
doubt that any government IT department could get passed the
'enterprise' restrictions on use ... which was the block on earlier
options for building windows versions as well.The licensing of Visual Studio doesn't appear to be a PHP issue.
Only if the 'official' installation path requires use of software that
has restricted licensing. While there are binary builds for windows
there is not a problem, but if a replacement pecl path required the use
of Microsoft tools the licensing does become a problem.
Support for other toolchains may be added; patches are welcome! :-)
Again something I have tried to maintain in the past, but the volume of
work on the TODO list is delaying bringing many of the old crib sheets
up to date. This latest one is the first since 2011 :( I can see a way
to package 'composer' to provide a centrally available tool, but it will
take some time to work out how to dovetail it into the other package
management systems. Looking to 'update' to composer when I'm also trying
to update a working javascript set-up is part of the current hold up on
completing an improved form validation upgrade ... do I need either
package handlers? Not currently since everything is under DVCS already.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I have already debugged the problems and will tidy up the notes later
when I cross check things. This is the sort of support I've always
provided to the PHP project. The pages relating to the compile process
on the php wiki need bringing up to date but I don't think I have access
to do that with my wiki login. One key element which a newcomer may miss
is the 'command prompt' needs to be the special command prompt VS15
generates rather than 'just a command prompt'.
Hm, the Wiki page states:
| If compiling PHP 7.0+ open either the “VS2015 x64 Native Tools
| Command Prompt” or the “VS2015 x86 Native Tools Command Prompt”.
The licensing of Visual Studio doesn't appear to be a PHP issue.
Only if the 'official' installation path requires use of software that
has restricted licensing. While there are binary builds for windows
there is not a problem, but if a replacement pecl path required the use
of Microsoft tools the licensing does become a problem.
I don't see why a replacement for pecl would have other licensing issues
as pecl.
Support for other toolchains may be added; patches are welcome! :-)
Again something I have tried to maintain in the past, but the volume of
work on the TODO list is delaying bringing many of the old crib sheets
up to date.
I guess, we all have more on our TODO list than we can actually manage. :-)
--
Christoph M. Becker
I have already debugged the problems and will tidy up the notes later
when I cross check things. This is the sort of support I've always
provided to the PHP project. The pages relating to the compile process
on the php wiki need bringing up to date but I don't think I have access
to do that with my wiki login. One key element which a newcomer may miss
is the 'command prompt' needs to be the special command prompt VS15
generates rather than 'just a command prompt'.Hm, the Wiki page states:
| If compiling PHP 7.0+ open either the “VS2015 x64 Native Tools
| Command Prompt” or the “VS2015 x86 Native Tools Command Prompt”.
As it's a couple of levels deep the prompt in my crib sheet was to how
to find them, but a little explanation on why you need to use a special
command line prompt for people who ARE coming from a click and go
environment will be helpful.
The licensing of Visual Studio doesn't appear to be a PHP issue.
Only if the 'official' installation path requires use of software that
has restricted licensing. While there are binary builds for windows
there is not a problem, but if a replacement pecl path required the use
of Microsoft tools the licensing does become a problem.I don't see why a replacement for pecl would have other licensing issues
as pecl.
It's the same problem as has always existed with the free tools only
being licensed for non-commercial use. As long as binary files are
available there is not a problem, but the fine detail of licences seems
to change with every new release?
Support for other toolchains may be added; patches are welcome! :-)
Again something I have tried to maintain in the past, but the volume of
work on the TODO list is delaying bringing many of the old crib sheets
up to date.I guess, we all have more on our TODO list than we can actually manage. :-)
I seem to be making some progress finally on starting switching
production machines to PHP7.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I have already debugged the problems and will tidy up the notes later
when I cross check things. This is the sort of support I've always
provided to the PHP project. The pages relating to the compile process
on the php wiki need bringing up to date but I don't think I have access
to do that with my wiki login. One key element which a newcomer may miss
is the 'command prompt' needs to be the special command prompt VS15
generates rather than 'just a command prompt'.Hm, the Wiki page states:
| If compiling PHP 7.0+ open either the “VS2015 x64 Native Tools
| Command Prompt” or the “VS2015 x86 Native Tools Command Prompt”.As it's a couple of levels deep the prompt in my crib sheet was to how
to find them, but a little explanation on why you need to use a special
command line prompt for people who ARE coming from a click and go
environment will be helpful.
Simply because php does not generate solution project files. It is
nearly impossible to support all version, while recent VS tends to
change less from one version to another.
The licensing of Visual Studio doesn't appear to be a PHP issue.
Only if the 'official' installation path requires use of software that
has restricted licensing. While there are binary builds for windows
there is not a problem, but if a replacement pecl path required the use
of Microsoft tools the licensing does become a problem.I don't see why a replacement for pecl would have other licensing issues
as pecl.It's the same problem as has always existed with the free tools only
being licensed for non-commercial use. As long as binary files are
available there is not a problem, but the fine detail of licences seems
to change with every new release?
This statement is wrong. Please check the VS/VC license, the free one.
Commercial usage is just fine.
Also a large majority of users do not need it, neither they need
gcc/icc as they will simply used the respective binaries.
That being said, on windows we do provide PGO builds, which bring a
significant performance gain. It is possible to do it yourself too but
I am not sure why one would go through that :)
Support for other toolchains may be added; patches are welcome! :-)
Again something I have tried to maintain in the past, but the volume of
work on the TODO list is delaying bringing many of the old crib sheets
up to date.I guess, we all have more on our TODO list than we can actually manage. :-)
I seem to be making some progress finally on starting switching
production machines to PHP7.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I have already debugged the problems and will tidy up the notes later
when I cross check things. This is the sort of support I've always
provided to the PHP project. The pages relating to the compile process
on the php wiki need bringing up to date but I don't think I have access
to do that with my wiki login. One key element which a newcomer may miss
is the 'command prompt' needs to be the special command prompt VS15
generates rather than 'just a command prompt'.Hm, the Wiki page states:
| If compiling PHP 7.0+ open either the “VS2015 x64 Native Tools
| Command Prompt” or the “VS2015 x86 Native Tools Command Prompt”.As it's a couple of levels deep the prompt in my crib sheet was to how
to find them, but a little explanation on why you need to use a special
command line prompt for people who ARE coming from a click and go
environment will be helpful.Simply because php does not generate solution project files. It is
nearly impossible to support all version, while recent VS tends to
change less from one version to another.
Pierre ... I have no problem here ... I'm simply trying to do what I did
15 years ago when I first created crib sheets to help ME work out how to
make things happen. Often things that are obvious to someone who has
grown up with a system need a different perspective when helping others
get up to speed.
The licensing of Visual Studio doesn't appear to be a PHP issue.
Only if the 'official' installation path requires use of software that
has restricted licensing. While there are binary builds for windows
there is not a problem, but if a replacement pecl path required the use
of Microsoft tools the licensing does become a problem.I don't see why a replacement for pecl would have other licensing issues
as pecl.It's the same problem as has always existed with the free tools only
being licensed for non-commercial use. As long as binary files are
available there is not a problem, but the fine detail of licences seems
to change with every new release?This statement is wrong. Please check the VS/VC license, the free one.
Commercial usage is just fine.
Off topic I know, but can you provide a link. I need to update a couple
of audit documents which include getting PHP7 listed with the options
for on-going support. People do like to push the high priced commercial
alternatives claiming open source is not really free :(
Also a large majority of users do not need it, neither they need
gcc/icc as they will simply used the respective binaries.That being said, on windows we do provide PGO builds, which bring a
significant performance gain. It is possible to do it yourself too but
I am not sure why one would go through that :)
Anything that helps education! And certainly I am still seeing windows
stacks a lot slower than on Linux on the same hardware. What is the
right way to do a windows install?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Back to PEAR ... what happens if I simply install a copy of composer
centrally and rename it 'PEAR'. composer.phar simply gets installed
centrally and any new tech has access without having to install their
own copy.
This is more or less how I've always used it: we don't call it "pear", but composer is placed in /usr/bin so it can be run the same way as any system command. It can be upgraded by anyone with sudo rights by running "sudo composer self-update". This makes sense to me, as that's where you'd put, say, a C compiler.
Others put a local copy in with their source code, so that they can easily build the code on different boxes which might not have a copy.
The important thing with composer is not where you put the tool you use to build things, but where you put the things you've built. It's similar to distributing DLLs for a Windows application: do you assume / ensure that the libraries and versions you've built against exist in the system directory (the global install that PEAR defaults to) or do you consider them part of your application, versioned and deployed as part of it (the local install that Composer defaults to).
So it's not really about "play areas" or safety, it's just a philosophical and practical question of which approach is "best".
Regards,
--
Rowan Collins
[IMSoP]
Having slept on the discussion about people today expecting users each
to have their own environment, I came to the something of an impasse.
How many Linux installations run a package manager that allows
individual users to install their own versions of
Apache/PHP/Database/Git/Hg and so on.
usually it isn't the distributions jobs to do that thanks to the spread of
virtualization and containerization but even distros moved to a direction
where you can install multiple versions in parallel or run multiple
instances of a service with different config.
some distros like gentoo supported this since forever, others only changed
recently (for example Ubuntu changed their package naming scheme with the
latest lts which is a big step to the parallel versions), and there were
other projects which was created for the specific purpose of installing and
running multiple versions in parallel (https://github.com/cweiske/phpfarm
and https://github.com/phpenv/phpenv for example)
and if we move away from php, and check out other similar languages like
python or ruby, they also moved to the direction of allowing the
application to specify it's own environment:
with ruby they have https://github.com/rbenv/rbenv
https://github.com/rvm/rvm to let apps specify their ruby environment, and
there is also https://github.com/chef/omnibus for creating a self contained
application which brings it's own embeddid environment so it has zero
external dependency.
with python you https://github.com/pypa/virtualenv and have
https://github.com/yyuu/pyenv and there is a tool (
https://github.com/pantsbuild/pex) which can be used to create a single
executable file which contains and executes your python application
together which it's dependencies.
The whole point being that the
machine has a consistent framework that everybody knows. Even adding
extensions to PHP they will be added to the single version, which is why
I expect extensions like 'composer' to be installed centrally so when I
run it I know it's the same version that every other tech is using.
this is the old school way of doing this, and was mostly superseded because
each application has it's own set of requirement (for dependencies and for
configuration options) and when you want to manage multiple applications in
a single environment it will be either hard or impossible.
of course the system wide installation philosophy is still fine as long as
you only manage a single application in that system.
Now I have no problem with each user pulling their own clone of the code
via Git or Hg and creating their own 'play area' to check out bugs and
there is nothing to stop them running multiple copies of the PHP code
against the central web services. They are testing in parallel with the
live code in an identical environment. But obviously it would be safer
to have a second mirror machine installed with the same version of
distribution on which to test, and in an ideal world one would update
the development machine, run all the test and ensure there are no
problems before allowing the production machine to roll over. I did say
ideal ;)
indeed, and you want to have a reproducible environment for other reasons
too.
Most sites will skip whole major versions of updates simply
becuase their production system IS working ...
usually it is easier to migrate in multiple smaller steps, but of course
there are people who will do the one big upgrade.
Back to PEAR ... what happens if I simply install a copy of composer
centrally and rename it 'PEAR'. composer.phar simply gets installed
centrally and any new tech has access without having to install their
own copy.
as I and others mentioned before composer does user/system wide
installations: https://getcomposer.org/doc/03-cli.md#global but not sure
what do you mean renaming it to PEAR, they have different command line
format, etc. you can't just rename it and expect it to work.
As with Git/Hg users can have their own play areas USING
composer, but to be honest from a safety point of view one knows that
the version of composer being run has not been infected with some
injection mechanism. We keep going on about validating the PHP code
against malicious attack, but the whole framework is open to that?
not sure I follow what are you trying to say here, so from the past your
devs were not allowed to add new PEAR dependencies, but someone else did
that for them? and now you are afraid that if you introduce composer they
will install random packages they will introduce something malicious?
First, if adding PEAR packages was a burden in the past, I'm fairly sure
that you have a couple of PEAR packages just manually committed to you
repository as part of your project.
with composer you don't push your dependencies to your repository, but with
the composer.lock you can guarantee that installing the dependencies will
be reproducible and you can scan/review your dependencies either
periodically or on-demand when your composer.lock has been changed.
also, if you want, you can opt-out from using https://packagist.org/ and
either explicitly use git trusted git repositories as package source, or
even use your own trusted mirrors.
but this isn't a topic for internals@, but more suited for
https://groups.google.com/forum/#!forum/composer-users
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Most sites will skip whole major versions of updates simply
becuase their production system IS working ...usually it is easier to migrate in multiple smaller steps, but of course
there are people who will do the one big upgrade.
Many of the sites I work on had not managed to complete testing and
re-writing of systems for W7 when XP was end of lifed. So XP is still
running on critical systems. The work done to move to W7 fails again on
W10 so once again the whole process has to be repeated. My PHP code
running on those sites goes back to the late 1990's and is still doing
the job it needs to do. The problem with 'smaller steps' is you need to
have the resources to complete on step before the next one rolls up, and
in the 'bad old days' when PHP fixes were slow to appear it WAS possible
to keep up. Today PHP5.3->4 is STILL a hold up for these sites when
there are so many other updates to keep track of. If I could wave a
magic wand and every legacy system just worked on the next 'small step' ...
Back to PEAR ... what happens if I simply install a copy of composer
centrally and rename it 'PEAR'. composer.phar simply gets installed
centrally and any new tech has access without having to install their
own copy.as I and others mentioned before composer does user/system wide
installations: https://getcomposer.org/doc/03-cli.md#global but not sure
what do you mean renaming it to PEAR, they have different command line
format, etc. you can't just rename it and expect it to work.
As I said elsewhere ... just the idea that installing PHP_CodeSniffer
and similar tools in the same central manor that PEAR makes them
available could be an alternative base.
As with Git/Hg users can have their own play areas USING
composer, but to be honest from a safety point of view one knows that
the version of composer being run has not been infected with some
injection mechanism. We keep going on about validating the PHP code
against malicious attack, but the whole framework is open to that?not sure I follow what are you trying to say here, so from the past your
devs were not allowed to add new PEAR dependencies, but someone else did
that for them? and now you are afraid that if you introduce composer they
will install random packages they will introduce something malicious?
First, if adding PEAR packages was a burden in the past, I'm fairly sure
that you have a couple of PEAR packages just manually committed to you
repository as part of your project.
with composer you don't push your dependencies to your repository, but with
the composer.lock you can guarantee that installing the dependencies will
be reproducible and you can scan/review your dependencies either
periodically or on-demand when your composer.lock has been changed.
also, if you want, you can opt-out from using https://packagist.org/ and
either explicitly use git trusted git repositories as package source, or
even use your own trusted mirrors.
but this isn't a topic for internals@, but more suited for
https://groups.google.com/forum/#!forum/composer-users
That a user can 'just install' their own copy of something is the
problem once one moves to the production environment. And yes just
adding or updating any library to a production system needs to be
properly managed. If the default installation of PHP provides for a
default way of adding extensions and user land code it should be to the
default installation of PHP. Off the shelf, composer is not following
that model even for the initial installation of the code, so is out of
sync with the CURRENT installation model of PHP. Now the current model
may well be old fashioned, but there is no clear alternative to replace
it, so if an element of that model such as PEAR needs to be replaced
with an alternative such as composer, the alternative should be used in
a manor that fits the overall installation model?
Now if there is a more modern installation model which better fits the
way composer sees the world, then the whole installation process should
be changed to that?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk