I've got a PHP project that uses Capistrano 3 to deploy to staging/testing/live and everything works fine.
Now we've encountered a bug in one of our dependencies that are included through PHPComposer, it's really an easy fix (change one line) which we do manually in the vendor directory on our development boxes, just until the bug is fixed through our pull request. But every time we deploy all dependencies are installed again on the deployment target server including the bugged dependency. After we manually ssh into the server and change that one line in the particular file the deploy is successful.
How would I go about automating this with capistrano? Are there proven ways of doing this?
I suspect the 'official' solution to this is to fork the repo with your fix in place, and then alias the new repo, setting your composer.json to use that in preference to the original while you wait for the fix to be merged upstream.
There are some details on the Composer site - require-inline-alias
The composer.json configuration to be able to do the inline-aliasing is:
"repositories": [
{
"type": "vcs",
"url": "https://github.com/you/monolog"
}
],
"require": {
"symfony/monolog-bundle": "2.0",
"monolog/monolog": "dev-bugfix as 1.0.x-dev"
}
That will fetch the dev-bugfix version of monolog/monolog from your GitHub and alias it to 1.0.x-dev.
Related
This question already has answers here:
Using PHP Composer to develop a local package and then copy it on deploy
(2 answers)
Closed 1 year ago.
I have two composer files to run composer in each environment
"repositories": [
{
"type": "vcs",
"url": "https://github.com/igorhaf/laravel-admin"
}
],
"require": {
"php": "^7.2.5|^8.0",
"fideloper/proxy": "^4.4",
"guzzlehttp/guzzle": "^7.4",
"laravel/framework": "^7.0",
"laravel/telescope": "^3.0",
"laravel/tinker": "^2.5",
"encore/laravel-admin": "dev-master"
},
I want running laravel-admin from a local folder in my project (packages) when I am using local environment, but with the same composer.json file
If I understand your use case clearly, you develop custom Laravel package and you don't want to always have to push it before you test it in local.
There's absolutely a use case for it. I personally use it. With this approach, your composer.json can stay the same both on local and server. No need to change anything.
You would need the package https://github.com/franzliedke/studio . The documentation is quite explanatory. You install it globally via composer. composer global require franzl/studio though can be installed per project but that's quite tedious because you may only need it locally.
At the root of your project run studio load path/to/your/local/vendor/directory/* (if you want all packages in directory) or studio load path/to/your/local/package (for a single package. You may add multiple packages). This will generate a studio.json file at the root.
Eg.
{
"version": 2,
"paths": [
"path/to/local/vendor/directory/*",
"path/to/local/package"
]
}
Anytime you run composer update, composer will first look in your studio.json file and symlink to local packages if available, else get it from the remote repository.
Note:
i. Make sure to add studio.json to .gitignore.
ii. Also remove the paths from studio.json as seen below and run composer update to generate new composer.lock file before you push your code to production/server. Else your code on server will be looking for packages from the symlink in local setup when you run composer install and give you errors.
{
"version": 2,
"paths": [
]
}
iii. After pushing to server, return the studio.json to initial state and continue to develop. No need to push to github/remote vcs before you see your changes. Changes are symlinked from local if available or gotten from remote.
iv. Run composer install on server.
v. Don't forget to push your package to remote else, you will not see the changes on server, though you see on local.
I've got a local PHP project (a website), and I want to use another project I've made (a tiny web framework) as a Composer package for the website project. I'm developing them in tandem, but want to keep them as separate projects; when I deploy the website, I want to use Composer to install the framework project as a package, just like I would with Guzzle or any other common Composer package.
The website project has the following composer.json:
{
"repositories": [
{
"type": "path",
"url": "/local/path/to/framework/package"
"options": {
"symlink": true
}
}
],
"require": {
"my/framework": "dev-master",
"guzzlehttp/guzzle": "6.3.3"
}
}
In /local/path/to/framework/package/composer.json I have:
{
"name": "my/framework",
"description": "A tiny framework.",
"autoload": {
"psr-4": {
"MyFramework\\": "src"
}
}
}
I run php composer.phar update and it sets up a symlink to the framework package in my website project. If I update code in the framework, it's immediately available to the website code. This is great.
However, later on I want to deploy the website project to my web server. For a clean deployment, I have a deploy script that exports an archive copy of the appropriate branch of the website git repo, and then runs php composer.phar install to make sure all the proper packages are installed. With the above config, the deploy script creates a symlink to the framework package, which is obviously no good when the deployment artifact is zipped up and scp'd out to the web server.
If I remove the symlink option above, then I have to run php composer.phar update every time I make any changes in the framework package, which is irritating since I'm developing the packages in tandem. But then on deploy, the package is copied in, rather than being symlinked in; this is good for deploy, except it always copies in the master branch (because I specified dev-master in composer.json).
Is there a way to set up Composer so that I can have the convenience of a local symlinked package for development, but to let the deployment script get a clean copy of the framework package, without having to change composer.json every time I want to deploy?
I also tried changing the repository type to vcs instead of path, but then Composer clones the framework package repository, and I really don't need a clone of the repo in my local vendor/ tree, either during development or deployment. I just want to be able to have a symlinked tree (which gets me instant updates) during development, and have a clean package installed for deplotment.
I may have to resign myself to developing the framework project "properly," that is, as a Composer package that I tag with actual release version numbers, and then update my website project to use a specific version of when it comes time for a deployment. I still haven't figured out the easiest way to do that, though.
You can use Composer Studio plugin.
It uses a separate file for configuration and allows you to have symlinks in development and a regular Composer install for prod deploy, without touching composer.json.
With it, your website composer.json will look like a regular file:
{
"require": {
"my/framework": "dev-master",
"guzzlehttp/guzzle": "6.3.3"
}
}
And with studio.json in the root of the project, with the following content:
{
"version": 2,
"paths": [
"/local/path/to/framework/package"
]
}
you can tell the plugin where to locate my/framework. Studio will then symlink the packages from the provided paths.
To have a regular install, just remove or rename studio.json, remove the vendor folder and composer.lock file and run the install again when deploying.
I made a composer plugin to make it more easy to test packages.
It doesn't require a configuration file, changing your composer.json and doesn't change the upgrade behavior of composer update
https://github.com/SanderSander/composer-link
It works as simple as calling composer link ../path-to-package to link the local package into your project.
I have tried to publish a project with composer. The project resides at github, and are published through packagist.org.
But when I try to create my project with composer it fails with this error message:
"Could not find package madskullcreations/simplicity with stability
stable."
I use the following command:
composer create-project madskullcreations/simplicity
The composer.json contains this:
{
"name": "madskullcreations/simplicity",
"description": "Website made simple!",
"homepage": "https://madskullcreations.com",
"type": "project",
"license": "GPL-3.0-or-later",
"minimum-stability": "dev",
"require": {
"php": ">=5.6",
"cakephp/cakephp": "3.5.*"
}
}
My repository contains just one file for testing. What is wrong? I tried to remove the dependencies, the entire "require"-block, but no real change...
Beginner as I am, I don't even know where I would define the packages "stability", can't find anything at github or at packagist.
Please help me get this started!
Working solution:
I eventually got it working with the help from Flying, see his answer further down. Since I think it is a wee bit complicated to get composer up'n working, I try to put the steps I did to get it working here:
Create a repository at github.
Create a composer.json with your depencencies. Check it in.
Release it. There are a "Releases" link somewhere, use it and give the release a name.
Now, to skip the packagist.org step during your testing, follow these steps. It is not good style to publish a non-working solution (like I did) on packagist.org, and it's no fun at all to do all the steps necessary ten times over.
Create a local folder somewhere, and create a new composer.json file there.
Put something like this in it:
{
"require": {
"madskullcreations/simplicity":"dev-master#dev"
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/madskullcreations/simplicity"
}
]
}
Run the following command in your new folder:
composer create-project
It should now download and install your project.
And, read the error messages given by composer and make sure you understand them. They are useful. My headache was a missing PHP-extension (intl) and that I assumed it was using php version 7.1, while it actually listened to my requirement in the composer.json file, and used v5.6. (I have several php-versions installed in iis, but my fuzzy head did not consider that.)
Packages stability requirement is defined into minimum-stability setting of composer.json of your project, not a composer.json of the external package.
Your madskullcreations/simplicity package have no releases defined so the only branch that is available in it - is dev-master "release" (it can be seen at the right side of package page on Packagist). This "release" have "dev" stability level.
Because of above if you're requiring this package into your project without either setting minimum-stability: dev or without specifying stability requirement for a package as
"require": {
"madskullcreations/simplicity":"dev-master#dev"
}
(notice #dev into version requirement) it is correct behavior of Composer to complain about lack of compatible releases.
Also it is generally bad practice to publish your test packages into public registry like Packagist. Instead you should use direct repository specification into your composer.json as explained here. In your case it will be:
"repositories": [
{
"type": "vcs",
"url": "https://github.com/madskullcreations/simplicity"
}
]
After specifying direct repository reference - it will be safe to remove your test package from Packagist unless you're really want to share it with open source community.
I'm trying to load a library I have hosted on BitBucket using composer as explained both in the official documentation and here, but keep receiving the following error:
[Composer\Repository\InvalidRepositoryException]
No valid composer.json was found in any branch or tag of [repository URL], could not load a package from it.
Here is my project composer.json:
{
"name": "Project name",
"require": {
"my-vendor/my-package": "dev-master"
},
"repositories": [
{
"type": "vcs",
"url": [repository URL]
}
]
}
And here is the composer.json in my remote repository (that apparently can't be found):
{
"name": "my-vendor/my-package",
"version": "0.3",
"autoload": {
"psr-0": {
"NS_": "src"
}
}
}
I should mention that both composer.json files are in the root directory as they should be.
Some other things to note:
I've also tried the "non-composer package" approach, whereby I specify the package information in my project composer.json, and omit the composer.json from my remote repository, as outlined in the documentation. This successfully clones the master branch but then results in the following error:
[RuntimeException]
Failed to execute git checkout "master" && git reset --hard "master"
fatal: Not a git repository (or any of the parent directories): .git
However, the package is downloaded to /vendor as expected, so I'm not sure why it's trying to checkout master again.
This is not the way I wish to solve this problem (as I'd rather make use of a composer.json in the remote repository), but it might help identify an issue elsewhere.
Thanks for any help.
EDIT
I've managed to get it working by referencing a package.json over HTTP:
"repositories": [
{
"type": "composer",
"url": "http://localhost/packages.json"
}
]
The packages.json looks like:
{
"packages": {
"vendor/my-package": {
"dev-master": {
"name": "vendor/my-package",
"version": "dev-master",
"source": {
"url": [repository URL],
"type": "git",
"reference": "master"
}
}
}
}
}
Is this the only way to get this working? It seems a bit overkill to host my own packages.json file if I'm only going to be using one or two in-house packages.
Regardless, this is giving me the same Git error as I mentioned previously.
EDIT 2
Forcing an error (invalid SSH passphrase) gives this:
[RuntimeException]
Failed to execute git clone "[repository URL]" "C:\workspace\DFv3\vendor\vendor/my-package" && cd /D "C:\workspace\DFv3\vendor\vendor/my-package" && git remote add composer "[repository URL]" && git fetch composer
So I can clearly see what it's doing here. However, it seems after this command runs it cds into the .git directory and tries running:
git checkout "master" && git reset --hard "master"
Presumably to get rid of the composer instance it pulled. However, it's running this in the wrong directory and I can't figure out why..
I know this is a bit old, but for some that might encounter this issue, this is how it works for me.
Clear the composer cache.
composer clearcache
Rerun the satis build script.
You must not include a version specification in your library's composer.json if it is actually managed by a supported source control system. Currently you are saying that your master branch IS version 0.3 (which is a stable version), but you are trying to include "dev-master" (which is an unstable version). Composer might get confused if that software really is "dev-master" or "version 0.3".
If you actually are developing new releases for the 0.3.x series in your master branch, you should define a branch alias instead. Add this to your current development branch for versions 0.3.x:
"extra": {
"branch-alias": {
"dev-master": "0.3.x-dev"
}
}
If you want to move on to version 0.4 or 1.0, you'd branch at the "last" state of the 0.3 series with a branch named "0.3.x" and then update the composer.json in the master branch to point dev-master to a new alias (like "dev-master": "0.4.x-dev"). You could also name your old 0.3 branch anyway you like and then add an alias for THAT branch.
Doing this will enable you to require the latest development version of 0.3.x like this:
"require": {
"my-vendor/my-package": "0.3.*#dev"
}
This will pull the latest 0.3 version - which currently would be the latest commit in the master branch because of the defined alias.
The way you are currently set up forces you to explicitly include version 0.3, which is a moving target without making that fact explicitly known.
Giving an explicit version tag should only be done if there is no version control system available that is able to give Composer the version number, i.e. there are no tags available, or the tags do not comply with Composer's requirement for version numbers. Since you seem to be in control of that vcs, it probably is a good idea to make the tags conform to Composers standard instead of making it troublesome to release a new version.
After you fixed this, I do expect your installation to NOT require that package.json file anymore, because that file now repairs the trouble you created with that version declaration. You'd then also not need that composer reference anymore, but can revert back to mentioning the original repository like you did.
If you feel you are using too many private repositories which are all requiring more private repositories, and are sick of mentioning them all in a long list, you could think about using Satis to create such a list of found packages instead of manually creating them.
I had the same error, after deleting folders from vcs everything works fine
sudo rm -R ~/.composer/cache/vcs/*
On Windows (as #Serbu suggested):
Clearing the vcs, repo and files directories under
C:\Users\Me\AppData\Local\Composer\
I've managed to get it working by referencing a package.json over HTTP:
"repositories": [
{
"type": "composer",
"url": "http://localhost/packages.json"
}
]
so the packages.json file looks like:
{
"packages": {
"vendor/my-package": {
"dev-master": {
"name": "vendor/my-package",
"version": "dev-master",
"source": {
"url": [repository URL],
"type": "git",
"reference": "master"
}
}
}
}
}
Also, its seems an autorun registry entry I had for command prompt was interfering with composer running.
See: Requiring a private git Bitbucket repository fails to find valid composer.json.
While this might be considered necromancy, I stumbled across this question yesterday while having an issue just like this (although in my case I was running an Ubuntu Docker container and not Windows as the OP was) and thought I would leave my thoughts and resolution here should anyone else stumble across this.
The Ubuntu repo version of Composer is currently sitting at 1.6.x (at the time of writing, Composer is up to 1.9.1 I believe) and I was getting different errors depending on if I ran composer install with different levels of logging. Without logging, it moaned that it couldn't find a valid composer.json. With logging, it moaned that it couldn't access the repo (despite scanning the tags).
The solution for me was to globally install the latest version of Composer as the Ubuntu repo version was using outdated BitBucket API calls (v1 is deprecated). Once I had updated to a newer version of Composer, the install ran perfectly.
So check your Composer version and install an updated version if possible (a local/project install should work too).
I've just updated composer.json to last version and the problem gone away.
I have made many modifications and fixes to a composer library that gets it's data from github , and it does have a dependency.
How can I preserve them easily while being able to get updates from package owner?
You could fork the project on Github, commit your modifications to your fork, then point composer at it.
When new updates come from the original package owner, you can merge them into your project using git's standard merge features.
When I have a project I have forked on github, I will often keep two remotes on my local copy, like so:
git clone [url of my fork]
cd [project name]
git remote add upstream [url of original project]
When updates are applied to the original project, I do something like:
git fetch upstream
git merge upstream/master
As my edit are rejected for absurd reasons. Fork like rjmunro suggests.
Then you need to refence your fork in composer.json
Example assuming you patched monolog to fix a bug in the bugfix branch:
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/igorw/monolog"
}
],
"require": {
"monolog/monolog": "dev-bugfix"
}
}
Take a look at the VCS part in the documentation!