I have been using maven in JAVA and started using PHP Maven, recently I switched to composer.
My project is with Zend Framework 2 and the team only checks in the application code not anything on the vendor directory. This is done to avoid conflicts and not to have the libraries under SVN.
Now each time a developer sets his or her new environment, we observe that, the composer pulls the dependencies from internet. This takes quite a long time.
Is there any better idea/approach to make this faster or handling the project in different way to avoid this problem?
maven uses maven proxy servers which can cache the download and can be used in the network again, but do we have any solutions to handle problems like this?
Composer is a very young project, so there might be things missing which e.g. Maven can co without hassle.
You could set up your own Packagist server as described in the composer docs. I believe packagist has some caching options which can be used to store packages on the packagist server.
What you also could do is fork your dependencies and push them to a company-owned private repository. In your composer.json you would now only use this dependencies, making it faster to clone. Of course this would require you to maintain all the different dependencies (although this could be done with a script and a cronjob, pulling the data from the github repo and pushing it into your company owned).
I also believe composer has some proxy options, but I don't think these are meant to cache dependencies.
Last option would be to develop something like this, either as part of composer/packagist or as stand-alone.
In PHP there is an existing option for running a composer like repo locally and it's called Satis (it's actually provided by Composer) here: https://github.com/composer/satis
So you can run it locally on your server and point your composer to use that as a default composer repository and Satis makes sure that all installed packages and different versions are cached on disk as ZIP files so could be retrieved quicker compared to always downloading them from Internet.
You can do something like this:
{
"repositories": [
{
"type": "composer",
"url": "http://satis.example.org/"
}
],
"require": {
"company/package": "1.2.0",
"company/package2": "1.5.2",
"company/package3": "dev-master"
}
}
This also allows you to have private packages and libraries without exposing them on GitHub.
Another BIG advantage is when GitHub goes down for whatever reason you can still deploy as all of your dependancies are cached locally. This is assuming you haven't added new, non-existent packages to the release.
Related
I am reading/learning about Composer, the application-level package manager for PHP.
In this blog post written by lead dev Jordi Boggiano, he writes:
Composer on the other hand forces you to declare your project
dependencies in a one-stop location (composer.json at the root). You
just checkout the code, install dependencies, and they will sit in the
project directory, not disturbing anything else on the machine.
Another related feature is the composer.lock file that is generated
when you install or update dependencies. It stores the exact version
of every dependency that was used. If you commit it, anyone checking
out the project will be able to install exactly the same versions as
you did when you last updated that file, avoiding issues because of
minor incompatibilities or regressions in different versions of a
dependency.
If I understand Composer properly, when we're talking about packages downloaded/installed by Composer, we are talking about PHP code packages, ie, programming code written in PHP, and not system-level packages, eg, extensions to the PHP runtime installed on the server. So once these PHP code packages have been downloaded and added to a PHP project, I would have thought those packages become part of the PHP application source code, eg to be checked in to whichever version control system is being used for the project. If another developer comes along and checks out the code, why would they need to then "install the packages", as is stated in the blog post? Wouldn't they get a copy of all code packages when they check out the code from source control? This line in the blog post is confusing me, and making me think I don't understand Composer.
Any clarity on this would be greatly appreciated. Thanks.
The dependencies themselves should not be commited to source control. The composer.json and composer.lock files, on the other hand, should. There's various reasons for this, amongst them:
Every time you update the dependency you would have to commit the changes. That kind of tightly couples your code to the dependency, when it should be exactly the other way around.
The packages themselves are already in their own repository with their own history. Why repeat that in your project's history?
Those repositories can be huge, just muddling the waters around your project. Why carry around all that weight?
Instead, having each developer just run composer install (very important: not composer update) whenever they check out the project is much more efficient. Composer will install the dependencies from composer.lock, making sure everyone running the same commit is on the exact same page. The same goes for deploying.
You can read more about this here.
On the other hand, there might be situations where you have to commit your packages to get around a problem, like for example when you know you won't be able to run composer install on your production server (shared hosting)
Normally packages installed via composer don't get checked in to source control, only the code you write and the composer.json and composer.lock files.
This way the repository for your project does not get bloated with code you did not write and possibly don't really care that much about.
Yes its normal after cloning down your repository a developer will need to run the "composer install" command. The composer.lock file will ensure they get the same modules and versions of them you used when creating your project.
Not including the composer modules in your source control also allow you to easily update to the modules to get bug fixes and new features in new versions of them.
Let me just say this, I'm very new to composer and laravel.
I'm a long time cli fan, so I feel very comfy with composer. I've used npm, ruby gems etc, I see all the benefits to package managers.
Problem is, I'm saving entire laravel dir to my svn repository. It seems kinda redundant, especially vendor/bootstrap dirs.
I also find it uncomfortable to have vendor packages same in every laravel app directory on the same server, I'm kinda missing global gems thing from ruby.
How do you deal with this? Is it possible to have laravel like a shared library on server and then just have app/public directories in each project?
What files should be saved to repository? can composer handle all the dependency installation on production server? I see laravel files come with .gitignore files, where do I get svn version?
Much confusion atm in my head, hope to clear these up, so I can start actually writing code ^_^
First off, as far as I know, it is not easily possible to install laravel and it's dependencies globally. I wouldn't worry about that too much though since composer will cache them so it won't need to download everything for each project you set up.
Vendor directory
The vendor dir should definitely NOT be in your repository. I'm no SVN expert but according to this answer you can ignore directories by doing:
svn propset svn:ignore "vendor" .
Most SVN client software should have a similar function in a context menu or similar.
Deploy workflow
Ideally you checkout the repo on your production server and then run composer update to install all dependencies. If you don't have terminal access or have other troubles with that I recommend you download a fresh copy of your repo and run composer udpate. Then upload it to your server.
I downloaded Laravel from github and save it on c:/htdocs/laravel1
and I created a copy of my laravel with CMD (with composer) and I install this as laravel2 in c:/htdocs/laravel2 directory.
Laravel1:
c:/htdocs/laravel1
Laravel2:
c:/htdocs/laravel2
And I have access to both of them in localhost:8080/laravel1/public/ and
localhost:8080/laravel2/public/
My question is : Why should I install laravel by composer? There is no different between the installed laravel and downloaded laravel.
There are many, many valid reasons to use composer:
Composer creates optimized autoloaders if you want it to
Allows you to add thrird party dependencies easily (just add them to composer.json)
You can track the composer.lock file, and use composer install to ensure the exact same versions of the dependencies are being used throughout (on all environments, by everyone contribbuting) This is a must-have, if you're using automated builds!
Updating all dependencies, including Laravel, is a simple matter of composer update
Composer supports post-install and post-update scripts, to be executed after a composer install/update is run. This is quite commonly used to prompt the dev for configuration parameters. Downloading the code means you have to edit the config files by hand, and worse of all: track them in git or svn
... I'll probably add more reasons along the way, these are just a few off the top of my head
Update:
Just thought of some more reasons why using composer is a good idea:
Composer packages themselves can, and often do, define dependencies and requirements. Things like "php": ">=5.4.0", or "ext-curl": "*" will alert you to any missing PHP extensions or a version mismatch. These requirements can also trigger composer to fetch additional dependencies. Which brings me on to the next point:
Laravel itself has dependencies: Laravel uses components from Symfony2, for example. The easiest way to manage its own dependencies is to use composer, seeing as Symfony does, too. If you run composer update, the dependencies of Laravel will be checked, and updated where needed. Doing this manually is possible, but it's tedious, and really not worth the bother. Repetitive, dull jobs make people grumpy. Computers don't have this problem.
Composer is a dependancy manager similar to node's npm which allows quick and easy management of 3rd party libraries & packages on a per-project basis.
I recommend reading https://getcomposer.org/doc/00-intro.md to find out more about composer and explore https://packagist.org to find out the kind of things that are available through composer
I'm working on a project which contains couple of parts written in different languages. One of these parts is a PHP application. When distributing the project there is a phase to distrib this PHP app. I use Phing for that. So apart from other dependencies, I have
"require": {
"php": ">=5.3.13",
"phing/phing": "2.7.*"
}
As composer.json in Phing package suggests, Composer creates autoload_classmap entries for Phing. There are some Phing targets that copy vendor libraries further, but they don't copy Phing itself (it's not a runtime dependency for PHP project itself). As a consequence, there are many entries in autoload_classmap that are problematic. My application itself uses classmaps so I want to use the mechanism but not for all packages.
Is it possible to suppress generation of classmap entries on a per package basis ?
This is probably a hen-and-egg problem, but I think Phing does not belong into the softwares dependencies, so it has to be taken out. Problem with the classmap solved.
Where does it belong? It is infrastructure you have to install to deploy or distribute the software. Phing should be installed on the machine executing the deployment, or anywhere else where it is needed, but this is part of the infrastructure requirement for this machine.
You can use Composer to install Phing globally (it's way better than using PEAR for this). Or you can create a deployment project that includes Phing, probably other stuff, and has the task to deploy/distribute that software.
When putting together a PHP project with composer, on installation / deployment, composer would fetch the dependencies usually from their original sources.
This could lead to problems when deploying, when a source (maybe only temporarily) becomes unavailable.
Is there any included mechanism to keep at least the current, stable versions of the dependencies some where to be always able to deploy the current version to other instances?
Right now there is no one click solution for this, but I plan to work on something soon that will give you more reliability.
Broker looks like a tool which could serve as a proxy to keep files, and is now integrated into Satis (see https://github.com/researchgate/broker)
broker is a full repository proxy for composer. It takes a composer file, downloads all
requirements and all dependencies, and then publishes a new repository with all these
packages. Instead of packagist or satis, all packages, including dist and source files will > be served directly by broker.
Note: this project is not actively maintained anymore. Since satis supports a similar
functionality now, you should use satis instead.