On 04.12.2019 16:49, Carl A. Adams wrote: >>> I had added register_backend to s3_boto3_backend, keeping it self contained >>> and following the convention in the ssh backends. The backends do not seem >>> entirely consistent on this point, with ssh having the two flavors entirely >>> self contained, and boto and cf separating the implementation from the >>> registration. >> >> they are not. they were implemented before we switched to the prefixed scheme >> approach. >> >>> The primary advantage of separating the registration from the >>> implementation of the backend appears to be selecting backend implementation >>> by CLI option, which I was told was now discouraged. FWIW, I'd say "boto" >>> is not correct for this new backend anyway, since boto3 is really a >> completely >>> different library, which can coexist with boto in a project. If we do want >> to >>> register the new backend along side the older s3 backends in a common >>> location, I'd suggest something named "s3" over "boto", reflecting the >> backup >>> server type rather than the particular implementation. >> >> not sure what you mean here. >> > > > Two things: 1) registering in botobackend.py as requested seems to conflict > with the request to follow the newer prefix conventions (where the example of > SSH registers each in their own ssh_<backend>.py). I followed the SSH > convention when I renamed it the new backend s3_boto3_backend.py. 2) If i > do register the all the s3 backends in a common py file, calling that py file > "boto" isn't right for the new one - boto and boto3 are completely separate. > If that's the registration convention you want to follow, I'd suggest > "s3backend.py", which would collect the two older "boto" backends, and the > newer "boto3" backend. But, I don't see the point of breaking the > encapsulation of "everything in the new backend is in the new backend file, > including registration", which is what ssh and most non-prefixed backends do. >
no worries. i think we are still misunderstanding each other. doesn't matter though! just leave the botobackend as is and i'll do the changes when i find the time :) >> >>> I had already added boto3+s3 to the url scheme section and an extended >>> explanation under "A note on amazon s3" in my latest updates, so I'm not >> sure >>> what else you are asking for. Is the bzr merge request not up to date? >> >> in the man page there is a section 'Url Format' that explains the url formats >> per backend (meaning protocol) currently it looks like >> >> --> >> >> URL Format >> >> Duplicity uses the URL format (as standard as possible) to define data >> locations. The generic format for a URL is: >> scheme://[user[:password]@]host[:port]/[/]path >> It is not .... >> >> [SNIP] >> >> S3 storage (Amazon) >> >> s3://host[:port]/bucket_name[/prefix] >> s3+http://bucket_name[/prefix] >> See also A NOTE ON EUROPEAN S3 BUCKETS >> > > > I think you are looking at an old diff. I updated that when I switched from > --s3-use-boto3 to boto3+s3. Did I need to do more than push my change to my > branch to update the merge request? (First project that I've used bzr in...) > > > ok, i see it now. fine by me then!.. ede/duply.net -- https://code.launchpad.net/~carlalex/duplicity/duplicity/+merge/376206 Your team duplicity-team is subscribed to branch lp:duplicity. _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
