Don't require :goth :json config to be present at compile time

[kommen]

I'm using this goth branch, which looks like it might be merged soonish: peburrows/goth#6

This doesn't require the :goth :json to be set at all, as it can be discovered.

However, right now if :json is not set, gcloudex doesn't compile:

==> gcloudex
Compiling 11 files (.ex)

== Compilation error on file lib/cloud_storage/client.ex ==
** (ArgumentError) argument error
    :erlang.iolist_to_binary(nil)
    lib/poison/parser.ex:35: Poison.Parser.parse/2
    lib/poison/parser.ex:50: Poison.Parser.parse!/2
    lib/poison.ex:83: Poison.decode!/2
    lib/gcloudex.ex:14: GCloudex.get_project_id/0
    lib/cloud_storage/client.ex:2: (module)

could not compile dependency :gcloudex, "mix compile" failed. You can recompile this dependency with "mix deps.compile gcloudex", update it with "mix deps.update gcloudex" or clean it with "mix deps.clean gcloudex"```

[kommen]

Just saw #2, which is about the same error, but I believe with goth supporting Google Cloud Platform metadata this should be reconsidered?

[sashaafm]

Hello @kommen, yes I saw that new goth branch yesterday.

I'll have to look into it. I'll try to take a look this weekend but I've got a ton of work until the following week so I can't promise anything.

[tazjin]

Hey,

let me know if you need any help / clarification. I'm fixing up the GCP metadata branch today to get it merged soon.

[tazjin]

I took a quick look at what's causing this. Fixing it in the function GCloudex.get_project_id is no problem, however it seems like the project is set up in a way that expects the project ID to be present at compile time due to the heavy macro usage.

I would suggest deferring those to runtime as this can cause other problems as well, e.g. identical artifacts being deployed to test and production environments.

To retrieve the project ID from Goth you should call Goth.Config.get(:project_id) instead of reading it from the configuration, once the Cloud Metadata pull request is merged that field will be populated from the metadata service as well.

[sashaafm]

Sorry I didn't look at this in the meantime. I'll take a look later today!

[sashaafm]

@tazjin could you please elaborate on deferring the project ID to be present at runtime? Do you mean in the module attribute in the Request and Impl modules?

Should this attribute be changed so that the function get_project_id is always called directly at runtime?

[tazjin]

Yes, exactly. The project ID may be different at runtime than at compile time

[sashaafm]

@tazjin I'll try to take care of this in the weekend or are you taking care of it in your fork?

[tazjin]

@sashaafm My fork now supports the same Goth.Config.get(:project_id) call when running via GCP metadata :)

[sashaafm]

Nice, will you make a PR? That's the only change right?

[tazjin]

Nope, there's work left to do - I'm wondering if you could explain what the idea with the macro utilisation is? If it was only for embedding the project ID I would remove that.

[sashaafm]

Yes just for embedding the project ID for easier access. I guess I should have thought a bit more about that design decision! Removing it from the module attribute to the function for runtime access shouldn't break anything I think.

[tazjin]

I guess stripping the whole .Impl thing and just putting the code directly in the modules is feasible then?

[sashaafm]

I think so. I was inspired by ExAws so I decided to follow their structure when I started building GCloudex. However, GCloudex don't really uses macros to the same extent as ExAws does.