Composer is very awesome for managing dependencies and makes life so much easier.
However, I am a bit unsure where I should place data files to be used by my composer requirements.
For example, the Maxmind GeoIP library is something I am using. Because the maxmind databases are provided independently of the PHP library and have a different cycle, there really isn't a way to make it a composer requirement.
Should I add them as packages to my composer.json? Since I have a Satis installation for serving private repos, should I create my own repo for those datafiles?
What is the accepted practice of dealing with vendor databases and datafiles when using composer?
If you want to manage the data via composer, I would suggest to configure them as an own package, which you require on project level.
There is no default workflow for non php parts. Especially databases are rarely managed via composer, as there is no standard for doing migrations.
In my opinion, migration scripts should not be part of composer, because only your application should alter your databases, and only when you want it to, not when you execute composer commands.
The GeoIP datas are a bit different, this is only a kind resource file you use. If I look at attempts regarding java-script and similar, its common to have a separate composer package for them. So like I said first, add the data in an own package, which you can maintain separate from the GeoIp Library
Related
Sounds weird, but I thought composer was a tool that one used to install packages in PHP stacks. An efficient and robust way to make sure that php environments are setup correctly.
But I keep coming across forum posts that talk about caching and advising to do things like composer clear-cache as if it was part of the actual running application. Like it's actively doing things in the running app.
Am I missing something?
Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you(refer link.
It helps us installing/updating various requirements/components for our app such as Laravel framework, Doctrine, lodash etc..
If you have ever written anything in PHP before, you have probably found that it feels like you have to keep re-inventing the wheel anytime you want to do a common task such as User Authentication, Database Management or Request Routing.
If you were to start manually picking the bits you wanted from Laravel then it would become very difficult to manage. Each library might also have dependencies, and so you would end up in a mess, particularly if you required other people to work on your project.
This is where Composer comes in. Composer is a dependency manager for PHP. Composer will manage the dependencies you require on a project by project basis. This means that Composer will pull in all the required libraries, dependencies and manage them all in one place.
Managing your dependencies manually in any programing language is an immense pain. This is often why, in most programming languages these days you may notice that all of them have some implementation of a dependency management system or generally a package manager.
In PHP, we use NPM i.e Node Package Manager in frontend technologies like JavaScript, VueJS. For backend, Composer is the de facto dependency manager.
Laravel is itself a package of packages, hence to develop our projects smoothly among the team members, dependency management becomes a must and composer does its work under the hood, silently but efficiently.
Composer is an application-level package manager for the PHP programming language that provides a standard format for managing dependencies of PHP software and required libraries.
Composer runs through the command line and installs dependencies (e.g. libraries) for an application. It also allows users to install PHP applications that are available on "Packagist" which is its main repository containing available packages. It also provides autoload capabilities for libraries that specify autoload information to ease usage of third-party code.
Composer is used as an integral part of several popular open-source PHP projects, including Laravel.
I'm a bit confused about using Composer.
I have built my own package manager, that uses a config-file and a large SVN-repo that contains all possible libraries (both PHP and Javascript / CSS) I need in several different projects. I download these packages myself from the library websites.
Now I'm trying to use Composer instead, since I like the automatic dependency checking and want to use something that everybody else does. But how do you decide what packages are best?
For example, for CodeMirror, I used to download the latest stable version from https://codemirror.net/ . But when I look in Packagist I see so many different versions that I don't know which to choose. It seems everybody can create new packages for Composer ? I just need the official ones.
So, how do you guys pick the packages you need?
To answer your question directly, for any component you want to import into your project, the way to find the "canonical" source - as opposed to various forks - is to go back to the original source and see what their usage/install instructions suggest. If they support a Packagist-based install, they will usually say so. If not, but there is a composer.json in their (typically) Github repository, then you can add the repository to your composer.json and then require the package as normal.
However, more generally, I think there is some confusion about what Composer really does. As noted in the comments, Composer is a dependency manager for PHP. Packagist is the primary repository for composer-managed packages. The CodeMirror library you cited is fundamentally a javascript library.
Now it's true that if you search for "codemirror" on Packagist, you will see lots of results there, some of which are labeled as Javascript components. But they are primarily:
wrappers that allow consumers to interact with or simply load CodeMirror in PHP-based view-scripts, like conquer/codemirror for the Yii framework, or nitrado/code-mirror-bundle for the Symfony framework; or
shim repositories for the Components project - like components/jquery, for example - which are then installed using the command-line script from their Component Installer for Composer
Bottom line: Composer is primarily used for importing PHP packages. It takes some gymnastics - like the Component Installer for Composer noted above - to make it usable/helpful for non-PHP packages.
I'm making WordPress plugin that is using a few third party libraries. Is it common practice to use Composer for WordPress plugin?
If it's okay to use it, then I assume that I should provide all Composer files along with my plugin, because I don't want to make people manually run composer install.
Another question is, is it safe to use Composer's autoloading? I configured it to autoload my own classes and the libraries are of course autoloaded as well. That's convenient.
Is using Composer with WordPress plugin an overhead? Or does it have any additional issues?
This is old question, but nothing has changed since 3 years. Using Composer for requiring dependencies in WordPress plugin/themes is usually a bad idea. PHP does not allow to load more than one class with the same FQN. So if two different plugins will install the same library independently, classes from random installation of library will be loaded which may result really weird bugs (especially if these are different versions of the same library). To avoid such problems you should have only one composer.json instance per project, so in this case Composer should be run at WordPress level.
In general if you have the same package installed multiple times, you probably will get some troubles (and this will happen if every plugin maintainer will use Composer on its own). Note that this is not directly related to Composer - if you copy libraries manually you will get exactly the same problem (maybe even worse).
If you really want to use Composer in your plugin you may try tools like humbug/php-scoper which will modify namespaces of used dependencies and make them unique.
First of all, I'm a complete newbie to Composer. I've been trying it out since it's a sounds awesome and mainly because Zend Framework 2 uses it.
Zend Framework 2 is actually also the reason for this thread.
It get the basics of Composer. But with my current server setup I have a request, which I can't seem to figure out if possible.
Let me explain.
I have multiple Zend Framework 2 projects:
/home/morten/sites/Project-1/
/home/morten/sites/Project-2/
/home/morten/sites/Project-3/
All of these projects should be running ZF2. When running composer in each project - each of them get their own separate download of the ZF2 Library files. Which is a bit redundant with my setup.
I have a complete and up-to-date download of ZF2 Library located at:
/var/www/shared/Zend/
And my php.ini has that path added to PHP's include_path, so the whole ZF2 library is available for all the three projects.
IS IT POSSIBLE to make Composer use in it's setup. Because if I try to change stuff and try things out in the composer files, then it just re-downloads Zend because it's a required component for other modules.
Can this be done? And if yes, how can I do it?
Hope I have explained myself good enough for you guys to understand what I'm trying to do and want :)
Thanks a lot in advance!
Regards,
Morten
You might be able to have one composer.json file stored in /var/www/shared/Zend, where you would put your dependencies and use Composer do manage them. Then all projects could include the same autoloader.
However, I wouldn't recommend that approach:
Your project's dependencies (composer.json) should be stored with your project. If you want to install your project somewhere else (for instance if you want to move one project to another server), you are missing the composer.json to install the required dependencies.
It will not be possible to update the dependencies of one project, without updating the dependencies of all other projects. If you want to introduce a new feature in Project 1, which requires a new version of a certain dependency, all other projects will get this new version as well - which might introduce backward compatibility breaks if an older feature that Project 2 relies on, is no longer supported. Since you can only have one version of each dependency, it is not possible for two projects to have different versions of the same dependency.
This approach might be useful if all projects will have the exact same functionality and code, but in that case you should probably merge them into one project.
In all other cases, I would suggest to use Composer the way it's supposed to be used: give all projects their own composer.json file and let Composer download the dependencies per project, in each project's vendor directory. The downside is that it'll cost you a little more disk space, but you'll get a lot of flexibility for it in return.
I'm looking for a script that will quickly implement package install/update functionality for my framework. It should be able to do the following things:
Must be PHP 5 compatible.
Should be able to install and update components' files and database tables.
Should allow defining of package dependencies and have a form of conflict resolving.
Should allow UPDATE SQL-statements when the developer of the package provides it. (To make database alterations without losing data).
Should be able to 'jail' an update package to a target folder.
Should be able to define and detect different package types to apply mentioned 'jail'.
Should provide an API to integrate it in custom backend.
Should allow downloading of the packages, preferably over HTTP (rather than FTP or others).
I plan on using this as a stand-alone utility to easily provide updates for modular frameworks as well as custom code for our clients.
If you have recommendations of tools that are similar or used in an open source framework to base it off that would be good as well. :)
I don't know of any magic tools to do this, but a couple that might help you do these tasks are Phrake and Composer.
Phake is a PHP version of Ruby's Rake util. You could use these scripts to set up your database, update files and run unit tests.
For package management you could use Composer to manage your dependencies (it can also download from PEAR if you depend on packages from those systems) and of course this could be incorporated into your build scripts.