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 li
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
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 Mond
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 wrote:
> I personally don't see any value in that approach over the existing one,
> but I won't block it :)
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
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.comput
