Here provider needs an update: apiKey

[verybigelephants]

now, the created apps use apiKey instead of app_id and app_code, however, the library only accepts app_id/app_code. these two cannot be generated in the Here panel for anymore (only for ios and android apps), and official developers even discourage using them https://stackoverflow.com/questions/60438951/does-app-key-means-the-same-as-app-code-for-here-geocoding-credentials-on-py

[jbelien]

Hello @verybigelephants ,

Thanks for the notice! Would you have time to create a PR to extend the library to use apiKey ?

[verybigelephants]

i would like to contribute i'm not sure how does the process actually work with the composer libraries. that is, how to actually test the code that i'll write :D

• i mean, if i modify the code inside the vendor directory then i'm not modifying the actual git repository https://github.com/geocoder-php/here-provider
• while if i actually checkout the https://github.com/geocoder-php/here-provider repository i can modify the code and make a pull request, but then i won't be able to actually test it in my application, as i'm not using it via composer install
• or should i modify it inside the vendor in my application and then, once working, i should copy it manually to the checked out directory? this seems really cumbersome and not right

could you point me in the right direction?

[jbelien]

All are dedicated repository for each provider are read-only ; you'll have to submit your PR to this main repository [geocoder-php/Geocoder](https://github.com/geocoder-php/Geocoder]. You can find the Here provider in src/Provider/Here.

For testing while your adapting the provider, you can for instance use path in your composer.json file to point the library to a specific folder.

[verybigelephants]

i've tried "\o_O/"

https://github.com/geocoder-php/Geocoder/pull/1088

[atymic]

I had a PR open for this already as well, in https://github.com/geocoder-php/Geocoder/pull/1042 I'm not sure why it didn't end up being merged, will check now.

[atymic]

Okay, looks like it just needs docs, I can update this arvo.

[verybigelephants]

i don't mean to offend or anything, but why would you keep deprecated app id/code inside the main __constructor and then make another another static method for a new constructor. this is a red flag that the library will need yet another update in a short future.

i mean, i understand that you've wanted to keep the old users using this api update without a hassle, but then why wouldn't you use something like func_get_args inside a __constructor and check the argument types then? :S

[jbelien]

I had a PR open for this already as well, in #1042 I'm not sure why it didn't end up being merged, will check now.

Oh riiiight, I thought we had already did something about that ... didn't think to check the existing PR 🤦‍♂️ @atymic Could you finish that one so we can merge it ?

[jbelien]

Duplicate of #1041

[jbelien]

i don't mean to offend or anything, but why would you keep deprecated app id/code inside the main __constructor and then make another another static method for a new constructor. this is a red flag that the library will need yet another update in a short future.

i mean, i understand that you've wanted to keep the old users using this api update without a hassle, but then why wouldn't you use something like func_get_args inside a __constructor and check the argument types then? :S

@verybigelephants We try to avoid as much as possible any breaking change. If appId/appCode still works (which seems to be the case, even though they're deprecated), there should not be any breaking change. In the way proposed in #1042, the current user won't have to adapt anything (which is how it should be) and the new appKey method is available.

[jbelien]

Version 0.5.0 is released.