Maybe a true stupid question but how can I really test a script with his dependencies before pushing the package to packagist?
I have tried with in myroot/composer.json :
"autoload": {
"psr-0": {
"myname/core": "vendor/myname"
}
}
in my vendor/myname/core/core.php I have something like this :
namespace myname/core;
die('it works');
in my vendor/myname/core/composer.json I have something like this :
{
"name": "myname/core",
"description": "xxx",
"license": "MIT",
"authors": [
{
"name": "my name",
"email": "",
"homepage": ""
}
],
"require": {
"php": ">=5.3.0",
"monolog/monolog": "1.0.*"
}
}
but it doesn't seem to work, when I try to run:
$ php composer.phar install
=> monolog/monolog is not installed =>
can somebody help me to understand?
I think this will help, I have a small blog article that I rewrote today that goes through creating packagist packages.
https://circlical.squarespace.com/blog/2013/6/24/distributing-a-zf2-module-through-packagist-github-and-composer
If you work it this way, I recommend checking it back down and testing inside a real integration -- I usually start like this, and push changes back up to GitHub whenever the changes are thoroughly tested.
Hope this helps.
Related
In my composer.json I have written:
"autoload": {
"psr-4": {
"Pmochine\\MyOwnPackage\\": "src/"
},
"files": [
"src/helpers.php"
]
},
But somehow even after composer dump-autoload the functions are not loaded. I get "Call to undefined function". To create the package I used a package generator. Maybe it has something to do that it creates a symlink in the vendor folder?
Inside helpers I have written
<?php
if (! function_exists('myowntest')) {
function myowntest()
{
return 'test';
}
}
In the package service provider, try adding this:
// if 'src/helpers.php' does not work, try with 'helpers.php'
if (file_exists($file = app_path('src/helpers.php'))) {
require $file;
}
What you are doing is best practise and should work. I took the composer.json from barryvdh/laravel-debugbar as an example. https://github.com/barryvdh/laravel-debugbar/blob/master/composer.json
{
"name": "barryvdh/laravel-debugbar",
"description": "PHP Debugbar integration for Laravel",
"keywords": ["laravel", "debugbar", "profiler", "debug", "webprofiler"],
"license": "MIT",
"authors": [
{
"name": "Barry vd. Heuvel",
"email": "barryvdh#gmail.com"
}
],
"require": {
"php": ">=5.5.9",
"illuminate/support": "5.1.*|5.2.*|5.3.*|5.4.*|5.5.*",
"symfony/finder": "~2.7|~3.0",
"maximebf/debugbar": "~1.13.0"
},
"autoload": {
"psr-4": {
"Barryvdh\\Debugbar\\": "src/"
},
"files": [
"src/helpers.php"
]
}
}
My guess is that you are not requiring your own package the correct way in the main composer.json?
Just need to call in your main project
composer update you/your-package
Source
The only thing that has worked for me is to run composer remove <vendor>/<package> and require it back again. The files section was ignored otherwise.
This seems to happen while developing locally the package and making changes on the composer.json file.
I am trying to build a PHP framework for the company I work in, and the most crazy thing is ever happing!
I have one package that depends on other both in development yet.
Just to get started (they are in different folders, of course!):
I ran composer init to create a package xxxxxx/core-min, and the result was:
{
"name": "xxxxxx/core-min",
"description": "Dummy Minimal Core",
"type": "library",
"license": "New BSD License",
"authors": [
{
"name": "My Name",
"email": "me#xxxxxx.com"
}
],
"minimum-stability": "dev",
"require": {}
}
Created the Packagist Service on Github, Submitted, and everything is okay so far.
I ran composer require xxxxxx/core-min and got it perfectly installed.
Then, I ran composer init to create a package xxxxxx/core, and the result was:
{
"name": "xxxxxx/core",
"description": "Dummy Full Core",
"type": "library",
"require": {
"xxxxxx/core-min": "dev-master"
},
"license": "New BSD License",
"authors": [
{
"name": "My Name",
"email": "me#xxxxxx.com"
}
],
"minimum-stability": "dev"
}
I ran composer require xxxxxx/core-min and got this message:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for zyneframework/core dev-master -> satisfiable by zyneframework/core[dev-master].
- zyneframework/core dev-master requires zyneframework/core-min dev-master -> satisfiable by zyneframework/core-min[dev-master] but these conflict with your requirements or minimum-stability.
This is tricking me out and I can't find any real solution!
Tried several GitHub issues and nothing!
With my clean Laravel 5.3 installation, I can run composer install to install the dependent packages.
Now, I've an internal package with its own composer.json, like below:
{
"name": "bar/foo",
"description": "A package for handling foo",
"licence": "MIT",
"authors": [
{
"name": "A. Foo",
"email": "a#foo.bar"
}],
"minimum-stability": "dev",
"require": {},
"autoload": {
"psr-4": {
"Foo\\Bar\\": "packages/foo/Bar/src"
}
}
}
So I prefer to autoload from the package itself, instead of autoloading from the main composer.json.
My questions:
Running composer dumpa from packages/foo/Bar doesn't take effect for autoloading. After Generating autoload files, Laravel doesn't know namespace Foo\Bar
Is there a way to run composer dumpa for all recursive composer.jsons?
You need to add the following section to your global composer.json
"repositories": [
{
"type": "path",
"url": "packages/*/*"
}
]
You also need to add the packages to the require object in composer.json
I just put up a package on packagist and I tried to run a composer update and am getting the error:
Unknown downloader type: h. Available types: git, svn, hg, perforce, zip, rar, tar, gzip, phar, file.
In the main project file I have this:
"require": {
//.......
"cyphix333/sbb-code-parser": "dev-master"
},
The composer.json file for cyphix333/sbb-code-parser is:
{
"name": "cyphix333/sbb-code-parser",
"description": "SBBCodeParser is a simple BBCode parser",
"keywords": [
"SBBCodeParser"
],
"homepage": "https://github.com/samclarke/SBBCodeParser",
"canonical": "https://github.com/cyphix333/SBBCodeParser",
"source": "https://github.com/cyphix333/SBBCodeParser/tree/master",
"autoload": {
"classmap": ["SBBCodeParser.php","classes/"]
},
"authors": [
{
"name": "Sam Clarke"
}
],
"require": {
"php": ">=5.3"
}
}
I am not sure what I am doing wrong here?
If you just started getting this error, try composer clear-cache and/or delete ~/.composer and vendor.
The specific error I was getting was:
[InvalidArgumentException]
Unknown downloader type: . Available types: git, svn, fossil, hg, perforce, zip, rar, tar, gzip, xz, phar,
file, path.
I just deleted everything and then tried again; works now.
I'm using
Composer version 1.2.0 2016-07-19 01:28:52
I've solved this issue deleting the vendor directory.
rm -Rf vendor
And then running:
composer update
Changes to your composer.json: dropped canonical and source; added type library.
Give this one a try:
{
"name": "cyphix333/sbb-code-parser",
"description": "SBBCodeParser is a simple BBCode parser",
"homepage": "https://github.com/samclarke/SBBCodeParser",
"keywords": ["SBBCodeParser"],
"type": "library",
"authors": [
{
"name": "Sam Clarke"
}
],
"require": {
"php": ">=5.3"
},
"autoload": {
"classmap": ["SBBCodeParser.php", "classes/"]
}
}
I did resolve this error after updating the composer version.
The installation did not work with composer v2.
Passing to the v1 version works.
composer self-update --1
I encountered this issue too, we had a human error in our composer.json. The dist part of one of our custom repositories was entered with a faulty downloader type (as stated in the error message).
{
"type": "package",
"package": {
"name": "campaignmonitor/createsend-php",
"type": "drupal-library",
"version": "dev-master",
"dist": {
"url": "https://github.com/campaignmonitor/createsend-php.git",
"type": "drupal-library"
},
"source": {
"url": "https://github.com/campaignmonitor/createsend-php.git",
"type": "git",
"reference": "master"
}
}
}
Note that the dist's type is entered as drupal-library, that is the package type, not the downloader type. We corrected this by using the following for dist:
"dist": {
"url": "https://github.com/campaignmonitor/createsend-php/archive/master.zip",
"type": "zip"
},
As we developed this project we had no problems when running composer install locally. We encountered this error when making the project production ready, using --prefer-dist. Obviously, it will only then use dist over source and then encounter this error.
Disclaimer: This case is somewhat different then the original question, though it's highly relatable and this question came up on top when trying to search for the answer. I hope this is okay.
For a project I'm working on I would like to create a 'Core' package containing multiple smaller packages, like laravel does with it's framework.
The folder structure would be something like this,
Package1: gybrus/core/src/Gybrus/Package1
Package2: gybrus/core/src/Gybrus/Package1
After doing some research I've noticed this could be achieved with composer if I'm not mistaken but this is also where it breaks for me.
Currently I have multiple composer.json files, but after running the 'php artisan dump-autoload' command the classes aren't added to the autoload files.
Therefore I'm wondering if the Laravel framework adds some extra magic to make this happen.
Thanks in advance!
This is my current setup, I've changed the package names for the sake of not advertising something ;)
The first composer file is in the 'core' folder next to the 'src' folder.
{
"name": "gybrus/core",
"description": "The Core",
"keywords": ["core"],
"authors": [
{
"name": "Kevin Dierkx",
"email": "email#email.com"
}
],
"require": {
"php": ">=5.3.0",
"laravel/framework": "4.0.x"
},
"replace": {
"gybrus/package1": "self.version"
},
"require-dev": {
"mockery/mockery": "dev-master",
"phpunit/phpunit": "3.7.*"
},
"autoload": {
"psr-0": {
"Gybrus": "src/"
}
},
"minimum-stability": "dev"
}
The second composer file is in the package1 folder:
{
"name": "gybrus/package1",
"authors": [
{
"name": "Gybrus",
"email": "email#email.com"
}
],
"require": {
"php": ">=5.3.0",
"illuminate/support": "4.0.x"
},
"autoload": {
"psr-0": {"Gybrus\\Package1": ""}
},
"target-dir": "Gybrus/Package1",
"minimum-stability": "dev"
}
Found the cause of my problem!
The first script tells composer that it should autoload the namespace 'Gybrus' starting in the 'src' folder, after some testing this works as intended.
Where the above setup breaks is the following line:
return Finder::create()->files()->in($workbench)->name('composer.json')->depth('< 3');
This tells the Finder to stop looking for composer.json files that are deeper than 2 folders.
Nothing weird so far.
Where is goes wrong is here, I symlinked the workbench packages into the workbench folder.
This causes the weird problem that the composer.json files are actually deeper than they should be, which in result stop the loading of the composer.json files and breaking the autoloading for these packages.
A quick fix would be to either don't symlink or run composer install from inside the package.