CODEWITHSUNDEEP
php
Graviton
Graviton

Reputation: 83254

What is the Best Practices to share PHP scripts among different PHP applications?

I have a folder of PHP scripts, they are mostly utility scripts. How to share those scripts among different PHP applications so that reuse and deployment are easy?

I would have to package my app into an installer, and let the user install it.

I could put the lib and hardcode the include path, but that means I haven to change the PHP code every time i deploy the web application to a new customer. This is not desirable.

Another route I consider is to copy the lib to other apps, but still, since the lib is constantly updating, that means that I need to constantly do the copying, and this will introduce a lot of problems. I want an automated way to do this.

Edit: Some of the applications are Symfony, some are not.

Upvotes: 9

Views: 698

Answers (7)

troelskn
troelskn

Reputation: 117527

Good question, and probably one that doesn't have a definite answer. You can basically pick between two different strategies for distributing your code: Either you put commonly used code in one place and let individual applications load from the same shared place, or you use a source-control-system to synchronise between local copies. They aren't mutually exclusive, so you'll often see both patterns in use at the same time.

Using the file system to share code

You can layer the include_path to create varying scopes of inclusion. The most obvious application of this pattern is a globally maintained PEAR repository and a local application. If your it-system consists of multiple applications that share a common set of libraries, you can add a layer in between these (a framework layer). If you structure the include_path such that the local paths come before the global paths, you can use this to make local overrides of files. This is a rather crude way to extend code, since it works per-file, but it can be useful in some cases.

Use source-control

Another strategy is to make a lot of local checkouts of a single shared repository. Some benefits over the layered-include-pattern is that you can make more fine grained local changes. It can be a bit of a challenge to manage the separation between application layers (infrastructure, framework, application). svn:externals can work, but has some limitations. It's also slightly more complicated to propagate global changes to all applications. An automated deployment process can help with that.

Upvotes: 0

txwikinger
txwikinger

Reputation: 3034

You should also look into using namespace in order to avoid conflicts with other libraries you might use. pear is probably a good idea for the delivery method, however, you can just place it in the standard path /usr/share/php/, or any other place that is set as the include path in your php settings file.

Upvotes: 0

erenon
erenon

Reputation: 19118

There are a lot of options:

  • tar + ftp/scp
  • PEAR (see above @Wayne)
  • SVN
  • rsync
  • NFS

I recommend to use a continuous integration software (Atlassian Bamboo, CruiseControl); check out your repository, build a package, and then use rsync. Automatically.

Upvotes: 0

mic.sca
mic.sca

Reputation: 1696

UPDATED:

you just have to put the lib in some place reachable by your apps (in a place where you can reach it via http or ftp or https or something else) and include it.

If you have to update it often you can package your library in a single phar file and you can then provide your client a function to pull the library from some remote path and update a parameter in their local configuration accordingly, like: 

 function   updateLocalLibary(){   
     //read the remote library in a variable  
     $file= file_get_content($remoteLibraryRepository.$libraryPharFile);   
     //give it a unique name  
     $newLibraryName=$libraryPharFile."_".date('Ymdhsi');  
     //store the library it on a local file  
     file_put_content($localLibraryPath.$newLibraryName,$file);  
     //update the configuration, letting your app point to the new library  
     updateLatestLibraryPathInConfig($newLibraryName);  
     //possibly delete the old lib  
 }

In your include path then you don't have necesasrily to hardcode a path, you can include a parameter based on your config, like: 

 include( getLatestLibraryPathFromConfig() )

(you are responsible to secure the retrieval in order to let only your clients see the library)

Your conf can be in a db, so that when you call updateLibraryPathInConfig() you can perform an atomical operation and you are sure not to have client read dirty data.

The clients can then update their library as needed. They may even schedule regular updates.

Upvotes: 1

Christophe Eblé
Christophe Eblé

Reputation: 8161

PHP now supports Phar archives. There's full documentation on php.net. There's a complete tutorial on IBM website as well.

One neat thing you can do with Phar archives is package an entire application and distribute it that way.

http://php.net/phar

http://www.ibm.com/developerworks/opensource/library/os-php-5.3new4/index.html

Upvotes: 4

gahooa
gahooa

Reputation: 137332

Ahh, libraries...

There are two conflicting purposes here:

  1. Sanity when updating scripts (ie. not breaking 10 other apps).
  2. Keeping things in one organized logical place for developer efficiency.

I suggest you take a close look at git and git submodules

We use git submodules extensively for this very purpose. It allows the best of both worlds because shared scripts can be upgraded at will in any project, and then that change can be moved to the other projects (deliberately) when you have time to do so and test correctly.

Of course, you need to be using git to take advantage of submodules, but if you are not using git, and you start, you'll eventually wonder how you ever lived without it.

Edit: Since the original poster is using svn, consider using SVN Externals.

Upvotes: 1

Wayne
Wayne

Reputation: 3435

You could create a PEAR package.

See Easy PEAR Package Creation for more information on how to do this.

This assumes that when you say anyone, you mean outside your immediate organisation.

Updated: You do not need to upload to a website to install the PEAR package. Just extract your archive into the pear folder to use in a PHP application.

Added: Why not create a new SVN repository for your library? Lets say you create a library called FOO. Inside the repostory you could use the folder heirachy of trunk\lib\foo. Your modules could then go into trunk\lib\foo\modules and have a file called trunk\lib\foo\libfoo.php. Now libfoo.php can include once or require once all the modules as required.

Upvotes: 5

Related Questions