I'm wondering how I would be able to load PHP packages without using composer to do so.
I'm unable to use composer as I'm using shared hosting, which imposes limitations like being unable to install composer due to a heavily jailed shell.
While there are certain packages which allow for the loading of a package with require_once('package/Autoloader.php');, i.e. Braintree & Twig.
However, not all packages can be loaded like this, example being,
Pug-PHP, which only includes installation with composer.
Can anyone help me load composer packages without composer?
This is not possible due to Packages being a dependency of the composer management system. Replicate the ENV locally and use #MichalGallovic 's suggestion.
There is also the option of git clone every package and dependency from their respective source repos; but at that point you will hate yourself.
Is the option of using a host that are not as strict an option?
Visit https://php-download.com/ They have a number of packages ready to go that will no longer need Composer. It finds and creates all required folders and creates a zips it for download. Saves me hours of drama.
Related
I want to minimize traffic usage with composer packages load, so I need for production loads to only download the source/lib folders without examples/docs/readme.
I haven't found any information in the official composer documentation.
UPD
One of the best solution - add .gitattributes file into your project and add main rows from this gist
This is not really up to composer and instead a responsibility of package maintainers. You can use --prefer-dist to install a distribution instead of checking out the git repository as is usually done during development, but what this distribution contains is managed by the package maintainer.
If the packages you install allow for pull requests & issues, you could ask them to provide a .gitattributes file which is recognized by github when creating an archive or provide a pull request providing one. In this file you can specify which files and folders will be excluded from the archive using export-ignore. In any case since everything is bundled in a zip the bandwidth saved is probably negligible.
So, short answer is the only way to minimize bandwidth usage and allocated disk space for dependencies is using the --prefer-dist option - and omitting dev dependencies with --no-dev - when installing them for production.
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.
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 am working on a PHP application that uses many features from PEAR. The app is meant to be distributable kind of like Wordpress but really scaled down.
Now the problem I've run into is that PEAR needs to be installed and configured alongside the PHP server without which my app simply will not function unless the users go through all the painful steps of installing PEAR on their server. Users can very well be newbies or non-technical so it's not an option for them.
Therefore there is a need to somehow package everything PEAR into the application itself. As far as I know it may not be possible.
Are there any alternate solution to this? Any solution at all will help. Thanks..
PEAR installs system wide dependencies which makes things like what you describe hard. Composer on the other hand is exactly what you'd need, because it's a per-project dependency manager with much better support for resolving and installing of dependencies. Basically, compared to Composer, PEAR sucks... it always did, Composer on the other hand rocks!
The first thing I would do for each package you need is to see if it is also provided on https://packagist.org/. If it is, problem solved, include the installation into your build process with composer. If you end up with only a few packages from PEAR, you have several options:
inspire the author to provide it on packagist
make your own mirror on packagist (not recommended but sometimes necessary)
see if the project is on github and install directly from git with composer
install the PEAR package via composer anyways, it's possible.
Short answer: switch to composer!
If you are talking about the PEAR packages or class files, you can put the PEAR packages anywhere you want. Just put the ones you use into a dir within your app dir structure and add that to the include path.
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.