This is aimed at people who are new to the package. I feel like I’ve consulted the docs 50 times to remember which submodule contains the get_driver methods and which contains the Provider enum class. Maybe that’s just me, but I find it quite unintuitive.
The change is really a shortcut, aimed at being a tad more obvious for people who don’t read documentation. The other thing you can’t do in the current system is programmatically instantiate a driver from each type without having to use __import__ I’m not wedded to this, but it would be good to see what some newer users have to say. There might be a better solution to this. On 5/07/2016, 8:09 AM, "Samuel Marks" <[email protected]> wrote: Yeah I agree with you Tomaz, no advantage for me either (but no complaints!). In regards to your other line, I already iterate over all available providers in my code by importing+transforming a few dictionaries out of libcloud... So this change would at most save a line of Python for me On Monday, 4 July 2016, Tomaz Muraus <[email protected]> wrote: > And I forgot to say - if there is any other benefit or advantage of this > approach over the existing ones which I am missing, please speak up :) > > On Mon, Jul 4, 2016 at 3:26 PM, Tomaz Muraus <[email protected] > <javascript:;>> wrote: > > > I personally don't see any value in that approach over the existing one, > > but I won't block it :) > > > > I would see some value if the APIs itself were changing frequently. In > > that case you could potentially iterate over all the available APIs with > > this proposed approach, but right now this is not really a big deal. > > > > APIs don't change often and when you work with some API and driver you > > need to explicitly select it (and need to be aware of the selection). > > > > I guess you could argue that just doing "import libcloud" is a bit more > > convenient, but then again what we are really doing is just moving that > > logic from import line to the function name and function arguments so > it's > > not really reducing complexity or anything. > > > > And then again I would argue Python already includes good support for > > namespacing things called packages and that's what we use right now (with > > the proposed approach we would replace that "Pythonic" thing with a thing > > which would better be used in languages which don't have good native > > support for namespacing things, imo). > > > > On Sun, Jun 26, 2016 at 1:30 AM, anthony shaw <[email protected] > <javascript:;>> > > wrote: > > > >> Hi, > >> > >> I've just created a PR, #822, proposing a slightly new API for 1.1, it > >> is backward compatible but would form the new recommended entry path > >> for instantiating drivers. > >> > >> I took a leaf out of requests book, (import requests; requests.get(' > >> goole.com')) > >> > >> Instead of the current > >> > >> from libcloud.compute.providers import Provider > >> from libcloud.compute.providers import get_driver > >> > >> cls = get_driver(Provider.RACKSPACE) > >> > >> The new way is > >> > >> import libcloud > >> cls = libcloud.get_driver(libcloud.DriverType.COMPUTE, > >> libcloud.DriverType.COMPUTE.RACKSPACE) > >> > >> OR > >> > >> import libcloud > >> cls = libcloud.get_compute_driver(libcloud.DriverType.COMPUTE.RACKSPACE) > >> > >> Comments please. > >> > >> https://github.com/apache/libcloud/pull/822 > >> > >> Ant > >> > > > > > -- Samuel Marks http://linkedin.com/in/samuelmarks
