I'm trying to install the Coinbase PHP API but it requires Composer:
https://github.com/coinbase/coinbase-php
I'm looking for a universal PHP solution (perhaps a function) to let me install composer packages directly onto my server, without having to use Composer.
I think the developers of Composer believe they are helping people, but actually there are thousands of beginner developers that are being locked out of learning web development by the 'Composer barrier'.
It would really help if there was a flexible solution or some approach where we could install without Composer? How can I do this?
Please don't respond with some sarcastic comment. There are people that don't want to use Composer and I don't see why we should be herded into a specific third-party software in order to do web development.
You can try https://php-download.com/ which can help you download all dependency most of the time along with vendor folder. It promises composer not required.
Tried it myself. It finds and creates all required folders and zips it for download. Works perfectly !!
The composer.json file lists the dependencies. In your example:
"require": {
"php": ">=5.5.0",
"guzzlehttp/guzzle": "^6.0",
"psr/http-message": "^1.0",
"psr/log": "^1.0"
},
You must then find the corresponding packages in the packagist site. Repeat the same process for each dependency: find additional dependencies in their corresponding composer.json files and search again.
When you finally have a complete list of the required packages, you only need to install them all one by one. For the most part, it's just a matter of dropping the files somewhere in your project directory. But you must also ensure that PHP can find the needed classes. Since you aren't using Composer's auto-loader, you need to add them to your own custom autoloader. You can figure out the information from the respective composer.json files, e.g.:
"autoload": {
"psr-4": { "Coinbase\\Wallet\\": "src/" }
},
If you don't use a class auto-loader you'll need to figure out the individual require_once statements. You'll probably need a lot of trial and error because most library authors won't care documenting that.
Also, and just in case there's confusion about this:
Composer has an official GUI installer for Windows and a copy and paste command-line installation procedure for all platforms.
Composer can be run locally and its output just uploaded elsewhere. You don't need SSH in your shared hosting.
The command needed to install a library can be copied and pasted from the package web site—even if the package maintainer didn't care to document it, packagist.org generates it by default.
Composer is not perfect and it doesn't suit all use cases but, when it comes to installing a library that relies on it, it's undoubtedly the best alternative and it's a fairly decent one.
I've checked other answers that came after mine. They mostly fall in two categories:
Install a library and write a custom download script with it
Use an online web based interface for Composer
Unless I'm missing something, none of them address the complaints expressed by the OP:
Learning curve
Use of third-party software
Possibility to develop right on the server (using SSH, I presume)
Potentially deep dependency tree
I'm using shared hosting for a website and can't execute commands there. Aside from running composer via php script request that I request via browser, I usually use this workflow:
Make sure you have php installed locally.
Make directory on desktop.
download composer.phar from https://getcomposer.org/download/ (under header *Manual Download) and place it in the directory.
make a file composer.json paste in it the following contents
{
"require": {
"coinbase/coinbase": "~2.0"
}
}
Browse to the directory with the shell of your choice(bash, git-bash, cmd, windows bash)
type php composer.phar update
Upload the vendor directory to your webserver via ftp or whatever mechanic you use.
include in your php project where you load your libraries(modify path to where you uploaded the vendor dir so it will include that autoload file)
require_once('vendor/autoload.php');
This way you get the benefit of dependency management and you don't have to include manually all the gazillion of files and download all the dependencies manually, and updating them is just as easy as typing php composer.phar update and then replacing the vendor dir on your server with the new one.
An alternative solution that worked for me (since php-download was down) can be done by making your own little local composer downloader.
Download and install XAMPP locally: https://www.apachefriends.org/index.html
Download and install composer locally: https://getcomposer.org/download/
Open commandprompt, navigate to say c:\temp and and simply type the composer dependancy, for example: composer require league/oauth2-client
Copy the files from your c:\temp folder to your web host using an FTP program
Add this to the top of your php: require("vendor/autoload.php");
This is not the ultimate solution but for me it was a big help for most of the cases:
https://github.com/Wilkins/composer-file-loader
Allow you to load composer.json file just as composer would do it.
This allow you to load composer.json file without composer (so
theorically PHP 5.2 is enough)
I know the question is old but I hope it will help someone.
I had to do this for an FTP server I didn't have SSH access to. The site listed in here worked, then I realized you can just do a composer install on your own server (using your target's PHP version), then copy all the files over.
Analizing the problem
The problem in installing the dependencies without Composer is the autoloading system.
Composer use a homemade autoloader based on an array map, this is a de-facto standard.
But this autoloading system, "fortunally" in this case, is not PSR-4 compliant.
PSR-4 is the de-iure standard for autoload a class in PHP, so you can't escape from autoloading. You must use one of them.
Solution Proposal
In this case, this brilliant PSR-4 autoloader is capable to be manually configured to autoload a VendorClass in a VendorNamespace anywhere in your code, as long as you require the custom autoload.php file early in your source code.
Real life example
Let's look at this example:
I have a legacy project who can't and won't use Composer never and never even if God allow this with a miracle. This project can be speed up in development with this fantastic package for command line scripts.
This is my project directory structure:
- src
- tests
- vendor (not the Composer's one)
This package has this directory structure:
- examples
- src
- Commando
- tests
The only thing I need is the src folder. Placing this folder in my vendor folder would be fine. So my custom autoloader would be like this:
// Constants
$base_path = "path\to\my\project";
$autoloader_class = '\vendor\MarcoConsiglio-Wichee\PSR-4-Autoloading\Psr4AutoloaderClass.php';
define("BASE_PATH", str_replace("\\", DIRECTORY_SEPARATOR, $base_path));
// Autoloader
require_once BASE_PATH.'\vendor\MarcoConsiglio-Wichee\PSR-4-Autoloading\Psr4AutoloaderClass.php';
// Init the autoloader.
$package = [
"nategood\commando" => [
"namespace" => "Commando",
"path" => str_replace("\\", DIRECTORY_SEPARATOR, '\vendor\nategood\commando\src\Commando')
],
"kevinlebrun\colors.php" => [
"namespace" => "Colors",
"path" => str_replace("\\", DIRECTORY_SEPARATOR, '\vendor\kevinlebrun\colors.php\src\Colors')
]
];
// Register namespaces.
$loader = new \PSR4\Psr4AutoloaderClass;
$loader->register();
// Namespace // Path to source
$loader->addNamespace($package["nategood\commando"]["namespace"], BASE_PATH.$package["nategood\commando"]["path"]);
$loader->addNamespace($package["nategood\commando"]["namespace"], BASE_PATH.$package["nategood\commando"]["path"]."\Util");
$loader->addNamespace($package["kevinlebrun\colors.php"]["namespace"], BASE_PATH.$package["kevinlebrun\colors.php"]["path"]);
Now I can use the command package anywhere in my project!
Pros & Cons
This solution allow you to:
Easely and manually build your own custom autoloader (you only need to specify the VendorNamespace and the folder(s) where search for VendorClasses in the VendorNamespace.
Freely organize your composer dependency anywhere in your project folder (and why not, outside it)
Import a composer package as is in your project (either downloading locally with Composer or cloning the package repository) or a relevant part of it (i.e removing composer.json file or files that require the composer autoloader).
Cons:
Manually build your custom autoloader means to work on every required dependency of your project (i hope not a lot).
Mistakes in package source paths can be tedious and frustrating.
Works only with PSR-4 compliant file names (i.e. can't use a A.class.php file name)
Related
I'm trying to install the Coinbase PHP API but it requires Composer:
https://github.com/coinbase/coinbase-php
I'm looking for a universal PHP solution (perhaps a function) to let me install composer packages directly onto my server, without having to use Composer.
I think the developers of Composer believe they are helping people, but actually there are thousands of beginner developers that are being locked out of learning web development by the 'Composer barrier'.
It would really help if there was a flexible solution or some approach where we could install without Composer? How can I do this?
Please don't respond with some sarcastic comment. There are people that don't want to use Composer and I don't see why we should be herded into a specific third-party software in order to do web development.
You can try https://php-download.com/ which can help you download all dependency most of the time along with vendor folder. It promises composer not required.
Tried it myself. It finds and creates all required folders and zips it for download. Works perfectly !!
The composer.json file lists the dependencies. In your example:
"require": {
"php": ">=5.5.0",
"guzzlehttp/guzzle": "^6.0",
"psr/http-message": "^1.0",
"psr/log": "^1.0"
},
You must then find the corresponding packages in the packagist site. Repeat the same process for each dependency: find additional dependencies in their corresponding composer.json files and search again.
When you finally have a complete list of the required packages, you only need to install them all one by one. For the most part, it's just a matter of dropping the files somewhere in your project directory. But you must also ensure that PHP can find the needed classes. Since you aren't using Composer's auto-loader, you need to add them to your own custom autoloader. You can figure out the information from the respective composer.json files, e.g.:
"autoload": {
"psr-4": { "Coinbase\\Wallet\\": "src/" }
},
If you don't use a class auto-loader you'll need to figure out the individual require_once statements. You'll probably need a lot of trial and error because most library authors won't care documenting that.
Also, and just in case there's confusion about this:
Composer has an official GUI installer for Windows and a copy and paste command-line installation procedure for all platforms.
Composer can be run locally and its output just uploaded elsewhere. You don't need SSH in your shared hosting.
The command needed to install a library can be copied and pasted from the package web site—even if the package maintainer didn't care to document it, packagist.org generates it by default.
Composer is not perfect and it doesn't suit all use cases but, when it comes to installing a library that relies on it, it's undoubtedly the best alternative and it's a fairly decent one.
I've checked other answers that came after mine. They mostly fall in two categories:
Install a library and write a custom download script with it
Use an online web based interface for Composer
Unless I'm missing something, none of them address the complaints expressed by the OP:
Learning curve
Use of third-party software
Possibility to develop right on the server (using SSH, I presume)
Potentially deep dependency tree
I'm using shared hosting for a website and can't execute commands there. Aside from running composer via php script request that I request via browser, I usually use this workflow:
Make sure you have php installed locally.
Make directory on desktop.
download composer.phar from https://getcomposer.org/download/ (under header *Manual Download) and place it in the directory.
make a file composer.json paste in it the following contents
{
"require": {
"coinbase/coinbase": "~2.0"
}
}
Browse to the directory with the shell of your choice(bash, git-bash, cmd, windows bash)
type php composer.phar update
Upload the vendor directory to your webserver via ftp or whatever mechanic you use.
include in your php project where you load your libraries(modify path to where you uploaded the vendor dir so it will include that autoload file)
require_once('vendor/autoload.php');
This way you get the benefit of dependency management and you don't have to include manually all the gazillion of files and download all the dependencies manually, and updating them is just as easy as typing php composer.phar update and then replacing the vendor dir on your server with the new one.
An alternative solution that worked for me (since php-download was down) can be done by making your own little local composer downloader.
Download and install XAMPP locally: https://www.apachefriends.org/index.html
Download and install composer locally: https://getcomposer.org/download/
Open commandprompt, navigate to say c:\temp and and simply type the composer dependancy, for example: composer require league/oauth2-client
Copy the files from your c:\temp folder to your web host using an FTP program
Add this to the top of your php: require("vendor/autoload.php");
This is not the ultimate solution but for me it was a big help for most of the cases:
https://github.com/Wilkins/composer-file-loader
Allow you to load composer.json file just as composer would do it.
This allow you to load composer.json file without composer (so
theorically PHP 5.2 is enough)
I know the question is old but I hope it will help someone.
I had to do this for an FTP server I didn't have SSH access to. The site listed in here worked, then I realized you can just do a composer install on your own server (using your target's PHP version), then copy all the files over.
Analizing the problem
The problem in installing the dependencies without Composer is the autoloading system.
Composer use a homemade autoloader based on an array map, this is a de-facto standard.
But this autoloading system, "fortunally" in this case, is not PSR-4 compliant.
PSR-4 is the de-iure standard for autoload a class in PHP, so you can't escape from autoloading. You must use one of them.
Solution Proposal
In this case, this brilliant PSR-4 autoloader is capable to be manually configured to autoload a VendorClass in a VendorNamespace anywhere in your code, as long as you require the custom autoload.php file early in your source code.
Real life example
Let's look at this example:
I have a legacy project who can't and won't use Composer never and never even if God allow this with a miracle. This project can be speed up in development with this fantastic package for command line scripts.
This is my project directory structure:
- src
- tests
- vendor (not the Composer's one)
This package has this directory structure:
- examples
- src
- Commando
- tests
The only thing I need is the src folder. Placing this folder in my vendor folder would be fine. So my custom autoloader would be like this:
// Constants
$base_path = "path\to\my\project";
$autoloader_class = '\vendor\MarcoConsiglio-Wichee\PSR-4-Autoloading\Psr4AutoloaderClass.php';
define("BASE_PATH", str_replace("\\", DIRECTORY_SEPARATOR, $base_path));
// Autoloader
require_once BASE_PATH.'\vendor\MarcoConsiglio-Wichee\PSR-4-Autoloading\Psr4AutoloaderClass.php';
// Init the autoloader.
$package = [
"nategood\commando" => [
"namespace" => "Commando",
"path" => str_replace("\\", DIRECTORY_SEPARATOR, '\vendor\nategood\commando\src\Commando')
],
"kevinlebrun\colors.php" => [
"namespace" => "Colors",
"path" => str_replace("\\", DIRECTORY_SEPARATOR, '\vendor\kevinlebrun\colors.php\src\Colors')
]
];
// Register namespaces.
$loader = new \PSR4\Psr4AutoloaderClass;
$loader->register();
// Namespace // Path to source
$loader->addNamespace($package["nategood\commando"]["namespace"], BASE_PATH.$package["nategood\commando"]["path"]);
$loader->addNamespace($package["nategood\commando"]["namespace"], BASE_PATH.$package["nategood\commando"]["path"]."\Util");
$loader->addNamespace($package["kevinlebrun\colors.php"]["namespace"], BASE_PATH.$package["kevinlebrun\colors.php"]["path"]);
Now I can use the command package anywhere in my project!
Pros & Cons
This solution allow you to:
Easely and manually build your own custom autoloader (you only need to specify the VendorNamespace and the folder(s) where search for VendorClasses in the VendorNamespace.
Freely organize your composer dependency anywhere in your project folder (and why not, outside it)
Import a composer package as is in your project (either downloading locally with Composer or cloning the package repository) or a relevant part of it (i.e removing composer.json file or files that require the composer autoloader).
Cons:
Manually build your custom autoloader means to work on every required dependency of your project (i hope not a lot).
Mistakes in package source paths can be tedious and frustrating.
Works only with PSR-4 compliant file names (i.e. can't use a A.class.php file name)
I am trying to install "Krumo"
It says there are two ways to install, I tried the first one (download the PHP file and include it into my project) and it worked fine.
Now I am trying the second way (using composer).
Bunch of questions emerge at the second I see it.
Where to run this command?
Is it equivalent to downloading the "class.krumo.php" file and other skin files to the current folder?
Do I still need to include the file in my PHP?
Or, maybe through running this command, krumo becomes a built-in function of PHP on my machine (so I can use it "out-of-box" on any PHP file)?
I managed to find that this install command doesn't actually work (probably outdated), and found out that I had to run composer require kktsvetkov/krumo. I did so and got this:
It seems to me it is finally installed. Under the folder there are only two files added "composer.lock" and "composer.json", the class.krumo.php file is nowhere to be found, and of course calling krumo() in a test PHP file throws the error call to undefined function krumo.
I need a big picture of how composer packages work.
First, you need to understand what composer is. It's a "dependency manager". So it manages your application dependencies, basically the libraries your application needs to work.
It does so recursively. So if your application requires NiceDependency to work, and NiceDependency in turn requires AnotherNicePackage, it installs both. It deals also with conflict resolution (when one of your dependencies requires something that's not compatible with something that another of your dependencies require).
The file where your dependencies are declared is composer.json.
So when you run composer require [some-vendor/some-package], a few things happen behind the curtain. Simplifying things a lot:
If your composer.json file doesn't exist, it will create it.
It will try to find your dependency in the central repository (packagist.org)
If found, it will download the package and store it in the vendor directory.
It will update your composer.json it to add your dependency to the require key.
In the process, it will resolve all the nested dependencies and do the same for those.
When it's done, it will also create a composer.lock file.
This "lock" file stores a frozen snapshot of all the references to all the packages that were actually installed. This is necessary because when you declare your dependencies you can define a range of versions (e.g "anything greater or equal than version 2.2; but lower than version 2.3"). Your composer.lock would store the specific version that's actuall installed (e.g. "version 2.2.4").
Later, if someone got your project files and executed composer install, the lock file would be read so they installed exactly the same files as you did.
(require adds a dependency to your project's composer.json file; install reads your composer.json and composer.lock files and sets up a project from there; there is also a update command that would read only composer.json, download the latest available packages respecting to the version restrictions in each dependency, and update `composer.lock accordingly)
Additionally, composer helps with autoloading, to make the process of actually using the installed libraries easier and faster for developers.
Autoloading is very convenient. Not only you no longer have to add a require someclass.php; statement for each class you want to use, but you also gain the advantage of not having to read these files until they are actually needed.
So not only it simplifies using these new classes, it helps making your application perform better.
For this, inside the vendor directory a file named autoload.php is created. Typically, you need to require this file as the first thing you do on your application entry point.
For example, assuming you have a structure like this:
- project root/
--- composer.json
--- composer.lock
--- vendor/
--- public/
----- index.php
Your index.php file should read:
// public/index.php
<?php
require('../vendor/autoload.php');
This would allow you to use any installed library normally. In the case of the tool you want to install:
// public/index.php
<?php
require('../vendor/autoload.php');
$a = [
'foo' => 'bar',
'baz' => [1, 2, 3],
'xxx' = false
];
krumo($a);
As a side note, that library seems to be quite old. I'd try to get something a bit newer. I'd recommend Symfony's VarDump component.
And no, it is not a particularly friendly "newbie" tool. It helps dealing with a lot of things, but it's mostly aimed to slightly more advanced users, since it helps solving issues that aren't so significant in starter/very simple projects.
I am sorry if this has been asked before but after searching for a while I couldn't really find answers to my dilemma.
I am part of team that is working on a PHP project and we use github for our version control. We would like to implement a PSR-4 autoloader and every single guide uses Composer so we would as well. Now, while searching I learned that the vendor folder should not be included into github, but only the composer.json and that every developer needs to install composer onto their own computer.
Does that require the autoloader to be created again on every developers computer.
And finally, when the project is done, we would like to upload it onto our website, but the only way we can do that is through FTP.
Which files should be uploaded to the live website and what would happen to th autoloader?
You need to commit the composer.lock file as well. That's super-important - it means that whenever someone else checks out the code they get the same set of dependencies (including their exact versions) installed to their /vendor directory.
That's why you don't need the /vendor directory to be committed - the lock file takes care of ensuring the dependencies are fixed.
The composer.json defines numerous potential versions of your dependencies that meet your requirements. Running composer update essentially checks to see if a more recent version is available that meets those requirements. That's the difference between install and update - install goes off the lock file and knows exactly what to look for - update goes off the json file and could return different results at different points in time.
In your composer.json you can define the autoloader by telling it where your root namespace lives.
"autoload": {
"psr-4": {
"RootNamespace\\": "library/src"
}
},
When your colleagues have run composer install it will create the autoloader for them in a consistent path.
You have options for deployment:
You can either upload the composer.lock file and run a composer install on production, or do it ahead of time and upload your vendor directory as part of the build.
I do the latter as I would prefer if there was an issue at this point to know about it before any files are changed on the production server. The alternative could leave a botched upgrade on production with missing dependencies. Safer to install those dependencies first and transfer everything in one go.
As an aside, I also like to install a fresh release to a separate folder on production named after the git commit and then symlink it as part of the deployment step. This ensures you don't have a half-updated application whilst you wait for the rest of the files to be uploaded. This approach would also eliminate the issue mentioned before, meaning you could do your composer install from production.
I have tried to install both ZendPdf and TCPDF into ZF2 using Composer without success.
Software is installed and autoload files are written but nothing works, ZF can't see them.
Which files do I need to edit in order to manually install TCPDF library so that it autoloads?
I have found lots of similar questions in StackOverflow but not many working answers that don't involve Composer.
In fact, you don't install them without Composer. I think it is easier to make Composer work than to install them by hand.
In theory you could install them by hand. Just download both components in a version you like. Then look into their composer.json file if you need to download some more software these libs need. Download them as well. Have a look in their composer.json to download even more software.
After these downloads, unpack the packages, create a whole directory tree of files, and create the autoloading manually. Which means again you have to look at all the composer.json files for the definition of autoloading. You are lucky if you find PSR-0 or PSR-4 autoloading, and you have to manually scan EVERY file in the directory if you have classmap autoloading.
You then simply push all these definitions into your own autoloader and hope it works.
Done. That was easy... NOT!
I can help you get Composer to work, but I cannot help you NOT use Composer. Ask a new question describing your problem using Composer.
Please follow these instruction below to install Zend without composer. But I recommend to use composer for future consistency
Download latest stable copy of ZF2 from http://framework.zend.com/downloads/latest and unpack, we call it "ZF2"
Download latest stable copy of ZF2 skeleton app from https://github.com/zendframework/ZendSkeletonApplication/ and unpack, we call it ZF2Skeleton
Create folder like /vendor/ZF2
Now copy ZF2/* into /vendor/ZF2
Now you need to fix ZF2_PATH or $zf2Path variable at “/init_autoloader.php” file of root to point our “/vendor/ZF2” folder. Find "$zf2Path = false;" line into "/init_autoloader.php" file and replace it by "$zf2Path = 'vendor/ZF2/library';"
That's all. You may visit https://shkhan.wordpress.com/2014/04/26/install-zend-framework-2-into-windows-iis/ for more information about installing ZF2 without composer.
I'm looking to develop a package in PHP, but I don't want it immediately available on GitHub or somewhere. It's easy enough to include a Packagist file in my composer.json, but how do I add a local package into my composer.json? Also, should I be building the package in /vendor/foo/bar (relative to the root composer.json), or should I put it somewhere else?
Edit: I guess my question is about how everyone else writes their packages. Does every new package get added to Packagist, and then when you want to test your changes, you commit to GitHub (or wherever), and then pull that back down via Composer? That seems really inefficient.
Instead of creating a new repository, you can tell composer to use any local path:
https://getcomposer.org/doc/05-repositories.md#path
For instance, lets say that you have your PHP projects under ~/devel/projects
You may have your main project in ~/devel/projects/main_project, and your "local package" in ~/devel/projects/local_package
Define your composer configuration for the local package. In ~/devel/projects/local_package/composer.json.
{
"name": "your_vendor_id/your_local_package",
...
}
Then, you can edit ~/devel/projects/main_project/composer.json and link to your local package via path repo:
"repositories": [
{
"type": "path",
"url": "../local_package",
"options": {
"symlink": true
}
}
],
"require": {
"your_vendor_id/your_local_package": "dev-master",
...
}
More info on this link (not written by me but has a good explanation on this subject):
https://carlosbuenosvinos.com/working-at-the-same-time-in-a-project-and-its-dependencies-composer-and-path-type-repository/
As this question has many different components/standards to be explained, I'll try to explain as much as possible here and you can PM me or just Google it for more specific questions as they come up.
To answer your first question, "How do I add a local package into my composer.json?":
If by "add local package" you mean autoload your class/package, you can do that by either using PSR-4 or PSR-0 or Classmap options in composer.
Read more
PSR [petermoulding.com] (via archive.org)
PSR-4 autoloading support in Composer [seld.be]
Battle of the Autoloaders: PSR-0 vs. PSR-4 [Sitepoint]
Why use a PSR-0 or PSR-4 autoload in composer if classmap is actually faster? [SO]
You can Google it if you need more info on PSR-0, PSR-4 and Classmap.
Example
"autoload": {
"psr-4": { "Core\\": "src/Core" } ## "standard": { "namespace" : "path/to/dir"}
}
Or (edit)
If you actually want to add a local package:
Create a composer.json for the local package, like:
{
"name": "localPackage/core",
"version": "dev-master"
}
You can also specify other properties and/or dependencies as required.
Zip the package, with the composer.json file as the root file in the archive.zip, and place it where desired.
In the other project/package where you want to include the local package, add the local package name to the required parameter, like
"localPackage/core": "dev-master"
Add the following under the repositories parameter:
"repositories" : [
{
"type": "artifact",
"url": "path/to/localPackage.zip"
}
]
Now if you have the local package on git, then there would be no need to archive the package (basically omit step 2) and you just need to replace the URL in the above example to the path/to/localPackage/.git.
(End of edit)
Now to answer the larger question: "How do I develop and include a Composer package?":
Decide the directory structure. Commonly it is as follows:
/PackageRoot
/src/PackageCore
composer.json ## this is your library’s composer.json
LICENSE
and set up your composer.json.
An example of one of mine composer.json files can be found at http://pastebin.com/tyHT01Xg.
Upload it to Github and tag the version. Use Semantic versioning (make sure you exclude/ignore the vendor directory when uploading to Github).
Register the package with Packagist (after logging in).
If you have tagged your commit as v1.0.0 (or similar), then this will show up in your Packagist dashboard for that package.
Now, if everything is done right, you should be able to use your library as a dependency in other projects by adding it to the composer.json of that project.
Here's a recap of the solutions plus my own
publish on packagist
Since you don't want to publish yet, you're in development, this is a poor option.
upload github
You may not want to publish your library source on github, not want to pay for a private repo, or be able to use a cloud external service (due to political or network policies).
zip your library
You can use the composer repository path in your example implementation to point to a local zip file as a release. You'll have to re-zip every time you make a change to the lib, even with a batch file to do it, this is icky.
upload to local git/svn repo on your machine
This is getting close, but you'll need to do a composer update each time you change your library and want to test your example implementation. This mimics productions but is cumbersome. Personally I recommend this solution, even though it's not brainless.
Autoload the library directly (sortof does what you want)
This is a hack, but you could just add:
{
"require": {
},
"autoload": {
"psr-4": {
"yourlibnamespace": "D:\\Code\\yourlib\\src\\"
}
}
}
Please note that you will need to copy+paste the 'require' section from your lib to your sample implementation. Change 'yourlibnamespace' to your library namespace and "D:\Code\yourlib\src\" to your local path to your library source.
This way any changes are immediately reflected. However you will not be using or testing your library's composer.json file at all. If you change a requirement in your library .json it will not flow through at all. So it has some big disadvantages, but does do what you want, which is to test your library implementation immediately with the least commands possible.
add your example implementation directly in your library tree (recommended)
Usually you just have src\ and tests\, but many have examples\ where you can find sample implementations. As you develop your application you can contribute to these example implementations. You can do this in a local git/svn repo, and you have the advantage of getting the lib's 'require', plus the namespace automatically. It is the best of all worlds. I recommend this method.
It seems most answers on this thread are not "in the know". I am new to Composer myself, but these answers are misleading. The question could simply be stated as: "How can I develop a composer package".
Yes, you could use a custom repository or upload an unfinished package and update it after every change. That neither is the correct solution or the answer to the question.
It doesn't help that Composer's official documentation doesn't state this upfront, but you can see the heading on the Libraries documentation page:
Every project is a package
This is very important to understand
composer.json:
The previously mentioned page goes on to state:
In order to make that package installable you need to give it a name. You do this by adding the name property in composer.json
{
"name": "acme/hello-world",
"require": {
"monolog/monolog": "1.0.*"
}
}
In this example so far, we have a required package, and now a name. Note the vendor/name format.
So now to autoloading our own files, which is documented on the Basic usage page.
{
"autoload": {
"psr-4": {"Acme\\": "src/"}
}
}
This will autoload the namespaced class files under the src/Acme directory.
On to the fun.
Install/Update
Install or update the package with the command:
composer update
or
php composer.phar update
This will download the required packages and create the autoload.php file
Our project structure should look simular to the following:
src
Acme
Foo.php
vendor
monolog
...
composer.json
Including
Now to test.
Include autoload.php
require_once 'path/to/project/vendor/autoload.php';
Assuming Foo.php looks like the following:
<?php
namespace Acme;
class Foo {
public static function bar(){
return 'baz';
}
}
?>
we can then call this from our script:
echo Acme\Foo::bar(); // baz
Please correct any misleading information I may have stated. This is what seems the be the solution to a popular question.
Maybe adding a custom repository will help you?
https://github.com/composer/composer/blob/master/doc/05-repositories.md
You can set up a local git repository with your library very easily.
Of course if you use composer to manage dependencies you should build your library someplace else and download it to vendor/ via composer coz this is the whole point i guess.
That's my flow of creating and developing a new Composer package locally:
Create a new repository for the package on GitHub (just an example)
Add it to Composer's database (packagist.org)
Add it to your main project via composer require. This is where you start wondering how can you apply hotfixes quickly
Clone it on your local machine somewhere, this is where you develop it
Now to test your local version, add a php require() statement where you load the class files in question. The autoloader won't load the one downloaded via composer but your local one.
When you're done hotfixing, delete/comment out the the require statement to revert back to using the composer version of the package.
Commit all changes, tag the commit and push to GitHub; hook fires to update Composer. Run composer update on your main project, the package gets updated to your local version.
This is still not ideal, but it gets the work done for small to medium packages.
To make developing more efficient I simply symlink the development repository into a directory that has already installed it.
For example, if /Code/project-1 requires a package that's in /Code/package-1, I:
Commit package-1 to GitHub (can even be private).
I then tell project-1 to install it using a custom repository (see other answers for the link to repository configuration).
Once it gets installed, I symlink /Code/project-1/vendor/developer/package-1 to /Code/package-1.
That way, when I make changes in /Code/package-1, it's immediately reflected in /Code/project-1.
My workflow does not completely answer the OP's question but may be helpful for others.
I like to develop a reusable package / lib in a real world project and I do not want to go through git / composer locally.
I also do not like to load the package differently locally compared to production (e.g. through a local require statement or local composer setting).
So what I do is simple: I add the package directly under the vendor directory, either directly or using a symlink.
drawbacks
When using composer update / install, your package may be overwritten. (so I tend to update or add dependencies one by one, during this time).
When not being careful, composer install on the production environment may install a different version. So keep pushing your package and version tags!!
Changing the package's dependencies and loading it in the parent project trough composer update, overwrites the package's folder