Ivory\HttpAdapter dependencies with geocoder
AntoineLemaire opened this issue · comments
Since few days, the repository of geocoder changed from https://github.com/geocoder-php/Geocoder to https://github.com/geocoder-php/php-common
In BazingaGeocoderBundle, the require is willdurand/geocoder: ~3.1
In geocoder-php/php-common on version 3.3.1 "egeloen/http-adapter": "~0.8", has been removed from the required packages. (It's still here in 3.3.0)
And geocoder-bundle is still using "CurlHttpAdapter" from namespace "Ivory\HttpAdapter" as bazinga_geocoder.geocoder.default_adapter.class in https://github.com/geocoder-php/BazingaGeocoderBundle/blob/master/Resources/config/services.xml
cc @Nyholm
Thank you for the Ping. I just started watching this repo now.
This is a really strange issue.
The repository change is unrelated. We changed that last Saturday. However, on the Geocoder tags page there is no 3.3.1. But there is on php-common.
The 3.3.1 taged in February by @istvancsabakis. Do anybody knows why? That person does not have push access.. Did he/she in February?
I think the correct solution would be to tag 3.3.2 as the same tag as 3.3.0. William, what do you think? I do not want to remove a tag, or should I?
I have now pushed tag 3.3.2. Everything should work as normal.
Thank you @AntoineLemaire for reporting this.
FYI. The bundle will see some updates during the summer.
Thanks to you ;)
Errr I don't get it. Maybe GitHub references the commit author as tag author too. We likely merged his fix... Still have to investigate though..
Thanks for the quick resolution!
Yeah... But he/she is not even a contributor...
@Nyholm I started tracking this thing. You did merge a PR with this exact change: geocoder-php/Geocoder#588. The username is slightly different but commit shas both match.
I did not tag version 3.3.1 because all my commits/tags are GPG signed, and the 3.3.1 is not.
@Nyholm I would recommend you to do the same, cf. https://help.github.com/articles/signing-tags-using-gpg/.
Okey, that explains the user name, but not the tag. I've no idea where that came from.
Yes, I set up signing yesterday. Thank you.
Could it be that you inadvertently created a local tag for 3.3.1?
What is weird is that the tag is on one commit of the PR I linked above, not on a PR merge commit.
So I believe the tag comes from this repo: https://github.com/istvankis/Geocoder/releases/tag/v3.3.1.
Question is: how tags are created in php-common? I guess it uses your tool, right?
So I believe the tag comes from this repo: https://github.com/istvankis/Geocoder/releases/tag/v3.3.1.
Yes, that makes sense. When I created php-common i pushed "all" tags from the original repo. That must have included istvankis' tag.
Question is: how tags are created in php-common? I guess it uses your tool, right?
No, it does not push tags. We want to version each component independently. Ie the Bing Maps provider could make breaking changes every month if it liked.
Still weird to pull other tags from the main original repo, no?
Yes. I believe I just did a git push --tags php-common
So, I made a mistake before. I should have verified the tags better.
I (or we) will not do the same operation again, so there is no change of this happening again.
Yes. I wish Packagist would have an option to only publish versions from (GPG-)signed tags. /poke @Seldaek 😃
I doubt this would help fix all such cases.. If the tag in istvankis/Geocoder was signed too, it would've still imported it.
This is just a bad luck thing + small mistake of not realizing you pulled in a new tag which is really easy to miss tbh.
Yes, correct. Thanks for your input.