Repository navigation
Put all providers in separate packages #578
Description
Currently there are over 15 providers in this repo an at least 10 more in the geocoder-extra repo. I have a feeling that most developers do not use all providers available. I would like to suggest that we do a subtree split of this repo to create the following repos
| Repository | Package name | Contents |
|---|---|---|
| geocoder-php/Geocoder | none | Everything |
| geocoder-php/php-common | willdurand/geocoder | Interfaces, Geocoders, Models, dumpers, exceptions, formatters |
| geocoder-php/google-maps-provider | geocoder-php/google-maps-provider | GoogleMaps provider + tests |
| geocoder-php/bing-maps-provider | geocoder-php/bing-maps-provider | BingMaps provider + tests |
| ... | ... | ... |
| geocoder-php/chain-provider | geocoder-php/chain-provider | Chain provider + tests |
To use one the GoogleMaps provider you would install geocoder-php/google-maps-provider.
Benefits
- No optional dependencies or suggests
- No need for geocoder extra package
- Version each provider separately. If one provider has a BC break we do not need to bump all providers.
- Statistics which provider is getting used
Drawbacks
All providers must live in a separate namespace. That would be a BC break.
What we actually have to do
- We create a lots of new repos
- Move the test code to the providers
- Change the repository for package
willdurand/geocodertogeocoder-php/php-common
What do you think?
Is it a good idea? Should this be done before 4.0, 5.0 or not at all? Has 4.0 too many changes already?
Disclaimer: I am the author of https://www.subtreesplit.com so of course I think this is the best idea ever. Please give me some feedback.
Activity
arubacao commentedon Jan 18, 2017
I like the idea very much.
Another benefit:
Just for inspiration purposes, Laravel has similar approaches:
https://socialiteproviders.github.io/
https://github.com/laravel-notification-channels
vingrad commentedon Feb 3, 2017
Yes, please make this. It's a good idea.
drupol commentedon Apr 3, 2017
Hi,
I'm for this kind of things of course.
The things is that it is a big refactoring.
I still believe that we should have tagged a release before doing this, just in case.
Nyholm commentedon Apr 3, 2017
We have currently some BC breaks in master so next tag will be 4.0.0. I hope that 4.0.0 will live a long life and 5.0 is in late 2018. If we wait with this feature we will not see it until 2018.
sagikazarmark commentedon Apr 7, 2017
I agree with @Nyholm that this would be a good move. We had this discussion in PHP-HTTP initially when we worked on our HTTP adapters for HTTPlug and we ended up having separate packages.
willdurand commentedon Apr 8, 2017
👍
Nyholm commentedon Apr 9, 2017
Great. I will make a PR after for this change.
DJaeger commentedon Apr 29, 2017
👍
Nyholm commentedon May 20, 2017
I've created https://github.com/geocoder-php/google-maps-provider and a composer package. If you think it looks good I will start with the rest of the providers.
willdurand commentedon May 22, 2017
Very nice!
Nyholm commentedon Jun 17, 2017
This is now complete. I changed the repository for package willdurand/geocoder to geocoder-php/php-common
sagikazarmark commentedon Jun 18, 2017
Why the name
phpcommon? Isn't that obvious?Also, as I can see the chain provider is also moved to a separate package. At HTTPlug we tried to separate only those which had an external dependency. Wouldn't it work here as well? The few extra LOC shouldn't be a problem IMO.
Nyholm commentedon Jun 18, 2017
Yeah, maybe.
There are some other js libraries in this organization. Maybe it should be only
geocoder-php/commonYeah, but it is also about separate versioning (and download stats). I agree that Chain provider is special and it maybe should be in the Common.
sagikazarmark commentedon Jun 18, 2017
Noted.
Not sure if those add that much benefit when there are no external dependencies involved. Separate packages can make things simpler from a dependency point of view, but they also mean an overhead to the user (install separately, UPGRADE separately).