Hmm, actually in my code I have this line:
self.provider_cls = (lambda driver: driver(
region=self.provider_dict['provider']['region'],
**self.provider_dict['auth']
))(get_driver(getattr(Provider, self.provider_dict['provider']['name'])))
And I also use DRIVERS. So these imports:
from libcloud.compute.providers import get_driver, DRIVERS
from libcloud.compute.types import Provider
Samuel Marks
http://linkedin.com/in/samuelmarks
On Tue, Jul 5, 2016 at 8:26 AM, Anthony Shaw <[email protected]>
wrote:
> 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
>
>
>
>
