I'm trying to fix a bug in a more complex PEAR package (CodeCoverage). So I'd like to have the development version that exists not within my PEAR path:
c:\Programme\PHP\PEAR\PHP
with one on another location, here exemplary:
c:\Dokumente und Einstellungen\hakre\PhpstormProjects\php-code-coverage\PHP\
Is there a common way in PEAR to temporarily switch from the installed package to just the files on another location of the disk?
I tried with placing a symbolic link, but that does not work because I need to link CodeCoverage.php as well which is not possible on Windows XP.
Is there some kind of development switch for this kind of scenario in PEAR or is it just that it's the business of each package to take care of that?
I'm using the CodeCoverage package together with PHPUnit.
I could get it to work by adding it to PHP's include path before the PEAR dir:
include_path = ".;c:\path\to\php-code-coverage;C:\programme\php\pear"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Invoking PHPUnit now uses the standard package but the development version of CodeCoverage. No symbolic linking required, editing php.ini is enough.
The "Contributing" section of the PHPUnit github project has a runner script included to make that task easier for you.
You can ether check out all the repositories from there or, if you only need one, still use the runner script:
#!/bin/bash
php -d include_path='.:../phpunit/:../dbunit/:../php-code-coverage/:../php-file-iterator/:../php-invoker/:../php-text-template/:../php-timer:../php-token-stream:../phpunit-mock-objects/:../phpunit-selenium/:../phpunit-story/:/usr/local/lib/php' ../phpunit/phpunit.php $*
(intentially not formatted as code so the whole thing is shown)
You can adapt the pathes to an absolute one by replacing .. with /path/to/your/dev/folder/ and put the script in /usr/local/bin/ and call it phpunit-dev.
Then it will automatically pick up all the existing folders and fall back to the pear path at the end for everything it can't find.
Another way to get a dev setup quickly would be to install it from composer with minimum-stability: dev and change the remote on one of the repos :)
Related
Bit of a strange set up but have come across a project where Composer has been used in a local environment to get a project started. The original developer did not have ssh access to the production server therefore he used Composer locally and uploaded the 'vendor' directory from his desktop to the server using FTP.
I now need to add the PHPMailer package so have done the following locally on my Mac:
cd Desktop/
composer require phpmailer/phpmailer
This has created the following structure on my desktop:
Desktop/composer.json
Desktop/composer.lock
Desktop/vendor/autoload.php
Desktop/vendor/composer/*
Desktop/vendor/phpmailer/*
Which of these do I need to upload through FTP? I realise vendor/phpmailer/* is the package I want, so will need uploading.
What about the others? I already have an autoloader configured so guessing vendor/autoload.php is not required here?
composer.json I could add the package to what's already there, e.g.
"require": {
*other packages here*
"phpmailer/phpmailer": "^5.2"
}
But I wasn't sure if that's necessary because I'm not going to be using ssh/Composer on the server to run any updates?
The usual workflow would be:
Checkout the current version from the version control.
Add dependencies via command line composer require new/package.
This will download the new package and update the autoloading.
Test the result locally or on a test website environment.
If happy with the result, upload the whole folder to the production server.
There may be several exceptions from this general workflow:
ad 1: If there is no version control, you'd probably better of starting a local git repo right now, and download the current production state into it as the first commit. Not having version control will make things harder, especially going back to known working versions. And because the files on the production server are probably unmanaged, you'd also check in the vendor folder into your newly created version control just to avoid canceling any changes that had been made to these files.
ad 2: Manually editing the composer.json file sometimes is a faster way to get what you want if you know what you are doing, but you'd have to correctly edit the JSON. For me it usually is too much hassle if I already have a command line ready. The command will also select a matching version that fits into the already installed dependencies. Manual editing may lead to version conflicts that you'd have to untangle. Remember to only install dependencies that work with the PHP version in production. You probably should run composer config platform.php X.Y.Z in order to add the production version of PHP into the composer.json file, which prevents Composer from installing dependency versions based on your development PHP. Adding the -g switch will add this setting to your global (user) setting instead, which will affect all composer operations you start, also for other projects.
ad 3: Manual editing will require you to run composer update on the command line, so there's probably no reason to not do composer require instead.
ad 4: How this could be done is entirely dependent on what environment you have to work with.
ad 5: At this stage you have assembled all files necessary to create a working website. Uploading them to production will always result in a working website unless the upload fails somehow. You could also use some "upload first to temporary folder, then move on the server" approach if you fear FTP would be unreliable. Some people take a different approach: They have a git repository on the production server and they simply push the version that should go live onto that remote repo. Some post-push scripts will run composer install then. This automated approach will also work (but not using FTP), but has the higher risk of something failing during deployment, and probably has no easy way back to the previous situation.
So in the end I'd say that uploading the whole folder structure via FTP (well, that protocol is insecure itself, better replace it with FTPS (FTP with SSL), SFTP or SCP) is better compared to running Composer on the production server.
Your specific question regarding which folders to upload: All of them. Especially upload the whole vendor folder. It contains the current autoloader and all dependency packages the software needs. If you worked correctly, you downloaded the existing composer.json and composer.lock file together with everything else and added the new dependency to it. This has changed both these files, added the new package to the vendor folder and the classes to the autoloader.
Don't fiddle with uploading only parts of the vendor folder, or manually editing a component of the autoloading. You will only create surprises for the developer coming after you if you do some aspect incorrectly, and it also takes more time. Composer is a very good tool to manage dependencies - use it!
You could copy the composer.json from the server to your local server, add the requirements and run composer update.
After that you can copy all files (composer.json, composer.lock and vendor folder to your server)...
Or you can copy local vendor/phpmailer into servers vendor folder, search for the entry of phpmailer in vendor/composer/autoload_psr4.php and add it to your servers vendor/composer/autoload_psr4.php.
Using this method also add phpmailers dependencies the same way.
composer depends phpmailer/phpmailer
I am trying to get PHPUnit working on my cakePHP application.
I have downloaded and setup all the necessary files
In my php.ini file , I put
include_path = ".;c:\wamp\bin\php\php5.4.12\pear\PHPUnit"
But I do not think this is correct.
When running cakePHP's app/test.php, I get 2 warnings to include PHPUnit\Autoload.php
Ok, so for whatever reason, no one here decided to hep me out on this one.. Which is a little bit frustrating.. But no matter! I'm going to provide the solution for others whom like me, are new to PHP and PHPUnit, and want to get into unit testing
Steps I followed :
Install PEAR, download from the PEAR website
If you find yourself having trouble, follow this guy's tutorial
Download PHPUnit
Put PHPUnit in local file.. (www or equivalent)
Install PHPUnit with PEAR (If integration with cake, make sure you follow these steps)
If you already installe v.4, you can downgrade using the command
pear uninstall phpunit/PHPUnit
and install PHPUnit-3.7.32
Finally visit php.ini and make sure that path included points to the pear directory
In my case include_path = ".;c:/wamp/bin/php/php5.4.12/pear"
Cheers and happy coding
I've been reading up on TDD using PHP and i'm ready to install PHPUnit, however...
I'm on Win7/64 running WampServer
I'm reading all these PEAR/PHPUnit install nightmare stories which are making me very leery.
So I'm considering using Composer to install PHPUNit (to skip the whole PEAR thing, for now).
Either way, it seems that it's best to have PHP in the PATH, which is not the case for default wampserver setup I suppose (since it's NOT already in my PATH)
I'm a bit confused about exactly which php file I should be adding to the PATH, as my directory (C:\wamp\bin\php\php5.3.10) has the following files:
php.exe
php-win.exe
I was planning on using number 1.
Finally, are there any other caveats that I should be aware of.
I'm using NetBeans (and SublimeText2 for front end stuff) and WampServer 2.2
Thanks!
sleeper
I Solved it. I just add the directory (C:\wamp\bin\php\php5.3.10), not an individual file. See my comment.
I'm working with symfony2 for some time and I don't really get the correct way to work with the vendors.
So here is what I'm doing:
I have the deps and deps.lock files in my git while I ignore the whole vendors folder. Now when I install the application to a new server, I do a php bin/vendors install to pull the vendors onto the server. I get the message that I have to use install --reinstall and do that.
From my understanding, the versions should now be the exact same as on my development machine, as both deps and deps.lock are the same. But it seems that the deps.lock gets (partly) ignored?
There is also a vendors update command, which I read should not be used. BUt I didn't get the idea what it really does.
So I'm a bit confused now as of what command should be used when and what it is supposed to do. Maybe someone can shed some light on this topic! I'm especially interested in the correct way to use the vendors command both local and on the server so the vendors are in the correct version on both systems!
install and update both fetch new code from the git repositories specified in your deps file
install checks for hashes in you deps.lock files for each library. If it finds something, it checkouts the commit corresponding to the hash. If it does not, it checkouts the tag or branch in your deps.lock if one is specified and creates an entry in the deps.lock file
update is useful when you want to update to a new version of symfony (or any library in the deps file). If you one day, you feel like updating, you can read this post I wrote about the update process.
To sum up, I always use update on all machines, and I try to always specify a version for each library, so that the production environment does not get updated to an unstable version unexpectedly.
install --reinstall is the same as install but it also deletes vendor folder content before doing installation.
vendors update updates all your vendors to the latest version or version specified in your deps file and updates your deps.lock file. But you rarely need it, don't know where you read "should not be used".
If you look inside vendors file, you can see this line:
if (is_dir($vendorDir.'/symfony') && !is_dir($vendorDir.'/symfony/.git') && !in_array('--reinstall', $argv))
...Try to run ./bin/vendors install --reinstall...
So you have vendor/symfony folder without .git in it.
have you download the standard edition which already contains the vendors, that's why it displays this message to use "install - reinstall"
I personally made php bin / install-reinstall vendors in the deployement project
I am new to Linux and I am attempting to install the PHP PEAR library on a virtual server which is running Ubuntu. I am following a tutorial that covers installing PEAR but have run up against an area where I am confused. When running the PEAR installation program I am prompted as to what I want the INSTALL_PREFIX to be. Evidently the INSTALL_PREFIX, among other things, determines where PEAR will be installed. The tutorial suggest the value of INSTALL_PREFIX be the following path ...
"/home/MY_USER_NAME/pear"
where MY_USER_NAME = my user account
Having come from a Windows world, applications are installed on the system where everyone can use them. If I install PEAR underneath my user directory will other developers on the system be able to make use of PEAR in their PHP scripts? I want to make PEAR available to all users and not just myself.
Could someone explain to me the difference between installing for all users and installing just for myself? Does the install location matter? Should I be installing PEAR in a different location?
Thanks for any suggestions.
P.S. The tutorial I am following is located at the following URL ...
http://articles.sitepoint.com/article/getting-started-with-pear/2
Amend your INSTALL_PREFIX...
typically PEAR gets installed to /usr/share/php/
Have you read through the install section on the PEAR site?
There is no law against giving others access to your home directory but in practice it is never done. If you wanted to do that you would have to set the correct directory permissions and the other users would need to put your stuff on their PATH. But don't, it's bad if only because others can see all your stuff, accidentally (or maliciously) delete things, etc.
You should read a few things on file system standards and file system hierarchy and figure out what is appropriate for you system. Usually it will be something like /opt or /usr/local which will be accessible to all users. Usually you will need to have root permissions to install in global locations.