CODEWITHSUNDEEP
versioningcomposer-phppackagist
Svish
Svish

Reputation: 158341

Composer/Packagist not giving me my latest package

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

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.

Upvotes: 8

Views: 5582

Answers (2)

Svish
Svish

Reputation: 158341

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.

Upvotes: 6

Danack
Danack

Reputation: 25721

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.

Upvotes: 2

Related Questions