packagist not detecting version of my package

[jurchiks]

https://packagist.org/packages/jurchiks/numbers2words

When I initially added the package, the composer.json file did not contain version info and there was no version tag, but the command composer require jurchiks/numbers2words did not work and continues to not work:
[InvalidArgumentException]
Could not find package jurchiks/numbers2words at any version for your minimum-stability (stable). Check the package spelling or your minimum-stability

Since adding the package, I have added a github push hook, pushed a "version": "1.0.0" addition to the repository, upped the version to 1.0.2, added a git tag 1.0.0 and deleted the "version" entry in composer.json file. I've tried deleting the version shown on the package page and manually updating it.
Nothing helps! It is still detecting only dev-master.

WTF? What does it want from me?

[jurchiks]

Update: adding another tag with version "1.0.2" and no title finally fixed this and 1.0.2 showed up on the package page, but why is it that tricky to get it right?

[stof]

there is an known issue with github hooks: pushing a tag pointing to a commit which is already available on Github (and so not pushing any new commit) does not trigger the push webhook, and so Packagist is not notified.
The workaround is to trigger a manual update in the packagist UI. Otherwise the tag will be picked only the next time you push a commit to github.

And I strongly recommend you not to add an explicit version in your composer.json: if you have an explicit version in your file and it does not match the tag name, Composer will consider the tag as broken and will reject it (and it will never appear on Packagist because of that).

[jurchiks]

Yeah, I read about that mismatch thing and that's why I removed it, but that didn't solve the issue, even though I tried manually removing the versions and updating the package.

This isn't an issue with the github hook per se. It should have detected the version right when I added "version": "1.0.0" to composer.json, the push hook worked because the last update time changed on the package page, but the version was not detected.

I would much rather just update the version in the composer.json whenever necessary than do the tagging, simply because it is simpler that way.

[stof]

@jurchiks if you push the master branch first, and then push the tag later in a separate command, github will notify a push webhook for the first push updating the branch (but the tag does not exist yet on Github so Packagist cannot see it) and will not notify it for the git push --tags command following it (because it is not pushing any commit)

[jurchiks]

Ok, fine, but like I said, this isn't about notifications. The last update time changes every time correctly, it just didn't detect my version!
I have since then created another tag, "1.0.2", and via the GitHub interface (Releases > Draft a new release) and for some reason doing that finally fixed the issue and 1.0.2 showed up on the packagist page.

But it should have worked with my first commit that added "version" in the composer.json file!

[stof]

well, given that you deleted the previous tags, it is hard for me to go seeing what could have caused it

[jurchiks]

I only deleted one tag, "1.0.0".

[Seldaek]

Right now the repo update reports:

Update successful
Reading composer.json of jurchiks/numbers2words (1.0.2)
Importing tag 1.0.2 (1.0.2.0)
Reading composer.json of jurchiks/numbers2words (master)
Importing branch master (dev-master)

So I don't really see the problem, and I am not sure what happened in the past. The best is to skip the version in composer.json, so you should be good to go now, and your next tag should appear whenever you create it. If not then please get in touch again before doing any more changes to the repo.

[jurchiks]

I know it works now, because of the shit I had to do with the tags. The issue is that it did not work with just the "version": "1.0.0" in composer.json. I don't want to use git tags.

[Seldaek]

OK I see, but creating a git tag is the only way to publish a release on packagist. The version in composer.json is purely informational, and it has to match the tag if it's present or it invalidates the tag, but the presence of a version isn't enough to have a tag. Otherwise how would we know which commit version 1.0.0 should point to if there is no fixed tag? It could be any of the commit until you change it to 1.0.1, etc. git tags give consistency and they are easy to create, so I really don't see the problem.

[jurchiks]

Greeeat...

[Seldaek]

Can you perhaps stop the complaining and explain what the problem is? Of the 70 thousand packages we have on packagist, you're the first person ever to complain about having to git tag to release.

[jurchiks]

Like I've said multiple times already, I want to be able to use ONLY the "version" label in the composer.json file, no git tags. But apparently that's not possible.

[Seldaek]

What you want does not say why you want it. Anyway no that's not gonna be possible, but if you explained then maybe just maybe we can find a better way.

[jurchiks]

Obviously I want it for simplicity.
From what I see, if I work on only the master branch and make only tiny bugfixes, then I have to make a new tag with every bugfix (+1 PATCH version), and the list of tags keeps growing (at least in Github "releases" tab it shows more than one if I leave them be). I don't want that. I just want a single number defining the current version of the repository.

[Seldaek]

The current version of the repo is shown on top.. See for example https://github.com/Seldaek/monolog/releases - not only do you get the current on top, you also get a changelog and history of all versions. I don't see at all how that is an issue.

And yes, you have to make a tag for every patch release, but that's not any more work than tweaking the version in composer.json and then pushing it. Rather less I'd say.

The only thing that changes from your workflow is that you don't necessarily have a new version for every bugfix, but you can do a version every X (time unit, or amount of bugfix, whenever it makes sense IMO). In the meantime, people can still rely on your package's latest state by requiring it as ^1.0@dev for example. That is only if you configure a branch-alias, see https://getcomposer.org/doc/articles/aliases.md#aliases if you are not familiar.

[jurchiks]

It could be simpler.

[lazychaser]

I'm having the same issue with kalnoy/illuminate-menu. Packagist doesn't see v1.2.0. I tried to manually update the package from packagist UI and it didn't help.

[alcohol]

@lazychaser most likely you first pushed the last commit (cause master is up to date), and then only later pushed the tag. This was also explained by @stof in this comment earlier in this thread.

[jurchiks]

But why does manually updating not fix this?

[lazychaser]

After I tagged release again and pushed it, packagist updated successfully. But it seems to be an issue, since this workflow (push commits, then push tags) worked fine before.

[alcohol]

It depends on timing, really.

[lazychaser]

How can I push both tags and commits together?

[alcohol]

I just usually do git push && git push --tags on the command line.

[lazychaser]

Ok, @alcohol, thanks!

[stof]

@lazychaser git push origin master --tags to push both the master branch and tags

@alcohol your command still performs 2 separate pushes (even though it performs them really quickly, meaning the timeframe in which it happens is likely to be too short)

[alcohol]

Yeah I wasn't sure how to specify the reference properly when using --tags. But my shortcut never failed me yet :d

[stof]

@alcohol as I said, the time between both pushes is probably shorter than the time between the first push and when Packagist reads the data in the webhook. This is a race condition situation, and you are just lucky (quite expected though as the second push transfers very little things as all commits are already pushed, but put a heavy pre-push git hook locally and you will see it happening).

[hwperkins]

For what it's worth to anyone who comes along in the future, my packagist badge was showing "No release" until I went to my project's packagist page and deleted the "dev-master" version from the list on the right the packagist cache was updated to reflect the correct stable version. ;)

[Seldaek]

@HWGehring badges are built using the packagist API which is cached for up to 1h so deleting things has no impact it was just luck that it started working at that point IMO.

[stof]

and badges are not implemented by Packagist itself. If there is a bug with them, open an issue on https://github.com/PUGX/badge-poser

[hwperkins]

@Seldaek Indeed, imagine my frustration the 2nd time around. It's just a matter of patience. Thanks

[eghojansu]

Hi, im googling for this and my issue is a little bit different.
i have a repository eghojansu/fa-simple-php
which i have already set a webhooks to packagist fa-simple-php.
Now my package version is 2.2.1 but still when i use composer create-project eghojansu/fa-simple-php , i am getting previous version (2.1.2).

I already create new tag (2.2.1 is same as 2.2.0). and I already clear composer cache.
this Issues still appear.
what should i do? please help

PS: sorry for my bad english

[alcohol]

Works for me;

 % composer create-project eghojansu/fa-simple-php
Installing eghojansu/fa-simple-php (v2.2.1)
...

[eghojansu]

@alcohol yes, that works after 12 hours since i push it to github :)
thats why i posted here. I dont know what happen with github or packagist but that was strange

[stiko]

Just in case someone beginner like me searches for this. If packagist does not update even when you manually click it, make sure to update composer.json version then tag with the same version then push
$git push origin master --tags

[Seldaek]

The best really is to delete the version field from composer.json then it will take the tag name as version and not ignore tags if they don't match the version.

[stiko]

@Seldaek Thank you so much for letting me know that. I thought I have to have it there and it was causing me a lot of issues.