Composer dependency issue with external repository - php

I have written a library that I want to use in another project. However, when I add the library dependency to my project I get the following error after running composer update -vvv:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for my/library dev-master -> satisfiable by my/library[dev-master].
- my/library dev-master requires doctrine/migrations dev-master -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
This error is very confusing to me since my project has my library as it's only dependency, i.e. my project composer.json looks like this:
{
"name": "my/project",
"type": "project",
"description": "My project",
"autoload": {
"psr-0": { "MyNamespace\\": ["src/", "tests/src/"] }
},
"repositories": [ {
"type": "vcs",
"url": "git#bitbucket.org:my/library"
} ],
"require": {
"php": ">=5.5",
"my/library": "dev-master"
},
"require-dev": {
"phpunit/phpunit": "3.*"
}
}
As you can see, pretty straight forward. The reason the version of my library is requiring dev-master is because master is currently the only branch I work on (I work alone, no need for other branches at the moment).
So far the only way for the resolve this problem is by adding the dependencies of my library composer.json to my project's composer.json which seems like an unnecessary step.
How can I resolve this dependency issue?

It looks to me as if it is a stability issue. Add the following two lines to your composer.json:-
"minimum-stability": "dev",
"prefer-stable": true,
ref:- minimum-stability & prefer-stable
Hopefully that will sort out your problem.

Related

Composer error: no matching package found

I have two Symfony projects: project-a (root project) and project-b.
My composer.json file from project-a contains:
{
"name": "myprojects/project-a",
"require": {
"myprojects/project-b": "dev-master",
},
"repositories": [
{
"type": "vcs",
"url": "git#bitbucket.org:MYPROJECTS/project-b.git"
}
]
}
And my composer.json from project-b:
{
"name": "myprojects/project-b",
"require": {
"guzzlehttp/guzzle": "^6.3"
}
}
I need to update project-b but when I execute the command composer update myprojects/project-b from project-a, I get this composer error:
[Composer\DependencyResolver\SolverProblemsException]
Problem 1
Installation request for myprojects/project-b dev-master -> satisfiable by
myprojects/project-b[dev-master].
myprojects/project-b dev-master requires guzzlehttp/guzzle ^6.3 -> no matching package found.
Potential causes:
A typo in the package name
The package is not available in a stable-enough version according to your minimum-stability setting
I have tried solve this adding "minimum-stability": "dev" property to both composer.json files, but it doesn't works.. How can I solve this?
Thanks.
As commented in guzzle/guzzle issue 861:
Looks like an issue with your caching.
Try clearing your composer cache, and self-update composer, then try again.
The OP Wildchild confirms in the comments:
composer clear cache and self-update solves my problem
"minimum-stability": "dev" is not needed.

How do I use my forked version of a repo in Composer?

I was working on a project and ended up having to make a small change to one of the packages I'm using.
That package is: shopifyextras/shopify-php-api-wrapper
Which you can find here: https://github.com/ShopifyExtras/PHP-Shopify-API-Wrapper
My previous composer.json file looked like this:
{
"require": {
"monolog/monolog": "1.*",
"shopifyextras/shopify-php-api-wrapper": "^1.1"
},
"autoload": {
"psr-0": { "MyApp\\": "src/" }
}
}
After forking the repo and making my changes (I forgot to create a new branch first, but created the branch after committing to master, and pushed it to github - I don't think this should cause any issues given that the branch exists and it does point to the correct head), I then updated my composer.json to use my fork.
After reading the composer docs (https://getcomposer.org/doc/05-repositories.md#vcs) I updated my composer.json to the following:
{
"minimum-stability": "dev",
"prefer-stable" : true,
"repositories": [
{
"type": "git",
"url": "https://github.com/JonLaliberte/PHP-Shopify-API-Wrapper.git"
}
],
"require": {
"monolog/monolog": "1.*",
"shopifyextras/shopify-php-api-wrapper": "dev-risksbugfix"
},
"autoload": {
"psr-0": { "MyApp\\": "src/" }
}
}
When I run composer update I receive the following error:
$ composer update --verbose
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- The requested package shopifyextras/shopify-php-api-wrapper could not be found in any version, there may be a typo in the package name.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.
I have tried:
Using "risksbugfix" instead of "dev-risksbugfix"
Using type "vcs" instead of git"
Removing ".git" from the repo URL
Using "jonlaliberte/shopify-php-api-wrapper" instead of "shopifyextras/shopify-php-api-wrapper"
Any help would be greatly appreciated. Thanks!
Branch Alias
If you alias a non-comparable version (such as dev-develop) dev- must
prefix the branch name.
You branch is a non-comparable version dev-riskbugfix.
You might need to prefix it with dev-: dev-dev-riskbugfix.
Or rename the branch to riskbugfix and get rid of the dev-, then the alias would be dev-riskbugfix.

retrieving fork with composer

This has been discussed multiple times in multiple questions on SO, but all the answers given refuse to work for me accept this answer:
Contributing to open source bundles from vendor directory?
I've tested this on multiple machines, so I'm pretty sure it's not an isolated incident.
But using the type "package" is considered bad practice I read. Can someone explain to me why this is not working? It won't load the forked repository!
{
"repositories":
[
{
"type": "vcs",
"url": "https://github.com/flyandi/lumen-doctrine.git"
}
],
"require": {
"nordsoftware/lumen-doctrine": "dev-master#dev"
}
}
update
So it turns out it has something todo with the stability of packages more about that here:
https://igor.io/2013/02/07/composer-stability-flags.html
I then tried this which works:
{
"repositories":
[
{
"type": "vcs",
"url": "https://github.com/flyandi/lumen-doctrine.git"
}
],
"require": {
"nordsoftware/lumen-doctrine": "dev-master#dev"
},
"prefer-stable" : true,
"minimum-stability": "dev"
}
What I don't understand is way the #dev flag doesn't work though? Can someone elaborate?
Composer tries to resolve into a stable set of packages by default.
It won't resolve, because the package you are fetching (via alias)
uses development dependencies itself. The dependency doctrine/orm of the package you are fetching lumen-doctrine is required in dev mode.
And the need for this development dependency bubbles up to your package.
When you add dev-master or dev-master#dev for nordsoftware/lumen-doctrine
it works only for this package.
The #dev makes explicit, what we already know because of the dev- prefix: its a request for a dev version, but it doesn't change the stability for all packages - and it doesn't set the stability for dependencies of the package.
The installation request for nordsoftware/lumen-doctrineis satisfiable by dev-master (and by a number of tagged versions).
The problem is that the package doctrine/orm is not satisfiable, because nordsoftware/lumen-doctrine dev-master requires doctrine/orm ~2.6#dev
Your options are:
set the minimum-stability of all packages to dev (you already have that)
or just add doctrine/orm and go lower in stability only on this package
by using ~2.6#dev or 2.6.x-dev
{
"repositories":
[
{
"type": "vcs",
"url": "https://github.com/flyandi/lumen-doctrine.git"
}
],
"require": {
"nordsoftware/lumen-doctrine": "dev-master",
"doctrine/orm": "~2.6#dev"
}
}

composer custom repository package can't pull dependency

Running into an issue with composer. I have a main project that im working on with some some small libraries I built that I want to more easily share between my projects. They are nowhere near release ready, so I do't want to add them to packagist, but when I require 1 that requires another, it will error unless I ad that custom repository as well on my master composer.json
also, the tertiary requirement can not resolve packagist libraries
Your requirements could not be resolved to an installable set of packages.
Problem 1
- ethereal/simpleCache dev-master requires predis/predis ^1.1#dev -> no matching package found.
- ethereal/simpleCache dev-master requires predis/predis ^1.1#dev -> no matching package found.
- Installation request for ethereal/simplecache dev-master -> satisfiable by ethereal/simpleCache[dev-master].
Main Project composer.json:
{
"name": "ethereal/SimpleTable",
"type": "project",
"repositories": [
{
"type": "vcs",
"url": "https://github.com/mathus13/SimpleConfig.git"
}
],
"require": {
"php": ">=5.3.9",
"doctrine/dbal": "^2.6#dev",
"ethereal/SimpleConfig": "dev-master"
},
"require-dev": {
"phpunit/phpunit": "~4.8"
},
"autoload": {
"psr-4": {
"Ethereal\\": "lib"
}
}
}
config library: when running composer update in SimpleTable, Simple Cache will not be included unless explicitly required in SimpleTable.
{
"name": "ethereal/SimpleConfig",
"type": "project",
"version": "0.0.1",
"repositories": [
{
"type": "vcs",
"url": "https://github.com/mathus13/SimpleCache.git"
}
],
"require": {
"php": ">=5.3.9",
"ethereal/SimpleCache": "dev-master"
},
"require-dev": {
"phpunit/phpunit": "~4.8"
},
"autoload": {
"psr-4": {
"Ethereal\\": "lib"
}
}
}
cache library: when running composer update in SimpleTable, predis can not be resolved.
{
"name": "ethereal/simpleCache",
"type": "project",
"version": "0.0.1",
"require": {
"predis/predis": "^1.1#dev",
"php": ">=5.3.9"
},
"require-dev": {
"phpunit/phpunit": "~4.8"
},
"autoload": {
"psr-4": {
"Ethereal\\": "lib"
}
}
}
ethereal/SimpleTable depends on ethereal/SimpleConfig in dev stability, which depends on ethereal/SimpleCache in dev stability, which depends on predis/predis in dev stability (version 1.1 hasn't been released yet).
Packages included into the main package cannot define any stability, the only stability allowed is the one in the main package. And that is "stable" by default.
You made ONE exception from this rule by depending on "dev-master" for SimpleConfig", but this is not inherited.
You have multiple solutions:
Tag your software. Tags declare it more stable than "dev", and it generally is a good idea to only use tagged software in production.
Include ALL your own packages that are needed in the main package, even if they are not directly used. This will add exceptions from the general stability for them, and allow Composer to resolve any sub dependencies.
You can add "minimum-stability":"dev" to the main composer.json, but this will also allow all other packages to be installed from a branch. Using branches however is a very bad thing, because you cannot easily go back to the version that was working before you did the update - the branch pointer moves only forward. Only tags will point to the same software forever.
Adding "prefer-stable":true" is some sort of workaround for the problem that 3 introduces for packages that are already available in a stable release version. However you still have the problem of not being able to go back to your own packages' earlier versions, because you are using a branch.
If you are still developing these packages, depending on branches may seem necessary. However, a good package will be able to be developed and tested standalone, with barely any foreign code present apart from interface definitions (which will be used to mock everything), so putting all code together into a mixture of repos with branches checked out usually is an invitation for writing code that isn't cleanly separated.
If any of these packages is already done (I'd say "good enough"), tag it and depend on that version instead of a branch. You can always release new versions if you find bugs or want to add new features.

composer dependency json config

I have the following json configs for composer.phar. Unfortunately, I get this error, and I don't understand why:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for myproject/cmsapp dev-master -> satisfiable by myproject/cmsapp[dev-master].
- myproject/cmsapp dev-master requires zendframework/zendframework dev-master -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
Read <http://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.
cms config:
{
"name": "myproject\/cms",
"description": "myproject CMS Tool",
"license": "GPL",
"keywords": [
"myproject",
"cms",
"framework",
"zf2"
],
"homepage": "http:\/\/avadon.com\/myproject\/cms\/",
"require": {
"php": ">=5.3.3",
"myproject/cmsapp": "dev-master"
},
"repositories": {
"myproject/cmsapp": {
"type": "git",
"url": "https:\/\/github.com\/myproject\/cmsapp.git"
}
}
}
cmsapp config:
{
"name": "myproject/cmsapp",
"repositories": {
"zendframework/zendframework": {
"type": "git",
"url": "https://github.com/zendframework/zf2.git"
}
},
"require": {
"php": ">=5.3.3",
"zendframework/zendframework" : "dev-master"
}
}
Can anyone try and explain to me this error?
You are using a software from a development branch. This will only be allowed if you configure your composer.json to accept development software. Usually you shouldn't do this.
Especially including the development branch from Zend framework is likely to break your software more than once if large enough updates occur. If you want the latest and greatest, you'd still have to call composer update all the time to fetch the newest commits, so it's less error-prone to simply require something like "2." for "any version 2 framework", or maybe even stricter "2.3." for a released, working version of the 2.3 version line.
The same would be true for your own software - do tag it!
But if you want to experience unintentional software incompatibilities yourself, you can add a "minimum-stability":"dev" to your cms config's composer.json and include all development versions of the world.

Categories