I've made custom changes to a package (Its wrong, I know) and I want to preseve these changes every time I update composer .. How can I?
Tag that version in your own repository and depend on the tag without any wildcards. Composer will never try to grab a different commit then.
If you are unsure which version to use, and the upstream project didn't release a tagged version yet, start with 0.0.0. If you are basing your work on top of a tagged release X.Y.Z, you might tag your changes as X.Y.Z.1 and depend on that exact version.
Related
I released a package version to packagist.org, through github.com releases, with a version tag that packagist.org didn't like (suffix of -dev). I've corrected the version error and republished and the corrected version is now showing up on packagist.org.
However, there is still a warning message (I'm assuming only seen by me, as the maintainer) that:
Some tags were ignored because of a version mismatch in composer.json.
Not a big deal, but it would be nice to remove that warning message. How can I do that?
Please note, there is not a version attribute in the composer.json file and as already mentioned, the latest release is showing up just fine.
Some tags were ignored because of a version mismatch in composer.json. [in the admin of packagist.org]
[...] it would be nice to remove that warning message. How can I do that?
In short, delete the tag from Microsoft Github, as it is the (remote) Git repository Composer uses for your package.
Longer:
Given Composer checks for versions (releases) in a package and it is a Git repository, one thing Composer does is to fetch all tags (e.x. git-ls-remote(1)), then checking the composer.json project configuration file at those revisions.
When the <tag-ref>:composer.json#/version mismatches the <tag-ref> (in your specific case this is more a virtual thing here as it is about validating the <tag-reg> as a composer.json#/version but exactly this contraint applies here), then the tag (as a package version) is dropped and the warning is shown so that you notice this, as it can have consequences that a specific version could not be found.
As Packagist does this to do the book-keeping for the services of packagist.org (indexing all public packages), you see it in the admin panel there.
In your case this is less an issue as you don't miss the version (you've solved that already by adding a new version "on top"), it still nudges you and you want to get rid of it.
The only way to achieve that is to yank the culprit, that is the actual tag (<tag-ref> above) in the repository, specifically the Git repository Composer connects to.
Now, removing published tags has consequences, and yes, this is a warning, so check your baseline for your actions. The git-tag(1) docs have a section I'd recommend as a reading in this context:
On Re-tagging - git-tag(1)
It's not a perfect match for the case asked about, but worth to understand before changing or even deleting a tag that has been pushed. YMMV.
The problem with the actual tag-name may come as a surprise as you normally can tag in Git quite freely (only some constraints on the tag-name).
But if the same Git repository is used as well as a package source for Composer (a package repository in Composer sprak), there are more requirements, specifically I'd recommend the following readings from the official Composer documentation to handle the tagging in the future without the warnings:
Composer Versions vs VCS Versions
VCS Tags and Branches (2.1 - 2.4).
Additional note: There can be other causes of this warning, just deleting the tag will not remove the warning then. Prevent such causes by using composer-validate before publishing (as you should do anyway) and understand all of the warnings of it, hypertext references should be provided.
I regularly observe the following behaviour:
When I try to execute composer update mynamespace/myproject, it fails because if conflicts with a dependent project "mynamespace/mydependency", which is 'locked' at a specific version - the version specified in the composer.lock file. I don't get what 'locked' means in that context, but I observe that the update works well once I deleted the entry
{
name : "mynamespace/mydependency"
...
}
from composer.lock. This behaviour is in contrast to what I understood so far that the composer.lock file was supposed to do - recording what exact versions are installed without specifiying any restrictions on composer.json.
Since my assumption has been proven wrong, I would be thankful to some clarification.
Never ever edit the lock file by hand, that will only cause trouble. If updating a single dependency does not work, you've found the reason already: cause it's still needed in the current version by any other dependency.
To see why an update is not possible, you can use composer why-not, followed by the package name and the version you want to update to. For example, the following command could list why exactly updating to v3 is not possible:
composer why-not mynamespace/myproject 3.0
Now, you can either decide to skip the update for now, or add any of the packages that are listed there to your update command such that these also receive an update.
NB: it's very common that updating a single component (and nothing else) is not possible, especially if this is not a minor update
I've created a v1.0.4 tag for my plug-in and deployer executed composer update on the server. After a short amount of time I've deleted this tag and created it again because this version needed a minor modification.
Now when deployer executes composer update on the server the plug-in is not been updated to the new v1.0.4 (that includes the modification) because the version number is still the same.
I've executed composer clear-cache on the server but this does not seem to work. Is this even possible or was it better to create a new version for this modification?
The modified tag v1.0.4 is present in the repository. Any help is appreciated.
Please tag your plugin properly as a new version. If v1.0.4 of it is already installed, the commit hash used by that tag is stored in composer.lock, and getting this fixed might lead to more problems popping up.
I have to update CakePHP from current, outdated version (2.7.7) to latest on 2 branch, because of PHP7 support.
While I've done numerous framework upgrades before, I found book.cakephp.org a more than a cryptic about key things which I ask here:
can it be done by replacing directoris
which directories are intended to be replaced (never edit dirs, like system in Codeigniter)
which directories are partially replaced if any
is there SQL commands that should be run?
is there other commands that should be run?
Any clue is appreciated, but 2 and 3 are of most value I guess. Thanks in advance.
Depending on how you've installed CakePHP, you either use composer to update the CakePHP core dependency:
$ composer update
or require a specific constraint/version if your current constraint doesn't allow upgrading:
$ composer require cakephp/cakephp:^2.10.3
If you're not using composer (I'd suggest to switch to using it), then you download the latest release package manually, and completely replace the /lib/Cake directory. With respect to the core, the upgrade is then complete.
Then read the migration guides to figure the possible changes that you have to apply to your application code or database schemas, and also compare the "application template" changes (/app/) to your local application and apply changes in case necessary. After this, run your test suite to ensure that everything works as expected.
With that being said, the upgrade from 2.7 to the latest 2.10 should be pretty easy, as it is said to be fully API compatible.
I recommend you to use composer to manage your framework and extensions.
With composer installed, it would be much easier to update. If you decide to use composer, let me know if you need any more help by installation, setup or update.
Is there an automated way of updating the version number in composer.json and adding the necessary tags before publishing, like the way npm version does?
I mean, if you had a composer.json with the line "version": "2.1.3", and executed:
composer version minor
It would do the following:
Updating the version number in composer.json to 2.2.0
Triggering composer update to update composer.lock
Making a new git commit
Making a new git tag v2.2.0
I know that the composer version command doesn't exist, but is there an equivalent tool?
npm version does stuff that you very likely do not need for Composer:
The version number is not recorded in composer.json if there are other means available - and because you are referring to Git later on, they are available.
Updating dependencies in the lock file is unnecessary. The lock file will be ignored when the project you are dealing with is included somewhere else.
Because nothing has changed in the project, a git commit wouldn't do anything.
All this leaves you with creating a new tag in the Git repository. Putting this into Composer would mean you'd exchange one command with another, without any big benefit besides you won't have to lookup the current version number you are dealing with if you use some of the relative version parameters.
All in all I'd say that simply tagging your new version is enough for Composer. You'd probably need to have some infrastructure in place and configured to make the world aware of the new version:
If your package is open source and on packagist.org, you should have a post-commit hook to notify them as soon as a new version is available. This is a standard option on Github, I don't know about other source code hosts.
Otherwise if you have to feed closed source code, you'd probably start a new update cycle of whatever system is used to create an alternative package information source (be it Satis, locally hosted Packagist, Toran Proxy or Private Packagist)
This however depends on how you set up things.
If for some reason and despite all voices against it you still want to use a tool like the OP asked for, https://www.npmjs.com/package/composer-version works quite well.