Menu
If you go you https://packagist.org/packages/geekality/website and compare it with what you get when you run `composer show geekality/website.
What is going on here? How do I fix this? If I change my composer.json to target version/tag 0.7.1, which to me clearly exists on both packagist and on GitHub, I get an error message saying the requested package could not be found.
I have tried
Anyone have any idea what's going on?
Seems like this is caused by some issues with Packagist and that nothing is actually wrong on my side (or others who seem to have the same problem).
I "solved" it temporarily by listing the source of problematic repositories manually in composer.json.
720
To update your packagesNavigate to the root of your git repo, where your composer. json file is. Run composer update (on your local machine) to update the required packages and re-generate a composer.
A repository is a package source. It's a list of packages/versions. Composer will look in all your repositories to find the packages your project requires. By default, only the Packagist.org repository is registered in Composer.
Try clearing Composer's cache by running composer clear-cache . Ensure you're installing vendors straight from your composer. json via rm -rf vendor && composer update -v when troubleshooting, excluding any possible interferences with existing vendor installations or composer.
You can check your installed composer version using a command composer -v at the current path. Such as: composer -v.
The solution in this case was to wait for Packagist to not be broken.
So, if anyone else have this issue and they have checked all their stuff, maybe check twitter or something to see if anyone else are having issues.
97
It looks like you stuffed up either your tags or moved origin/master back to an earlier version.
It is version v0.5 that still has the origin/master and master tags associated with it which is very odd.
I think you want to just reset master to the lastest commit, however you probably ought to figure out how this happened first, in case there's something even weirder going on.
The way I tag versions is:
git tag 1.2.3 on a command line.git push --tags
I think you may have caused this issue by skipping step 1 and still having uncommitted changes locally. If you can push those commits, that might fix the problem, otherwise you may need to reset the head to the appropriate version.
In Atlassian Sourcetree that can be done by right clicking on the appropriate checkin, otherwise you can do it from the command line with the git reset command:
git reset --soft a4ed43d16ecb20aaa275ee120e073e043190e093
Does not touch the index file nor the working tree at all (but resets the head to , just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.
That should not delete anything either locally or remotely, but just change where the head is pointing to.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
