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.
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 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.
We're starting a new project, and we're managing dependencies with Composer. We'll probably build our app on top of Laravel 4. But we'll also create our own library, which we will use for all our next projects, not just this one.
So, we have this terrible doubt: what's the best way to develop a library using composer?
If we list that new library as a dependency, every time we modify it we will have to commit the change to the repository and then call composer update.
That seems terrible!
Is there a better way to do that?
I think there are two ways to handle this, which I use depending on the case:
The library is a pure library, which is standalone, fully tested, and develop it using TDD to ensure that it all works. That way it can be used with the "commit, update" cycle you described just fine I think.
You are developing a plugin or something that must be integrated in something else (application/framework) and testing it standalone is more difficult, or you are developing it very tightly with your application. In this case require the dev-master version of the library so Composer installs it with a git clone (if it was already installed as a tag you will have to rm -rf vendor/your/library to force a reinstall as opposed to an update). You can also force this for tagged releases using the --prefer-source flag. Then once you have a clone in the vendor dir you can very easily work directly in there. If you do work in a team though you will still need to do this commit and then update to make sure the others get the latest version.
The third alternative is to just develop the code in the src/ directory of your application until it is mostly stabilized and then you can extract it as a new package and add it back as a dependency, then fall back on the first two ways I described because it will then be a lot more viable.
If you set the dependency to the repository master branch instead of a packaged distribution file, Composer will check out a working copy into the vendors folder. You can modify this working copy right in the vendors folder, as if it's part of the main project, but then commit it into its own repository. You'll indeed have to make sure to composer update after that to keep the composer.lock file in sync with the development of that library though.
It's still the more convenient way to develop a project in tandem with a dependency.
If you aim to develop a truly awesome library, then you should try to develop it independently of any other software you create.
It should fulfill one exact task only. And this probably is done after some commits, so the initial creation of the library should take only a week or two to come to a stable first version. And this version can be tagged and then used elsewhere.
When tagging, strictly try to follow semantic versioning - that way you can use the library with a version restriction like "~1.0", meaning at least version 1.0, but anything up to 1.9999 is acceptable, as long as it is not 2.0 (which would mean incompatible changes).
And then you really do not need to update any other software when you release a new version of the library. You only need to update if you want to include fixed bugs. Without bugfixes, you can update, but there is no need to do so immediately after the library's new version release.
Composer will take care of all the dependencies you need. The most important thing if you start a new library is to include the composer.json right from the start into the repository.
What if you really want to always include the newest release of the library in every other software you write? I'm not sure you realize the implications this has. It means that you are strictly binding your other software to the most recent library version. Break that version, or introduce a nasty bug, and all your software breaks. So being able to update or not actually is a feature. You will find that all foreign libraries you might use will follow the same release mechanism: They tag a new version if an important bug was fixed, or if a reasonable amount of new features was implemented. They do not wait for you to approve a new version - you have to approve THEIR new version in your software by explicitly updating to the most recent one. And the same should apply to an internal library.
Try to avoid fiddling with "dev-master" solutions mentioned here. They might work, but Composer works best if used with tagged versions. If you have a reasonably stable state of your library, tag it with "0.0.0" and include that version everywhere else instead of "dev-master". And then tag according to semantic version rules.
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.