I'd like to use composer create-project to always pull the latest commit of the dev version I'm using. I've noticed a similar question exists but unfortunately it didn't help.
Currently I can do (e.g. for Drupal) composer create-project drupal/drupal test 8.4.*#dev but this will pull the nightly dev build. Instead, I'd like to be able to specify the commit hash I wish to pull from and thus ideally chase HEAD. Also, I'd like to do this with a one-liner if at all possible, without having to resort to a composer.json file.
Instead, I'd like to be able to specify the commit hash I wish to pull from and thus ideally chase HEAD.
Well, there is a syntax to specify a git commit hash: dev-master#hash or branch#hash. But this feature is not really supported by the Composer team. It might not work as expected on the create-project command.
Referencing: https://getcomposer.org/doc/04-schema.md#package-links
If you want to "ideally chase HEAD", you can try to leave the third parameter on create-project away (You can provide a version as third argument, otherwise the latest version is used.). Referencing: https://getcomposer.org/doc/03-cli.md#create-project
Maybe an alternative one-liner can help:
composer require "vendor/project:dev-master#hash" && composer install
Related
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.
My workflow for developing Symfony bundles is the following:
install Symfony
create a git repo for the new bundle, put a composer.json file in there
require the new package in the top-level composer.json, using #dev version
composer update newpackage => the package is downloaded, using git clone
work on the git clone inside vendors, committing and pushing from it
This is all fine and dandy, but seems to break in one specific case:
if I alter the 'autoload' tag of the already-installed package, it seems that Composer has a hard time taking it into account:
I tried 'composer dumpautoload', and it does nothing
I do not want to remove the composer.lock file, as I do not want other packages to be updated to a newer version, I only want to alter the autoload config of that one package
I tried removing by hand vendor/composer/installed.json, and what happened is that Composer re-downloaded all the vendors and wiped any data which happened to be in there at that moment
The same problem manifested itself when I did alter the autoload section of the package on a separate clone, pushed the changes to git and ran 'composer update mypackage' - although that might have been related to packagist not having received the ping from github.
I can of course alter by hand the composer.lock and vendor/composer/installed.json files, but that seems too hackish. It also does not gives the guarantee that user downloading the package the 1st time will see it working.
Try:
./composer.phar dumpautoload -o
It reads the composer.json files and rewrites all the autoload files which pick up the new paths.
dumpautoload uses the package information from vendor/composer/installed.json and not the individual composer.json files. You need to change the autoload info there, too.
The file installed.json is only being update when you run a
composer update
tl;dr: I'm having troubles forcing Composer to get latest changes to my local package. It seems, that problem is caused by latest change not being part of any release in packages repository.
I'm using yii2-language-picker in my project and have added it with instructions given in docs:
php composer.phar require --prefer-dist lajax/yii2-language-picker "1.*"
Recently extension's author has made a change. However, this change is not part of any release, because it is 1 commit after latest release. If I'm not mistaken (I'm quite new to Composer), this causes Composer to not update my local package -- after composer update or composer install I'm getting Nothing to install or update.
Because that latest change is not a part of any relase, I was suggested to edit composer.json file, change "lajax/yii2-language-picker": "1.*" in required section to "lajax/yii2-language-picker": "*" and issue another composer update.
I have also completely removed this package and installed it again with both "1.*" and "**".
None of these brought any effects. Composer still claims, that there is nothing to install or update.
What can be causing this situation? Is there anything I can do in this case, or the only option I'm left with is to sit down and wait until package / repository author will make that change part of another release?
I tried to manually update this package, but after composer status I'm getting No local changes and I'm woried, that all these changes will be lost, once actual package update will be released. Should I make any local changes in this situation or should I sit and wait?
Changing 1.* to dev-master probably solves your problem.
I've updated my Laravel installation with the following commands today (which is a few days after Laravel 4's release date):
php composer self-update
php composer update
You can have a look at my composer.json file here: http://paste.laravel.com/umX
In the Docs I've found out about the Maintenance Mode... (http://laravel.com/docs/configuration#maintenance-mode) Trying to use it returns:
[InvalidArgumentException]
Command "down" is not defined.
Command I've entered in the terminal for this exception:
php artisan down
My current version:
php artisan --version
Laravel Framework version 4.0.0
Any ideas? Did i miss something, am I still on some old version possibly?
Thanks in advance and best regards, Martin.
The fix for me was to update the 'providers' array in ./app/config/app.php. I thought I was doing a pretty good job of manually updating the L4 skeleton near the end of the beta period, but there was a minor change in that array (not sure which line) that allowed the 'down' command to finally appear in artisan.
The first thing I suggest you do is just run php artisan list to get a list of all the available commands. If the up and down commands aren't listed then you probably aren't fully updated.
If you have a bootstrap/compiled.php file try deleting it. Also make sure you pull the latest changes in from the laravel/laravel GitHub repository to update your application skeleton.
Once you've done the above you can again check for the existence of the commands by running php artisan list.
In app/start/global.php (or app/start/artisan.php), you need:
App::down(function() { return Response::make("Be right back!", 503); });
don't you?
Perhaps you could also try updating laravel via composer "composer update" in CLI.
I've just installed a clean Laravel 4 clone and tryed the maintenance mode with it.
Everything's working as supposed...
I've also compared the composer.json files + I'm pretty sure I've done nothing wrong updating to the stable release version even thought my app/start/* php-files remain unchanged.
Summary:
Composer seems to not override the php files in app/start/* which would be needed in order to get the maintenance mode working correctly. Probably there are even more files not being updated. This also makes a lot of sense, since you could have done some important customizations to your application there.
Correct me if I'm wrong... I'll start importing my package into a clean install thought. Don't want to run into more trouble due to this.
Best Regards, Martin.
How can i tell composer to ignore certain deps while running update?
I know i can update certain packages with:
php composer.phar update vendor/package vendor/package2
But i would like to have it the other way around by telling composer to update all except these packages.
In my case the command would be much shorter than the above, since i just want to ignore some experimental bundle.
And i dont want to delete it fully, which would probably happen, if I clear the bundle from the require list.
I think this is not possible by now.
However you can try to shorten the explicit update calls with wildcards:
php composer.phar update doctrine/*
As described here: http://getcomposer.org/doc/03-cli.md#update
But composer will ask you if you want to keep local changes if composer detects such.
The package has modified files:
D code/controller/yourFile.php
Discard changes [y,n,v,s,?]?
Also you can use the stash/apply mechanism for git repos which is featured in composer.
https://github.com/composer/composer/pull/1188
Also helpful:
Composer: Develop directly in vendor packages
Maybe it wasn't possible at that time, but nowadays you can do it like this
composer update --ignore-platform-reqs vendor/package