search

pachadotdev / analogsea

Digital Ocean R client
https://pacha.dev/analogsea/
Apache License 2.0
155 stars 24 forks source link

Cannot change "spaces_base" variable, spaces different region support #163

Closed LogIN- closed 5 years ago

LogIN- commented 6 years ago

Since spaces can be located in many regions and not only in nyc3 as defined here: https://github.com/sckott/analogsea/blob/8f1f5698df5a58f42d3e22d6a03fc52082de595e/R/spaces.R#L1 we need option to change this spaces_base variable / URL.

As I can currently see that is not possible, please tell me if I am wrong. Maybe we can also use some env variable like DO_SPACES_BASE to specify endpoint?

amoeba commented 6 years ago

Hey @LogIN-, thanks for the report.

Your assessment that the Spaces region cannot be changed looks correct to me. There used to be only one region available but Digital Ocean has since expanded Spaces across more of their service regions so it totally makes sense to make this configurable.

An env var to configure this, such as DO_SPACES_BASE, makes sense and would work. Looking at the API docs, I think perhaps DO_SPACES_REGION (e.g., nyc3, sfo1, etc) might match the DO API and lingo better. Can you think of any reason we might let the user specify a full Spaces API base URL (e.g., https://nyc3.digitaloceanspaces.com) over just the name (e.g., nyc3)?

LogIN- commented 6 years ago

Hi @amoeba, I think that currently according to DO API only specifying region would be enough.

But since this would basically behave as a wrapper variable to base_url parameter of aws.s3 package, maybe it would be the best to follow their input structure and that full Spaces URL needs to be defined in such ENV parameter.

They define this base_url parm as:

A character string specifying the base URL for the request.

I think that this is called AWS_S3_ENDPOINT on their side, so maybe DO_SPACES_ENDPOINT would also fit in the name schematics.

amoeba commented 6 years ago

Ah, yeah! So the full URL for an aws.s3 request would be AWS_S3_REGION + AWS_S3_ENDPOINT (e.g., us-east-1 + s3.amazonaws.com) so the Digital Ocean Spaces equivalent would be DO_SPACES_REGION + DO_SPACES_ENDPOINT (e.g., nyc3 + digitaloceanspaces.com). So to resolve this issue, we'd create support for two new env vars, each with sensible defaults. Does that sound like what you were thinking?

LogIN- commented 6 years ago

Hi @amoeba , That sounds great, than each case is covered regarding endpoints. I think that would solve most if not all of use cases regarding that.

amoeba commented 6 years ago

👍 I'm still working on some fixes for some other Spaces issues but I think I'll PR this along with those fixes so when Spaces are all working nicely, setting a non-default Spaces region will work too. Thanks for the idea!

amoeba commented 6 years ago

Hey @LogIN- this is working in #165 as far as I can tell. Once #165 is merged, you'll be able to set DO_SPACES_REGION (along with your access token and secret) and use any Spaces region DO provides.

Would you be willing to kick the tires to let me know if you have any issues by either building #165 or waiting until it's merged?

sckott commented 5 years ago

@amoeba can we close this? given no response from issue opener