search

maxmind / GeoIP2-perl

Perl API for MaxMind's GeoIP2 web services and databases
https://metacpan.org/release/GeoIP2/
Other
18 stars 11 forks source link

Split into Database and WebService #31

Closed jlanawalt closed 8 years ago

jlanawalt commented 8 years ago

Hi,

Thank you for putting together this API for Perl consumption of GeoIP2. I am very interested in distributing it across some Debian servers I manage as Debian packages. I would like to minimize the dependencies pulled in and avoid replacing (Debian) distribution maintained Perl libraries (modules) with newer versions required by GeoIP2 for code paths I don't need.

On a Debian 8.0 (Jessie) release server I can run bin/web-service-request after installing libdata-validate-ip-perl (0.24-1) for Data::Validate::IP and libthrowable-perl (0.200012-1) for Throwable::Error. With those two external dependencies and the code in lib/GeoIP2 I'm able to make the web requests I'm interested in.

If I try to install GeoIP2 though it requires MaxMind::DB packages and that quickly leads to many more packages, some of which need to be newer than the ones shipped with Debian 8.0.

If GeoIP2-perl were split into three (Perl) distributions, GeoIP2-Common, GeoIP2-WebService, and GeoIP2-Database, I could build Debian packages for libgeoip2-common and libgeoip2-webservice, skipping the database code I'm not interested. It should also make it easier for others who are only interested in consuming your web service using Perl to do so.

This issue is an interesting reverse on the GeoIP2-dotnet issue #16 where the database only code is wanted to avoid the extra web service dependencies.

I looked for different options in newer Perl build systems than ExtUtils::MakeMaker to build multiple 'packages' out of one Perl source distribution, but came up short. They may exist, but after searching I was told by one knowledgeable Perl module creator and maintainer that the distribution is basically the unit of installation in Perl, and changing that mostly results in confused users and broken deployments. They would default to having three distributions / tarballs if it was important to install X and Y and not Z when the distribution contains X, Y, and Z.

For my own needs I can modify the Makefile.PL and remove lib/GeoIP2/Database and related code and build my custom package, or could maybe split it into three unofficial parts and just build two, but it would be nice to mirror whatever you are willing to do to make installation of just the WebService Perl module and common code easier.

jlanawalt commented 8 years ago

The dependencies and stuff to learn to figure out how to make Dist::Zilla create three Perl distributions from one source package blew out my time window so I ended up hacking out the code I didn't need, dropping all the Dist::Zilla stuff, and tweaking Makefile.PL to build just the WebService related code into GeoIP2-WebOnly and packaging that for my systems. Seems to work.

It would be great if the source could be structured to build the three Perl distributions, -common, -webclient, and -database, from the one source.

autarch commented 8 years ago

Hi Jacob,

We discussed this internally and we don't want to split this up into three packages. I understand your goal, but doing this would make managing these libraries a lot more complicated for us.

Cheers,

Dave

jlanawalt commented 8 years ago

I recently tried another service that had a simple slurp & dump 20 line LWP example. I was able to throw the JSON module into the mix and had a working custom client that day in under 100 lines of code, and their JSON response documentation wasn't the most comprehensive I've worked with. Because the requirements were so light I was able to deploy it right away.

Any concerns about a 3rd party Perl module of just the webservice client?

It would use very little outside of LWP and JSON, so I'm thinking of names like GeoIP2::WebService::Client::Only or GeoIP2::WebService::Client::Lite. If that's too close for comfort, I also considered some variations under the Geo namespace like Geo::GeoIP2::Client.

oschwald commented 8 years ago

@jlanawalt, please feel free to make a third-party module that fits your use case better. As long as it is clear from the documentation that it is not distributed by MaxMind, I don't think we would have any concerns. I might suggest the WebService:: namespace, but that's really up to you.