If I download the fat archive linked here http://silex.sensiolabs.org/download I get a different silex to that when I composer require "~2.0" ( as instructed on the same page ) , for example, the ServiceProviderInterace does not exist in silex/src/Silex in the composer version, whereas in the fat archive it does. Looking at github the composer version matches...but I need the version with the ServiceProviderInterface...
I must be doing something wrong! advice please
In Silex 2.0, there was some changes and the ServiceProviderInterface was split in to EventListenerProviderInterface and BootableProviderInterface and were moved in the Api directory.
Here: http://silex.sensiolabs.org/doc/master/changelog.html
In the fat archive you give, it's the version 1.1 of silex if you look at the composer.json file that's why you have the ServiceProviderInterface.
Related
According to docs, composer install (composer update too, since it includes install script), among other things, downloads the requirements and puts these packages inside the vendor directory: https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies :
It then implicitly runs the install command. This will download the dependencies' files into the vendor directory in your project.
What the docs don't say is: we often write the following in composer.JSON...
"require": {
"php": "^8.0",
... so if we try to apply what the docs say, it means that Composer would download the PHP interpretor (a package available in Packagist for example) and put it inside the vendor directory, when we run either composer install or composer update. What is the interest of putting a PHP interpretor inside a site's folder (here, vendor)?
But we know it doesn't do that. It won't download any PHP interpretor. It won't obviously put it inside the vendor directory. Instead, it will just check the server's PHP interpretor's version and returns a fatal error or something else if this version doesn't match the requirement's version.
So does it mean that in the Composer's install and update scripts, there is an exception made for PHP when treating the require's lines in the composer.JSON file?
In composer there's a special exception for require php, it only checks if your system's PHP version meets the requirement.
It's in the composer website under Package links: https://getcomposer.org/doc/04-schema.md#package-links.
Its not literally written though, its quite hard to find in the composer documentation.
If your require contains something like with
"php": "^8.0",
"ext-json": "*",
this does not mean: Install PHP or the JSON extension through Composer, but require that PHP and that extension in the given versions are already installed. That's what the documentation at https://getcomposer.org/doc/04-schema.md#package-links tells you:
require and require-dev also support references to specific PHP versions and PHP extensions your project needs to run successfully.
A regular expression that matches all such platform requirements can be found at https://github.com/composer/composer/blob/9ba042ded8b26230d33ebceb692bf29111d51ba4/src/Composer/Repository/PlatformRepository.php#L34 - currently, it contains:
const PLATFORM_PACKAGE_REGEX = '{^(?:php(?:-64bit|-ipv6|-zts|-debug)?|hhvm|(?:ext|lib)-[a-z0-9](?:[_.-]?[a-z0-9]+)*|composer-(?:plugin|runtime)-api)$}iD';
...which matches:
PHP runtimes in several versions
HHVM, a virtual machine that runs a forked version of PHP
all kinds of extensions and core libraries, like ext-json or lib-bz2
Composer itself, as some packages require special features of Composer v2 which were not available in v1
All lines in require section of composer.JSON are not packages available on a repository like Packagist: indeed, we can put some "virtual packages" inside this require section (https://getcomposer.org/doc/01-basic-usage.md#platform-packages).
php is one of these virtual packages. So Composer treat the following line...
"require": {
"php": "^8.0",
... as a virtual package (other name: "plateform package"), and not a package that could be put in vendor.
Then, if we extend a little the following definition of require...
Map of packages required by this package. The package will not be installed unless those requirements can be met.
(https://getcomposer.org/doc/04-schema.md#require)
..., then we can say that "if server's PHP interpretor's version doesn't meet the requirements versions, then Composer will raise a fatal error or something like that.
**Conclusion: being seen as a "virtual/plateform package" by Composer, php won't be installed (put) in vendor directory. It will just make Composer to check if server PHP version matches or not the requirements (if not, an error will be raised). This behavior is different than for other packages that would be, them, downloaded from for example Packagist and installed (put) inside vendor directory. **
I've just come across the https://github.com/FriendsOfPHP/security-advisories tool which looks a great way to automatically scan for the vulnerabilities that are in that community-contributed database.
It scans a composer.lock file for packages with vulnerabilities. However, it's made me realise that my understanding of Composer is not what it should be!
I have a project that has a composer.json file that requires a single demo/package. That demo package also has requirements, like demo/dep.
The result of running composer install --no-dev is that I have a composer.lock file which includes:
demo/package version 1.0
demo/dep version 1.2
All good so far, and running symfony security:check /path/to/my/project/composer.lock gives me a green light, no vulnerabilities.
However on close inspection of the files now in my vendor dir, I can see there's a vendor/demo/package/composer.lock file, which contains references to demo/dep at version 1.1 - which has a security vulnerability against it.
As I understand, I have the safer 1.2 version installed - so says my project's composer.lock file, but why is a composer.lock file included with the vendor's package?
Does that mean that the dodgy code is installed somewhere, too? Or can I just simply ignore the composer.lock files if there's a composer.lock file in a dir above it or such? composer show does not list the versions in the nested lock file. Or maybe I should ignore composer.lock files if there's no sibling ./vendor/ dir?
Why not simply inspect your folders to find a vulnerable version? If there was any, you should find a vendor folder within that package, that's where that package could have installed stuff from it's own composer.lock
Usually, only the composer.json of a package is evaluated to install dependencies. If there is a lock file within one package's folder, you should ask the maintainer of that package why this is the case, but for installing dependencies on your system, this does not matter.
Side note: writing "usually" refers to the standard model of installations. I've seen some crude stuff where Composer plugins put other rules in place, but this cannot be said for your project without knowing more about the structure.
An important security release for laravel-query-builder was launched.
Since I use it in my project, I want to check what version I am using. But I couldn't find it. I already searched in my composer.json file. Laravel version that is being used is "laravel/framework": "5.8.*".
Where is it located?
To check if this package is installed in your installation, type in your terminal:
composer show
It will show all your installed packages.
If you not installed this package with the command:
composer require spatie/laravel-query-builder
That package will not exist in your Laravel folder, because it's not a default package. And you do not have to worry.
Execute composer info | grep laravel-query-builder on your project root folder.
That will give you your installed version of the package, if the output is empty you don't have it installed.
I have never used Composer, but I want to use PHPSpreadsheet package, and it is recommended that Composer is used.
I am on a MAC using XAMPP and Netbeans.
I have installed Composer, and I have run the following command to get and install the PHPSpreadsheet package.
php ../../Composer/composer.phar require phpoffice/phpspreadsheet
I am running this in my project folder, (hence the ../../ to where Composer.phar is located.
This downloads the files into a vendor folder in my project folder.
What should I do then? Do I need to keep it in the Vendor folder, or can I move into a folder of my choice?
Netbeans has Composer options in the menus, but as far as I can see, this is for creating dependencies rather than installing packages.
I know I am totally missing the point of Composer somewhere, but have spent hours just trying to get this work.
Many thanks
You should really start with the docs -> https://getcomposer.org/doc/01-basic-usage.md
You have to keep the vendor directory - this is where all dependencies are kept. If you require more packages - then they will be installed in that directory.
After requring the package you have to load it so the PHP will know all the classes. Composer comes with great autolader. It is located by default in vendor/autoload.php. So what you have to do now is to require this file in your project. After that all classes from composer packages will be loaded automaticaly each time you use them in the code :)
I hope this will help you with this great tool. Cheers.
I know that we can always install a package via command:
composer require packageA
But I don't know if you guys ever have a situation like this:
You want to install a big size package "packageB" that your teammate added to composer.json and your wifi is slow so composer would take very very long to get the packageB. Then you have an idea:
"Maybe I try get the packageB zip from my teammate via flash drive and paste
it into my project."
And you did that, the package works as expected. Wonderful!
But then, you think again:
What if now I want to do the composer update other packages in my
project?
You try:
composer update
and then, what happen is composer will get the package again because you didn't use "composer install" or "composer update" to install packageB so composer doesn't know you have it.
(Sorry for the long explanation).
So my question is:
How do we let composer know that we have the package already so composer don't re-download the package again? Or this is the behavior of composer and I must always use "composer install/update", there is no other way?
And sorry, change to another wifi or find a faster internet connection is really not what I'm looking for. And I also know that we can install the package locally (see here: How to update a single composer package?).
Thanks in advance!
If we don't want to use repositories.
In my knowledge, the only option is to update you composer.json and composer.lock. Friend give you version 1.2 to vendor? Write in exactly version in composer.json and for composer.lock, you will need data from your friend too.
Run install then.
Should check, but not download any file. Still, problem is that all required libraries by this library, could be updated - you can only write down exactly version of them in file.
As default, I think, the didn't predict scenarios for that way.
This is the only solution for you, i know should work.
Composer does use caching heavily to reduce the amount of data to download. However this does not remove the need to download the package at least once.
Basically Composer has two modes to download: --prefer-dist will try to obtain a download URL for an archive file, and --prefer-source will try to obtain a copy of the version control system being used.
Both variants put the result into Composer's cache directory.
Over time you'll collect a couple of archive files locally, which allow for quick switches back and forth between existing version downloads, and newer versions will have to be downloaded once.
Also you can clone a git repository once, and Composer will try to reuse it when updating, by simply fetching new commits and checking out the appropriate tags. This still requires to clone the repository once.
You can work around cloning the repository by manually placing it at the correct spot, either by physically putting it there, or by symlinking the correct vendor directory. You can also make Composer aware of an official copy by adding the local copy as an entry to repositories. This will add this source to the existing collection of packages available from Packagist.