composer custom repository package can't pull dependency - php

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.

Related

Composer multi-level dependency with private repos

I got following propblem:
I have 6 private repositories on bitbucket
app
implementation1
implementation2
core
bundle1
bundle2
App is my main - "root" package.
Now the app can have multiple implementations in composer.json along with core package
and than core has multiple bundles in its composer.json
The problem is that when I use
composer install
in my core package - it normally downloads bundle1 along with bundle2 inside core/vendor folder.
But when I try to install packages from app - it gives me following error:
Problem 1
- Installation request for company/app-core-bundle dev-master -> satisfiable by company/app-core-bundle[dev-master].
- company/app-core-bundle dev-master requires company/app-bundle1-bundle * -> no matching package found.
The workaround I've found is to specify all repositories in app/composer.json but it's bad solution and it's not what dependencies are used for.
Here are 2 parts of composer.json:
app/composer.json
{
"name": "company/app",
"version": "master",
"type": "project",
"minimum-stability": "dev",
"license": "proprietary",
"repositories": [
{
"type": "git",
"url":"git#bitbucket.org:username/company-app-core.git"
}
],
"require": {
"php": ">=5.5.9",
...
"company/app-core-bundle": "dev-master"
}
}
company-app-core/composer.json
{
"name": "company/app-core-bundle",
"version": "master",
"type": "symfony-bundle",
"minimum-stability": "dev",
"license": "proprietary",
"repositories": [
{
"type": "git",
"url":"git#bitbucket.org:username/company-app-bundle1.git"
},
{
"type": "git",
"url":"git#bitbucket.org:username/company-app-bundle2.git"
}
],
"require": {
"php": ">=5.5",
"company/app-bundle1-bundle": "*",
"company/app-bundle2-bundle": "*"
}
}
company-app-bundle1/composer.json
{
"name": "company/app-bundle1-bundle",
"version": "master",
"type": "symfony-bundle",
"minimum-stability": "dev",
"license": "proprietary",
"require": {
"php": ">=5.5",
...
some other 3rd company bundles like FOS
}
}
It's a 2 level dependency, my repos have to be private and I don't want to play around with Satis right now.
Thanks for any help. :)
There is no better solution for you.
You have to provide the meta data of every repository hosting a package somehow. Composer can find out about the public packages because it knows how to ask packagist.org. For private repos this cannot be done, so someone has to give Composer a pointer where to get the meta data instead.
There are basically two ways: The one you don't want to use is to use an additional instance doing the same thing Packagist does, by either running your own instance of Packagist, or Satis, or Toran Proxy.
The other way is to list each repository individually in ALL composer.json files that would ever need the package hosted there. This clearly is the inferior solution because it means that you constantly have to add ALL repositories you have into ALL repositories' composer.json file, just in case any cross referenced dependencies occur. Additionally it probably slows things down because of the number of server connections involved when collecting the newest data during an update.
There is no silver bullet for you. Composer decided to not scan repositories recursively in order to be able to have acceptable run times. Only the root repository decides where to scan for packages, with using only Packagist being the default (which can be turned off), and additionally scanning either packagist-like instances, or repos.
Satis is still the easiest way to host private repos because it only requires running PHP on the command line, and then make the created files available via static HTTP hosting.
Packagist is a PHP application with dependencies to a database, redis, a cache, a mail server etc. - likely more complicated to set up than Satis.
Toran Proxy also is a PHP application, but without such dependencies (according to the website - I have no experience using it). You'd only need a vhost able to run the main script.
For all of them, you'd have to get the configuration right, add the list of your private repositories for them to scan, and then add the URL of your new Composer information source to all composer.json files in all your private repositories - but this has to be done only one final time, after that this URL stays the same and points to updated meta data of all your repos.
You need to specify all private packages in root level of composer.json. As was stated already - composer won't do recursive scanning. I strongly suggest using Toran Proxy. This will solve the problem. Satis is also an option, but Toran requires almost no configuration and have very nice GUI :)

Why isn't Composer able to find/install my package for Laravel 5.2?

I am using Laravel 5.2.23 and am unable to pull in my new package, bsapaka/metattribute. I get the exception:
[InvalidArgumentException]
Could not find package bsapaka/metattribute at any version for your minimum-stability (stable). Check the package spelling or your minimum-stability
Composer seems to have it:
Running composer show bsapaka/metattribute returns:
name : bsapaka/metattribute
descrip. : classes for Laravel attributes
keywords : attribute, attributes, properties, alias, meta attribute
versions : dev-master
type : library
(more)
So I am wondering if I am missing something in the composer.json:
{
"name": "bsapaka/metattribute",
"type": "library",
"description": "classes for Laravel attributes",
"keywords": [
"attribute",
"attributes",
"properties",
"meta attribute",
"alias"
],
"homepage": "https://github.com/bsapaka/metattribute",
"license": "MIT",
"require": {
"illuminate/support": "~5.1",
"php" : "~5.5|~7.0"
},
"require-dev": {
"phpspec/phpspec": "~2.2"
},
"autoload": {
"psr-4": {
"bsapaka\\metattribute\\": "src/"
}
},
"minimum-stability": "stable"
}
I have done a good bit of docs reading, troubleshooting, adding in mininum-stability, checking the versioning, comparing against other packages, validating JSON, looking for the tidbits I missed etc, and at this point I could really use some guidance on where I might be going wrong. Thanks for reading, and I appreciate your help.
You don't have any version tag defined in your master branch on GitHub.
If there is no version tag then Composer doesn't know which version is the stable one. So if you have "minimum-stability": "stable" in the project which is requiring your self made package it can't find any stable version.
Create a new tag (e.g. 1.0.0) in your master branch on GitHub to declare the latest commit as stable or use the dev-master version and "minimum-stability": "dev" in the project which is requiring your self made package.

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 dependency constraint

Is there a possibility to let composer install a package only when the PHP version is below a given version.
https://github.com/ircmaxell/password_compat
"ircmaxell/password-compat": "dev-master"
I have found this package to be useful because I have a webserver which runs on PHP 5.4 and I need the password_* functions which are only available >= PHP 5.5.
Yes, there is. You can find the details on the packagist website, but basically, the package/dependency should be defined with this requirement:
{
"name": "ircmaxell/password-compat",
"description": "A compatibility library for the proposed simplified password hashing algorithm: https://wiki.php.net/rfc/password_hash",
"require": {
"php": "<5.5.*",
"phpunit/phpunit": "4.*"
}
}
As you can see, I've added "php": "<5.5.*" to the requirements for the package. You can add this requirement to your own composer.json file, by adding the dependency to your repositories array in the composer.json file, and add the requirements there:
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/ircmaxell/password_compat",
"require": {
"php": "<5.5.*",
}
}]
}
Something like that, I only have php5.5 installed, so I was unable to test this, though... but read through the documentation, I'm pretty sure it's possible.

Composer dependency issue with external repository

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.

Categories