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 :)
Related
I'm trying to use composer to automatically clone a git repository from github that isn't in packagist but it's not working and I can't figure out what am I doing wrong.
I think I have to include it among "repositories" like so:
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
and then probably list it in "require" section. It should be similar to this example but it doesn't work. It just gives this error:
Your requirements could not be resolved to an installable set of packages.
Have anyone tried to do something like this already?
That package in fact is available through packagist. You don't need a custom repository definition in this case. Just make sure you add a require (which is always needed) with a matching version constraint.
In general, if a package is available on packagist, do not add a VCS repo. It will just slow things down.
For packages that are not available via packagist, use a VCS (or git) repository, as shown in your question. When you do, make sure that:
The "repositories" field is specified in the root composer.json (it's a root-only field, repository definitions from required packages are ignored)
The repositories definition points to a valid VCS repo
If the type is "git" instead of "vcs" (as in your question), make sure it is in fact a git repo
You have a require for the package in question
The constraint in the require matches the versions provided by the VCS repo. You can use composer show <packagename> to find the available versions. In this case ~2.3 would be a good option.
The name in the require matches the name in the remote composer.json. In this case, it is gedmo/doctrine-extensions.
Here is a sample composer.json that installs the same package via a VCS repo:
{
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
"require": {
"gedmo/doctrine-extensions": "~2.3"
}
}
The VCS repo docs explain all of this quite well.
If there is a git (or other VCS) repository with a composer.json available, do not use a "package" repo. Package repos require you to provide all of the metadata in the definition and will completely ignore any composer.json present in the provided dist and source. They also have additional limitations, such as not allowing for proper updates in most cases.
Avoid package repos (see also the docs).
At the time of writing in 2013, this was one way to do it. Composer has added support for better ways: See #igorw 's answer
DO YOU HAVE A REPOSITORY?
Git, Mercurial and SVN is supported by Composer.
DO YOU HAVE WRITE ACCESS TO THE REPOSITORY?
Yes?
DOES THE REPOSITORY HAVE A composer.json FILE
If you have a repository you can write to: Add a composer.json file, or fix the existing one, and DON'T use the solution below.
Go to #igorw 's answer
ONLY USE THIS IF YOU DON'T HAVE A REPOSITORY
OR IF THE REPOSITORY DOES NOT HAVE A composer.json AND YOU CANNOT ADD IT
This will override everything that Composer may be able to read from the original repository's composer.json, including the dependencies of the package and the autoloading.
Using the package type will transfer the burden of correctly defining everything onto you. The easier way is to have a composer.json file in the repository, and just use it.
This solution really only is for the rare cases where you have an abandoned ZIP download that you cannot alter, or a repository you can only read, but it isn't maintained anymore.
"repositories": [
{
"type":"package",
"package": {
"name": "l3pp4rd/doctrine-extensions",
"version":"master",
"source": {
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git",
"reference":"master"
}
}
}
],
"require": {
"l3pp4rd/doctrine-extensions": "master"
}
You can include git repository to composer.json like this:
"repositories": [
{
"type": "package",
"package": {
"name": "example-package-name", //give package name to anything, must be unique
"version": "1.0",
"source": {
"url": "https://github.com/example-package-name.git", //git url
"type": "git",
"reference": "master" //git branch-name
}
}
}],
"require" : {
"example-package-name": "1.0"
}
Just tell composer to use source if available:
composer update --prefer-source
Or:
composer install --prefer-source
Then you will get packages as cloned repositories instead of extracted tarballs, so you can make some changes and commit them back. Of course, assuming you have write/push permissions to the repository and Composer knows about project's repository.
Disclaimer: I think I may answered a little bit different question, but this was what I was looking for when I found this question, so I hope it will be useful to others as well.
If Composer does not know, where the project's repository is, or the project does not have proper composer.json, situation is a bit more complicated, but others answered such scenarios already.
I try to join the solutions mention here as there are some important points to it needed to list.
As mentioned in the #igorw's answer the URL to repository must be in that case specified in the composer.json file, however since in both cases the composer.json must exist (unlike the 2nd way #Mike Graf) publishing it on the Packagist is not that much different (furthermore also Github currently provides packages services as npm packages), only difference instead of literally inputting the URL at the packagist interface once being signed up.
Moreover, it has a shortcoming that it cannot rely on an external library that uses this approach as recursive repository definitions do not work in Composer. Furthermore, due to it, there seems to be a "bug" upon it, since the recursive definition failed at the dependency, respecifying the repositories explicitly in the root does not seem to be enough but also all the dependencies from the packages would have to be respecified.
With a composer file (answered Oct 18 '12 at 15:13 igorw)
{
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
"require": {
"gedmo/doctrine-extensions": "~2.3"
}
}
Without a composer file (answered Jan 23 '13 at 17:28 Mike Graf)
"repositories": [
{
"type":"package",
"package": {
"name": "l3pp4rd/doctrine-extensions",
"version":"master",
"source": {
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git",
"reference":"master"
}
}
}
],
"require": {
"l3pp4rd/doctrine-extensions": "master"
}
I was encountering the following error: The requested package my-foo/bar could not be found in any version, there may be a typo in the package name.
If you're forking another repo to make your own changes you will end up with a new repository.
E.g:
https://github.com/foo/bar.git
=>
https://github.com/my-foo/bar.git
The new url will need to go into your repositories section of your composer.json.
Remember if you want refer to your fork as my-foo/bar in your require section, you will have to rename the package in the composer.json file inside of your new repo.
{
"name": "foo/bar",
=>
{
"name": "my-foo/bar",
If you've just forked the easiest way to do this is edit it right inside github.
In my case, I use Symfony2.3.x and the minimum-stability parameter is by default "stable" (which is good). I wanted to import a repo not in packagist but had the same issue "Your requirements could not be resolved to an installable set of packages.".
It appeared that the composer.json in the repo I tried to import use a minimum-stability "dev".
So to resolve this issue, don't forget to verify the minimum-stability. I solved it by requiring a dev-master version instead of master as stated in this post.
If you want to use a composer.json from GitHub you would look at this example (under the VCS section).
The package section is for packages that do not have the composer.json. However, you didn't follow that example as well or it would also have worked. Do read what it says about package repositories:
Basically, you define the same information that is included in the composer repository's packages.json, but only for a single package. Again, the minimum required fields are name, version, and either of dist or source.
https://stackoverflow.com/a/14485706/11716408
{
"repositories": [
{
"type":"package",
"package": {
"name": "tiagof2/materializecss-laravel-pagination",
"version":"v1.0.3",
"source": {
"url": "https://github.com/tiagofrancafernandes/materializecss-laravel-pagination.git",
"type": "git",
"reference":"v1.0.3"
}
}
}
],
"require": {
"tiagof2/materializecss-laravel-pagination": "v1.0.3"
},
}
composer update
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.
I have a private git repository located at username#somedomain.com, that i access with ssh.
I need to include 2 projects from the same server, and i do like this:
"require": {
"proj1": "dev-master",
"proj2": "dev-master",
},
"repositories": [
{
"type": "vcs",
"url": "username#somedomain.com:proj1.git"
},
{
"type": "vcs",
"url": "username#somedomain.com:proj2.git"
}
]
May happen that these repo grow in number. Is there any chance where i can configure something like
"url": "username#somedomain.com"
and let composer resolve where to find the packages?
Please note that i don't want to use satis or any other package manager.
There is only way to handle private projects without direct definding insided composer.json -- use Satis or Toran Proxy.
https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md
Composer allows you to add repositories that will also be scanned for packages in addition to using Packagist.
Note that you didn't specify which package is to be found in these repositories because Composer will scan these for composer.json itself and detect which packages are available (one repository might contain more than one package in different branches!).
Because every repository is independent of each other, you have to mention them all individually.
Also note that Composer only allows to add these repositories on the root level, so you have to repeat every repository that is being used in your dependencies again in the root project, even if that root project does not have a direct dependency to a package that is provided in such a repository.
The way to avoid this is to have a Packagist-like repository that is created via Satis, Toran or a local installation of Packagist itself. I recommend going that way even if you say you don't want to.
I have a library foo/foo-lib which requires a specific commit from GitHub:
{
"name": "foo/foo-lib",
"repositories": [
{
"type": "vcs",
"url": "https://github.com/KnpLabs/Gaufrette.git"
}
],
"require": {
"knplabs/gaufrette": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"
}
}
and it works fine:
$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
- Updating knplabs/gaufrette dev-master (2633721 => 2633721)
Checking out 2633721877cae79ad461f3ca06f3f77fb4fce02e
Generating autoload files
but when I require that library in other project:
{
"name": "bar/bar-app",
"repositories": [
{
"type": "vcs",
"url": "ssh://git.example.com/foo-lib"
}
],
"require-dev": {
"foo/foo-lib": "dev-master"
}
}
it yields dependency error:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for foo/foo-lib dev-master -> satisfiable by foo/foo-lib[dev-master].
- foo/foo-lib dev-master requires knplabs/gaufrette dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e -> no matching package found.
So my question is: how to correctly require the specific commit from GitHub in my library, so that it would be available in dependent packages?
You'll have to explicitly require the Gaufrette library at that hash, with a dev flag, in both your library and your application. Something like this should work in the application composer.json:
{
"name": "bar/bar-app",
"repositories": [
{
"type": "vcs",
"url": "ssh://git.example.com/foo-lib"
}
],
"require-dev": {
"foo/foo-lib": "dev-master",
"knplabs/gaufrette": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"
}
}
From the documentation:
If one of your dependencies has a dependency on an unstable package
you need to explicitly require it as well, along with its sufficient
stability flag.
The documentation also suggests that you'll need to include the repository for Gaufrette in your bar/bar-app Composer file, though it sounds like this wasn't necessary in this case. I'm not sure why.
Here is how you do it on the command line:
composer update knplabs/gaufrette:dev-master#2633721 --with-dependencies
You don't have to use the whole hash, a hash seven characters long seems to dothe trick. As mentioned above, your project will need to support dev - which it will complain about if not already set. Also, use --with-dependencies to get any dependencies of the one you are updating.
If you're making changes for a Git Repository by forking make sure that you use the
The package name is actually defined in the package's own composer.json file - so even though I'd forked the package to my own joshuapaling github account, and the package was now residing at the URL https://github.com/joshuapaling/Cake-Resque.git, that had not influenced the package's name at all, from composers perspective.
A stupid error - but I'm new to composer, and it wasn't clear at first! So, I hope this helps someone else with the same problem.
I'm trying to use composer to automatically clone a git repository from github that isn't in packagist but it's not working and I can't figure out what am I doing wrong.
I think I have to include it among "repositories" like so:
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
and then probably list it in "require" section. It should be similar to this example but it doesn't work. It just gives this error:
Your requirements could not be resolved to an installable set of packages.
Have anyone tried to do something like this already?
That package in fact is available through packagist. You don't need a custom repository definition in this case. Just make sure you add a require (which is always needed) with a matching version constraint.
In general, if a package is available on packagist, do not add a VCS repo. It will just slow things down.
For packages that are not available via packagist, use a VCS (or git) repository, as shown in your question. When you do, make sure that:
The "repositories" field is specified in the root composer.json (it's a root-only field, repository definitions from required packages are ignored)
The repositories definition points to a valid VCS repo
If the type is "git" instead of "vcs" (as in your question), make sure it is in fact a git repo
You have a require for the package in question
The constraint in the require matches the versions provided by the VCS repo. You can use composer show <packagename> to find the available versions. In this case ~2.3 would be a good option.
The name in the require matches the name in the remote composer.json. In this case, it is gedmo/doctrine-extensions.
Here is a sample composer.json that installs the same package via a VCS repo:
{
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
"require": {
"gedmo/doctrine-extensions": "~2.3"
}
}
The VCS repo docs explain all of this quite well.
If there is a git (or other VCS) repository with a composer.json available, do not use a "package" repo. Package repos require you to provide all of the metadata in the definition and will completely ignore any composer.json present in the provided dist and source. They also have additional limitations, such as not allowing for proper updates in most cases.
Avoid package repos (see also the docs).
At the time of writing in 2013, this was one way to do it. Composer has added support for better ways: See #igorw 's answer
DO YOU HAVE A REPOSITORY?
Git, Mercurial and SVN is supported by Composer.
DO YOU HAVE WRITE ACCESS TO THE REPOSITORY?
Yes?
DOES THE REPOSITORY HAVE A composer.json FILE
If you have a repository you can write to: Add a composer.json file, or fix the existing one, and DON'T use the solution below.
Go to #igorw 's answer
ONLY USE THIS IF YOU DON'T HAVE A REPOSITORY
OR IF THE REPOSITORY DOES NOT HAVE A composer.json AND YOU CANNOT ADD IT
This will override everything that Composer may be able to read from the original repository's composer.json, including the dependencies of the package and the autoloading.
Using the package type will transfer the burden of correctly defining everything onto you. The easier way is to have a composer.json file in the repository, and just use it.
This solution really only is for the rare cases where you have an abandoned ZIP download that you cannot alter, or a repository you can only read, but it isn't maintained anymore.
"repositories": [
{
"type":"package",
"package": {
"name": "l3pp4rd/doctrine-extensions",
"version":"master",
"source": {
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git",
"reference":"master"
}
}
}
],
"require": {
"l3pp4rd/doctrine-extensions": "master"
}
You can include git repository to composer.json like this:
"repositories": [
{
"type": "package",
"package": {
"name": "example-package-name", //give package name to anything, must be unique
"version": "1.0",
"source": {
"url": "https://github.com/example-package-name.git", //git url
"type": "git",
"reference": "master" //git branch-name
}
}
}],
"require" : {
"example-package-name": "1.0"
}
Just tell composer to use source if available:
composer update --prefer-source
Or:
composer install --prefer-source
Then you will get packages as cloned repositories instead of extracted tarballs, so you can make some changes and commit them back. Of course, assuming you have write/push permissions to the repository and Composer knows about project's repository.
Disclaimer: I think I may answered a little bit different question, but this was what I was looking for when I found this question, so I hope it will be useful to others as well.
If Composer does not know, where the project's repository is, or the project does not have proper composer.json, situation is a bit more complicated, but others answered such scenarios already.
I try to join the solutions mention here as there are some important points to it needed to list.
As mentioned in the #igorw's answer the URL to repository must be in that case specified in the composer.json file, however since in both cases the composer.json must exist (unlike the 2nd way #Mike Graf) publishing it on the Packagist is not that much different (furthermore also Github currently provides packages services as npm packages), only difference instead of literally inputting the URL at the packagist interface once being signed up.
Moreover, it has a shortcoming that it cannot rely on an external library that uses this approach as recursive repository definitions do not work in Composer. Furthermore, due to it, there seems to be a "bug" upon it, since the recursive definition failed at the dependency, respecifying the repositories explicitly in the root does not seem to be enough but also all the dependencies from the packages would have to be respecified.
With a composer file (answered Oct 18 '12 at 15:13 igorw)
{
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
"require": {
"gedmo/doctrine-extensions": "~2.3"
}
}
Without a composer file (answered Jan 23 '13 at 17:28 Mike Graf)
"repositories": [
{
"type":"package",
"package": {
"name": "l3pp4rd/doctrine-extensions",
"version":"master",
"source": {
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git",
"reference":"master"
}
}
}
],
"require": {
"l3pp4rd/doctrine-extensions": "master"
}
I was encountering the following error: The requested package my-foo/bar could not be found in any version, there may be a typo in the package name.
If you're forking another repo to make your own changes you will end up with a new repository.
E.g:
https://github.com/foo/bar.git
=>
https://github.com/my-foo/bar.git
The new url will need to go into your repositories section of your composer.json.
Remember if you want refer to your fork as my-foo/bar in your require section, you will have to rename the package in the composer.json file inside of your new repo.
{
"name": "foo/bar",
=>
{
"name": "my-foo/bar",
If you've just forked the easiest way to do this is edit it right inside github.
In my case, I use Symfony2.3.x and the minimum-stability parameter is by default "stable" (which is good). I wanted to import a repo not in packagist but had the same issue "Your requirements could not be resolved to an installable set of packages.".
It appeared that the composer.json in the repo I tried to import use a minimum-stability "dev".
So to resolve this issue, don't forget to verify the minimum-stability. I solved it by requiring a dev-master version instead of master as stated in this post.
If you want to use a composer.json from GitHub you would look at this example (under the VCS section).
The package section is for packages that do not have the composer.json. However, you didn't follow that example as well or it would also have worked. Do read what it says about package repositories:
Basically, you define the same information that is included in the composer repository's packages.json, but only for a single package. Again, the minimum required fields are name, version, and either of dist or source.
https://stackoverflow.com/a/14485706/11716408
{
"repositories": [
{
"type":"package",
"package": {
"name": "tiagof2/materializecss-laravel-pagination",
"version":"v1.0.3",
"source": {
"url": "https://github.com/tiagofrancafernandes/materializecss-laravel-pagination.git",
"type": "git",
"reference":"v1.0.3"
}
}
}
],
"require": {
"tiagof2/materializecss-laravel-pagination": "v1.0.3"
},
}
composer update