7

If you go you https://packagist.org/packages/geekality/website and compare it with what you get when you run `composer show geekality/website.

  1. Latest version at packagist at the top is v0.7
  2. Latest version given in command line output is v0.6
  3. Latest version should have been v0.7.1 in both cases
  4. Version >= 0.7 doesn't even show up in the command line
  5. The dev-master version points to v0.5 ??

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

  • Delete vendor folder and re-update
  • Delete the composer cache
  • Do the composer update on a different computer
  • Delete and recreate the package on Packagist
  • Create and push a new tag (0.7.1 is basically same as 0.7)

Anyone have any idea what's going on?

Update

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.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
Svish
  • 152,914
  • 173
  • 462
  • 620
  • Please, help, I have the [same problem](https://stackoverflow.com/questions/58586759/composer-does-not-see-a-new-release-when-the-packagist-sees-it-fine) – Yevgeniy Afanasyev Oct 28 '19 at 07:05

2 Answers2

5

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.

Svish
  • 152,914
  • 173
  • 462
  • 620
  • I'm having the same issue: the version is listed on Packagist but can't be installed through `composer update`. However, it can be installed by referencing the GitHub repo as a VCS in the composer file. How long did you have to wait for the problem to be solved? – Jon Sep 03 '16 at 08:31
  • @Jonathan Don't remember really, but don't think it was super long. Max a day? Either way, do check twitter or something, as others should be noticiing the same if it's the case. – Svish Sep 03 '16 at 09:53
  • 1
    Thanks for your answer. I just tried again and it has finally been resolved automatically. At last! However, I didn't find any particular report of this issue on Twitter nor on Stackoverflow. – Jon Sep 04 '16 at 18:58
2

It looks like you stuffed up either your tags or moved origin/master back to an earlier version.

Tags for Svish php-web

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:

  1. Check in and push everything to the remote repository.
  2. Run git tag 1.2.3 on a command line.
  3. Push the tags on the 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.

Danack
  • 24,939
  • 16
  • 90
  • 122
  • oich. that explains things I suppose. Kind of newb at git stuff still when it comes to the more complex craziness. How do I fix this? – Svish Jun 06 '13 at 14:19
  • I'm using the GitHub for Windows client, but also git straight from command line as I haven't found a way to create and push tags in the GUI client. I just noticed that even though I have pushed from command-line the gui says I have a couple of unsynced commits. I assume this will fix it, but how can I make sure that they are working together and not "against" each other from now on? – Svish Jun 06 '13 at 14:21
  • Still seems to be a mismatch somewhere. Not getting it. Did the sync in the GitHub gui client, and now dev-master references 0.7.1 on Packagist, but I still get 0.5 when I run composer update. And still fails to get 0.7 or 0.7.1. If I set version to be 0.*, I get 0.6. I don't get it... – Svish Jun 06 '13 at 14:40
  • Think I'll just have to delete the package and the repository and re-up everything. Will lose the git history and all, but yeah... I'm unable to fix this :/ – Svish Jun 06 '13 at 14:57
  • I think Packagist may be having an outage. https://twitter.com/PrincipeBorodin/status/342655643603324929 – Danack Jun 06 '13 at 15:02
  • Ooooh... sigh... lol. Recreated both repository and [package](https://packagist.org/packages/geekality/webframework) now. Even named both something else to make sure they did not mess with each other. Packagist looks correct, composer still unable to find anything :/ Guess they might be having problems over there. – Svish Jun 06 '13 at 15:19
  • Yep - I can't deploy right now as latest version of my project requires an 'unfindable' library, which is same as yours, exists on website, not in composer. – Danack Jun 06 '13 at 15:21
  • Please, help, I have the [same problem](https://stackoverflow.com/questions/58586759/composer-does-not-see-a-new-release-when-the-packagist-sees-it-fine) – Yevgeniy Afanasyev Oct 28 '19 at 07:07