Every time I create a new PHP project I basically use the same MVC folder structure that I adopted and like, I use the same base classes, interfaces, and the same PDO DAL implementation.
When I'm creating a new project I copy&paste all the needed files to the new project in addition to few changes, like changes to namespaces (to match the new project name) etc.
I thought, why not creating a simple script to copy those files and folders, and make the additional changes.
So now, when I create a new project I just run the script and the code is generated automatically, which is much nicer.
And then I thought, I want it to be even simpler. I don't want to save the code in my computer, I want to save it on Github, and since I use and love composer, I thought I will make the Github project a composer package.
But when trying to implement it I realized that I can't make the new composer package auto generate the code that I want, or at least I don't know how to make it do that.
I tried googling it with no success.
Does anyone knows how to achieve this?
I don't see any need to generate code here. Simply add your skeleton files to your Git repository and use Composer's create-project feature. See the third point:
You can use Composer to create new projects from an existing package. This is the equivalent of doing a git clone/svn checkout followed by a composer install of the vendors.
There are several applications for this:
You can deploy application packages.
You can check out any package and start developing on patches for example.
Projects with multiple developers can use this feature to bootstrap the initial application for development.
An example of a major PHP project that supports this approach is Laravel. From its installation instructions:
Via Composer
The Laravel framework utilizes Composer for installation and dependency management. If you haven't already, start by installing Composer.
Now you can install Laravel by issuing the following command from your terminal:
composer create-project laravel/laravel your-project-name --prefer-dist
This command will download and install a fresh copy of Laravel in a new your-project-name folder within your current directory.
If you prefer, you can alternatively download a copy of the Laravel repository from Github manually. Next run the composer install command in the root of your manually created project directory. This command will download and install the framework's dependencies.
Edit:
To have a script run after composer create-project completes you should be able to use a Composer script:
A script, in Composer's terms, can either be a PHP callback (defined as a static method) or any command-line executable command. Scripts are useful for executing a package's custom code or package-specific commands during the Composer execution process.
You are probably looking for the post-create-project-cmd event:
occurs after the create-project command is executed
Depending on whether your script is a static PHP method or a shell executable, you should define it as follows (modified from Composer documentation):
{
"scripts": {
"post-create-project-cmd": "MyVendor\\MyClass::postUpdate"
}
}
or
{
"scripts": {
"post-create-project-cmd": "my-shell-script arg1 arg2"
}
}
Related
I have a hard time figuring this out; I am also puzzled of the connection - if any - with the create-project command.
As far as I can tell, the only difference between install and create-project is the execution of post-root-package-install and post-create-project-cmd hooks...
Can someone shed some more light on this?
My goal is to set up a composer infrastructure where I run create-project and this sets up a project skeleton (creates and sets directory permissions, creates default configuration files, creates blank data stores)
What exactly is the difference between project and library types in composer?
Practically, there is none. It doesn't affect how composer gets executed. You can use both install and create-project with both types of package types.
This metadata is meant to inform plugins, IDE, or even packagist.org when parsing composer.json, but on a vainilla installation, there is no practical difference in using one or the other.
(Docs on package types)
As far as I can tell, the only difference between install and create-project is the execution of post-root-package-install and post-create-project-cmd hooks.
The docs are your friends:
You can use Composer to create new projects from an existing package. This is the equivalent of doing a git clone/svn checkout followed by a composer install of the vendors.
Any time you do create-project, install is executed as well. Which means that the install hooks are executed as well.
First it clones the whole package via the appropriate CVS (git, usually), and then immediately executes composer install. By default, it removes CVS information (e.g. the .git directory), unless one uses the --keep-vcs option.
create-project is useful to bootstrap applications, so the app's directory is setup beyond what downloading composer`s dependencies would do. You can create a skeleton directory structure, etc.
Usually one would have a package proper (that could be required into an application), and a "application-skeleton" package, that would include the directory structure and would depend on the original package.
I'm posting a more succint answer to my questions, based on experimentation:
What is the difference between project and library types?
Absolutely none as far as composer is concerned. Some plugins might implement logic to treat the two package types differently though.
How does that relate to require, install, create-project commands?
In no way whatsoever. The project in package type has nothing to do with project in create-project.
How does create-project work?
Let's say we are talking about a single <package>. We have 2 workflows:
composer init <project_path> && composer require <package>
composer create-project <package> <project_path>
The first workflow will create a blank root package and add <package> as a requirement to it.
The second workflow will "clone" <package> into <project_path> as the root package.
NB: If you are working with local path type repos for development, create-project will actually create <project_path> as a symlink to <package>'s source dir. This is the default behavior of path repos, and probably a miss for composer in the need to treat create-project differently. This can create a heap of confusion (as you might be inadvertently changing and adding to <package>s sources while thinking you are just editing project_path). So for local development and testing, you are better off with cp -A rather than composer create-project.
Maybe just a stupid question.
After I download/clone composer source code from github.com, how can I run it or compile it into a phar file?
When running "php bin/composer -v", it shows such errors:
php bin/composer -v
You must set up the project dependencies using `composer install`
See https://getcomposer.org/download/ for instructions on installing Composer
Is it said that I must download another composer.phar file and run "php composer.phar install" first?
I think it is a recursive way, "composer" itself is managed by composer :(
At first: if someone wants just to use composer, they must not install it from GitHub, just follow the installation guide: https://getcomposer.org/download/
OK, back to the question.
"composer" itself is managed by composer
Yes, and why do you think it is bad?
See the official documentation for contributors. It encourages exactly that way:
Run git clone https://github.com/composer/composer.git
Download the composer.phar executable
Run Composer to get the dependencies: cd composer && php ../composer.phar install
Then you can actually use composer by launching bin/composer, or you can compile it into phar by bin/compile.
If you wonder how are composer binaries actually built, you can see it in their Travis config. They just grab previous composer release provided by Travis, and build new composer release with it.
Composer's job is to locate and install dependencies for a particular project. Everything it does could be done by hand, mostly simply by placing files in the right location, and referencing a series of autoloaders.
In order to build Composer from scratch, you need certain code that is outside of the main Composer repository, such as command-line and logging helpers. You could download all of these manually, but the natural way is to use an existing install of Composer to fetch them.
This is only necessary if you are working on Composer itself, because once you have a successful build, you can produce a PHAR file, which contains all the required code including those third-party dependencies. These are the files distributed as official releases, and are all most people need; the tool even has a self-update command which downloads a new PHAR file and overwrites the one you ran.
This kind of bootstrapping - using an existing build of a tool as part of its own build process - is actually quite common. There are some parts of PHP itself which are generated using a PHP script, and I believe the first feature-complete C++ compiler was written in C++.
I am starting a new PHP project, and I wanted to pull some php components such as "nesbot/carbon" using composer. But when I create a composer.json file and try to run composer install command, it downloads other files from my previous projects that I don's want.
Even when I try to run "composer install" with out having a composer.json file in an empty folder, it downloads some previous dependencies from caches. I didn't get that from where it's reading composer.json. Am stuck in the middle of project.
How can I create a fresh project with composer?
To create a fresh project with composer, run
$ composer init
in the root directory of that project.
For reference, see https://getcomposer.org/doc/03-cli.md#init.
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 created a project with Laravel and downloaded from git via this command:
git clone -b develop git://github.com/laravel/laravel.git
The file size was about 21MB,
I want to know should I download Laravel for every project with this command?
What you have done is cloned the framework itself, which you should only do if you're going to fork and develop the Laravel core.
What you should do instead is use Composer to install your Laravel projects. You'll also be using Composer for other dependency-related actions in said projects (including autoload). This is the proper way of installing a fresh Laravel framework for developing a website:
composer create-project laravel/laravel --prefer-dist
http://laravel.com/docs/installation
Then, any future Laravel projects you create will be loaded from your Composer cache without needing to re-download.
The Composer package also sets up all your vendor-related .gitignore information and includes several other really useful management features. This is important, because you only want to keep your application-specific code under git version control, not the framework itself or any other dependencies. (Otherwise, your diffs and commits will get polluted with the dependencies' development changes.)
Once you've created a repository for your project, and installed Laravel with Composer, and created your first few commits (with some migrations, models, and controllers, for instance), cloning your project usually works something like this:
cd /clone-here
git clone /myproject # Location of current project
# /clone-here now has only the application-specific files from /myproject. It is
# still missing the framework itself and other dependencies.
composer install # Composer now looks at the dependencies in
# /clone-here/composer.json and installs them into /clone-here/vendor
# including the Laravel framework.
# Now the framework and other dependencies are good to go.
php artisan migrate # Laravel makes all your DB schemas from your migrations
php artisan db:seed # Seed your lovely new DB tables
It's really elegant and fun once you get used to it.
Edit:
See Sheikh's answer to save some time in the Composer install process!
Already Leng gave a nice answer.
Installing Laravel since version-4.1* via Laravel Installer is faster than composer
First, download the Laravel installer PHAR archive. For convenience,
rename the file to laravel and move it to /usr/local/bin. Once
installed, the simple laravel new command will create a fresh Laravel
installation in the directory you specify. For instance, laravel new
blog would create a directory named blog containing a fresh Laravel
installation with all dependencies installed. This method of
installation is much faster than installing via Composer.