Whatever is done we should not break the API like that, as this would instantly break every single application out there that uses goamz's s3 package.
A better way to handle that is to panic if the S3 endpoint is unset and s3.New is called on such a region, and document that this will be the case on that function. That's generally not a good idea, but in practice this is already what happens today: if a region without the S3 endpoint is used, it will eventually panic in a more subtle way, so we're just making the behavior explicit and clear. Then, when we're forced to break the API for a different reason, we can take the chance to improve that API, and at that time we should change the import path so that existent applications are unaffected by these modifications. gustavo @ http://niemeyer.net On May 8, 2014 11:07 AM, "Benoît Canet" <benoit.ca...@irqsave.net> wrote: > > Hi, > > I am adding the Outscale provider regions declarations in goamz/aws/aws.py > Regions variable. > > It turn that a bunch of endpoint are not definied for the outscale cloud > which only implements the EC2 endpoint. > > It set these field to "" to indicated they are not used. > > Now I am trying to find a way to make sure that the S3 api of goamz will > work > fine with this. > > Is it correct to change goamz S2 new constructor to return nill, false if > the > region has no S3 endpoint and *S3, true if the region has an endpoint. > > It does imply that callers need to change their way of doing. > > Of course I would modify the juju-core code to support this. > > What are your opinions ? > > Best regards > > Benoît > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
