I'm trying to install the Twig template engine. I downloaded the source and copied the lib/Twig folder inside my src/lib/Twig project folder. But there is no autoload.phpor Autoloader.php inside this folder so I can't simply run
require_once 'src/lib/Twig/autoload.php';
How can I install it ? Where do I find the autoload.php ?
Twig is supposed to be installed with composer, you can find the composer.json in the repository. That would also generate the neccessary loader.
If you really want to install it yourself, set up your psr-0 compatible autolader like the composer.json tells you. Also pay attention to the requirements block, install those too and set up their autoloading mechanism.
Composer really eases installing libraries with all their dependencies, I highly recommend getting familiar with it.
Related
What I want to do is use the elasticsearch php client in a typo3 extbase controller. Now I created a composer.json and did the composer install, now I have a vendor directory next to my typo3 directories.
But what do I do next? Can I somehow tell typo3 to use the autoload.php or is there another way to load the classes? I'm kinda helpless.
If you want composer support, then you should consider upgrading to TYPO3 7.6 LTS.
You can find some basic documentation about composer at the official website.
When creating sites using a framework like Silverstripe I often want to use helper modules like gridfieldextensions and lumberjack.
I therefore use composer require to add the dependencies.
However when I follow my regular development work flow and use git add -A to add the module to the repo rather than the code being added to the repo I get a reference to it.
This causes problems when I then try to clone the site elsewhere (using Jenkins or another developer). The git clone or git pull leaves an empty directory.
I solve this by deleting the .git dir of the module and adding all the files.
Is there a better way to do this? Is using git submodule an option?
Somewhere i found a good .gitignore file that ignores everything and i have to tell it to include the custom modules for my project. It's like:
# ignore everything...
/*
# ...but
!/.htaccess
!/.gitignore
!/composer.json
!/composer.lock
!/Capfile
!/Gemfile
!/favicon.ico
!/touch-icon-*
!/mysite
!/some-module
#...other modules
# theme stuff
!/themes/
**/.sass-cache
**/node_modules
!**/node_modules/_manifest_exclude
#no assets in general, but /assets/.htaccess
!/assets
/assets/*
!assets/.htaccess
As FinBoWa already said you need the composer.json and composer.lock file in your project and running
composer install
on another machine it'll install the packages in the versions saved in the composer.lock file on that machine
composer install --no-dev
will only install the "normal" requirements, no dev-requirements like phpunit or other stuff you only need for developing or testing but not live
composer install --no-dev -o
will also optimize (-o) the auto loader, so it'll be a bit faster.
composer update
will update your packages, which might have funny side effects and break your site. So use it carefully and test afterwards.
composer update silverstripe/framework
will just update that package and finally
composer update silverstripe/*
will update all packages by the vendor silverstripe (e.g. framework and cms package)
See also:
gitignore documentation
composer documentation
I already know how to install by going through composer.json to add laravel/cashier, then composer update, and then add some line in app provider. But where does this folder go? What other things does it add in my app to make it fully functional? What is the work flow of composer update in Laravel 4?
Composer is a dependency management tool for PHP. It is not a typical package manager as it does not install libraries globally, but on a per project basis. It uses the file "composer.json" to install, update and remove libraries specified, including the version requested.
Composer creates an "autoload.php" file that, if included in your project, autoloads all libraries and classes and makes them available for use.
Typically, in a regular PHP project, you'd include the following line to bootstrap your project:
require 'vendor/autoload.php';
Now, when you execute composer install (for first time) or composer update (every time after), Composer adds/removes packages according to configuration made in "composer.json" file. All packages go in the directory "vendor" found in root of your project directory.
Laravel, by default, is a Composer project. You know when you execute composer create-project laravel/laravel my-app --prefer-dist to install Laravel, you are telling Composer to build a "composer.json" file with Laravel project and its dependencies, and run composer install. That's all!
Last but not least, Laravel, since it is a Composer project, includes "autoload.php" file and autoloads all packages within that project by default. You will notice "vendor" directory in the root directory. In Laravel 5 project, if you navigate to "bootstrap/autoload.php" file, you will see Laravel includes "autoload.php" file: require __DIR__.'/../vendor/autoload.php';
To answer your question about manually installing Laravel Cashier, Laravel Cashier is a package made specifically for Laravel, and as such, is not meant to be used on regular PHP project, unless you use specific classes and do some tweaking. To manually install Laravel Cashier, if you go to the following link, you will find link to "laravel/cashier" GitHub repository, from where you can manually download Zip file or clone the repository using git:
https://packagist.org/packages/laravel/cashier
I hope this adequately answers your questions - I kept it as simple as I could. Let me know if you have any other questions.
I've been working with the Magento Firegento custom Composer installer, and I ran into this odd bit of Composer behavior I don't understand.
Consider the following dead simple composer.json file
{
"require": {
"magento-hackathon/magento-composer-installer": "*"
}
}
If I run compser.phar install with this composer.json file, I get the following.
$ composer.phar install --no-dev
Loading composer repositories with package information
Installing dependencies
- Installing aoepeople/composer-installers (v0.0.1)
Loading from cache
Writing lock file
Generating autoload files
From my mostly lay-person's understanding composer.phar, I've said
Hey, composer, please install the magento-hackathon/magento-composer-installer package from packagist.org
And composer has said back to me
Sir, yes sir! Here's the aoepeople/composer-installers package
I don't understand why composer installed aoepeople/composer-installers, when I asked for magento-hackathon/magento-composer-installer.
To be clear: I understand the reason magento-hackathon/magento-composer-installer wasn't installed is this is a package that lives in a different composer repository. My original mistake was not including this repository in my composer.json file.
However, it doesn't make sense to me that composer would install a different package than the one I asked for. When I search packagist there's no magento-hackathon/magento-composer-installer extension.
Why does packagist install a different extension? What's happening behind the scenes to make magento-hackathon/magento-composer-installer resolve to aoepeople/composer-installers? How/where in the composer source could I debug this sort of thing myself in the future?
Vinai published a great writeup on Magento and Composer here.
Quoting from there
Composer will use packagist.org to look where to get the libraries. Because Magento modules aren’t listed there, you will have to add the packages.firegento.org repository to the configuration as follows [...]
So you will need the repository
"repositories":[
{
"type":"composer",
"url":"http://packages.firegento.com"
}
],
to get the magento composer installer.
And yes composer offers replacements. On the packaging entry for aoepeople/composer-installers you will notice the replaces section:
And since magento-hackathon/magento-composer-installer is not available on packagist composer will deliver you aoepeople/composer-installers.
OK, so that's a weird behavior :) I'm the author of the aoepeople/composer-installers package and the idea behind this is that this package provides an alternative (very basic and simplified implementation of the composer package-type magento-module - and adds another type magento-source. I only want the installer to put the package in the right place - keeping it simple. That's why I decided to come up with an alternative package.
The reason why the aoepeople/composer-installer replaces the magento-hackathon/magento-composer-installer is because many Magento modules already come with a composer.json that requires the magento-hackathon/magento-composer-installer. In order to be able to seamlessly use the simpler installer that one is "pretending" to be the hackathon-installer. But unless you actively require aoepeople/composer-installers in your project's composer.json you should continue using the original installer as no Magento module's composer.json out there (not even ours) is directly referring to aoepeople/composer-installers.
The fact that packagist tries to be "smart" and returns a package that replaces a package that's not registered is new to me and - to be honest - very disturbing. While this might be intended behavior I share the opinion that this could easily be abused. I start liking Alan's idea to bypass packagist completely using "packagist":"disabled". Especially in the case of Magento modules this seems to happen easily because most of the Magento modules are unknown to packagist while being registered at packages.firegento.com only.
A simple quickfix/workaround to this specific situation could be to register magento-hackathon/magento-composer-installer on packagist.org.
The Packagist package at https://packagist.org/packages/aoepeople/composer-installers has metadata saying that it replaces the magento-hackathon/magento-composer-installer package. Packagist would then install this as it's the package that replaces what you asked for.
Docs here: https://getcomposer.org/doc/04-schema.md#replace
My project relies on ZF and on a JS library. I wanted to be able to deploy the ZF library to the normal location (vendor/zendframework/zendframework1) but then deploy my JS library to somewhere else (public/my-vendor/my-library). Is there anyway to do this?
Composer is meant to manage your PHP dependencies, not JS.
Also, it only supports one vendor folder.
You might follow the way Symfony bundles use:
install everything in vendor
link (or copy) public assets to a public directory as part of your deployment process
In my opinion it's safer than installing something in a public folder (as long as you copy/link public part of a library only).
I came across the symlink idea but I wanted to automate this instead of manually creating the symlinks. I was going to create a composer script to create the symlink. I then found that symlinks on Windows and *nix need to be created in different ways which made this solution get messier by the second. I found that in the composer docs they talk about this same type of issue on the custom installers page and say that to solve this to create your own custom installer.
Relavent docs section: http://getcomposer.org/doc/articles/custom-installers.md
My custom installer: https://github.com/ddelrio1986/zf1-public-asset-installer
I have implemented this composer plugin to install packages into user (custom) defined folders you can just include it in your composer.json, follow the example and tell me if you have more questions :)
https://github.com/mnsami/composer-custom-directory-installer
composer-custom-directory-installer
A composer plugin, to install differenty types of composer packages in custom directories outside the default composer default installation path which is in the vendor folder.
This is not another composer-installer library for supporting non-composer package types i.e. application .. etc. This is only to add the flexability of installing composer packages outside the vendor folder. This package only supports composer package types,
https://getcomposer.org/doc/04-schema.md#type
The type of the package. It defaults to library.
Package types are used for custom installation logic. If you have a package that needs some special logic, you can define a custom type. This could be a symfony-bundle, a wordpress-plugin or a typo3-module. These types will all be specific to certain projects, and they will need to provide an installer capable of installing packages of that type.
How to use
Include the composer plugin into your composer.json require section::
"require":{
"php": ">=5.3",
"mnsami/composer-custom-directory-installer": "1.1.*",
"monolog/monolog": "*"
}
In the extra section define the custom directory you want to the package to be installed in::
"extra":{
"installer-paths":{
"./monolog/": ["monolog/monolog"]
}
by adding the installer-paths part, you are telling composer to install the monolog package inside the monolog folder in your root directory.
As an added new feature, we have added more flexibility in defining your download directory same like the composer/installers, in other words you can use variables like {$vendor} and {$name} in your installer-path section:
"extra": {
"installer-paths": {
"./customlibs/{$vendor}/db/{$name}": ["doctrine/orm"]
}
}
the above will manage to install the doctrine/orm package in the root folder of your project, under customlibs.
Note
Composer type: project is not supported in this installer, as packages with type project only make sense to be used with application shells like symfony/framework-standard-edition, to be required by another package.
By default, Composer reads composer.json schema. But, it can also use a different file. For instance, you can have zendframework.json and my-library.json.
In the zendframework.json, you can define:
"config": {
"vendor-dir": "zendframework/vendor"
},
In the my-library.json, you can define:
"config": {
"vendor-dir": "my-library/vendor"
},
Finally, you can update the libraries in this way:
COMPOSER=zendframework.json composer update
COMPOSER=my-library.json composer update
This is a simple idea. The benefit is that you solve the issue without third-party tools.