There are 3k commits on boto3 (90+ contributors) vs. ~200 on aws-elixir. Work on boto3 was started in 2014. That was right about the time elixir hit 1.0, but 6 years into python3. What you see for boto takes work and in open source this also means time. We can sure get to a similar state, but one can’t expect it to be there from “day 1”. Therefore I can just support @josevalim. If you see deficits try to open issues or even PRs (and I’ve done so myself a lot of times).
LostKobrakai
LostKobrakai
You don’t need write access to the hex package. Opening PRs on github can be done by anyone. If you’re not sure how to interact with the module generation you can ask the maintainers. Also ex_doc does have means of including plain markdown files (the guides you see in popular libraries like ecto or phoenix) without them needing to be part of a module.
Given it’s a wrapper around the official aws apis they’ll likely work quite similar as other languages libraries / the http api aws has docs for. It might not help for this library, but often you can look also at the test-suite how things work.
Edit:
Even if you don’t know things you can ask in issues. E.g. see this one I improved the docs on after having to ask first about what things actually are: Documentation of `Migration.execute/1` · Issue #257 · elixir-ecto/ecto_sql · GitHub
0
cnck1387
Right but for the docs to be updated would require someone pushing a new package version to Hex?
Also the top of every source code file says not to touch it because it’s machine generated, example:
# WARNING: DO NOT EDIT, AUTO-GENERATED CODE!
# See https://github.com/aws-beam/aws-codegen for more details.
If the docs are generated by code comments but the files that contain the code are read-only, I can’t think of a way to open a PR on that. The changes would get lost.
This is what I normally do, but yeah aws-elixir has no tests. At least none that show how to use the functions that this library exposes.
In the end this leaves us with no to limited docs, no test suite and no way to update the docs due to things being auto-generated. How would we proceed to improve this given the above constraints? It sounds like an expert would need to crawl through the popular AWS services and write custom guides / docs and then publish them to somewhere outside of the code repo?
But even that isn’t a great experience because it could hard to find and could very easily become outdated vs what’s available in the library.
0
LostKobrakai
And as always: try things out. It’s not like the parameters are awefully hard to guess and as mentioned the functions align with common aws api, so “what the functions do” should be not to hard to find out. It’s more a matter of what inputs/outputs are. If you don’t want to rent an actual S3 bucket you can look at the tests for depot_s3 I linked previously. It has integration with a local minio instance.
Edit:
And I want to add: Things need not be correct/complete/perfect on the first shot at it. A good maintainer will help you work through improvements to make them mergeable.
2
cnck1387
Thanks.
Hopefully in time we can pick a semi-blessed solution that ends up having code, tests and documentation in 1 spot so us regular devs can get up and going without having to solve a mystery case to see how to use the library :D.
With that semi-blessed solution maybe other libs that use AWS could start using it too. Right now Waffle is still using exAws as a dependency.
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
This is starting to feel a bit like a different topic. However it’s worth noting that ExAws’s approach to documentation has always been “use the official AWS docs”. ExAws is a relatively thin wrapper around the underlying API calls. Mandatory parameters are function args, options are options.
2
christhekeele
darnahsan
frumos
Hello Elixir community.
In my prototyping I am using ExAWS and it works really good for my current needs: S3, STS, SQS but now I see lack for other APIs like autoscaling. I tried ExAWS “custom request” but did not succeed.
So just today I check this library aws-elixir and pool the latest release 0.6.0
When I check AWS.AutoScaling.xyz API I see much less functions present comparing to what is defined on Go side, namely: aws-sdk-go/models/apis/autoscaling/2011-01-01/api-2.json at main · aws/aws-sdk-go · GitHub
When I check head of git master branch I see it is in par with Go version, namely: https://github.com/aws-beam/aws-elixir/blob/master/lib/aws/auto_scaling.ex
However when I pull version {:aws, "~> 0.6.0"} in mix.exs it just brings limited subset of services and APIs (you can check it here: Releases · aws-beam/aws-elixir · GitHub).
Could you please help to figure out what is the issue? Why the latest version of 0.6.0 aws-elixir released with such limited (and it seems outdated) set of services/APIs?
Thank you.
PS:
I just updated my dependency to:
{:aws, git: "https://github.com/aws-beam/aws-elixir.git"}
and now I have e.g. AWS.AutoScaling.describe_account_limits which is not in v. 0.6 So the question is why this lib is not released with full set of API?
0
LostKobrakai
That you need to ask the maintainers. Maybe they want to do some more testing or some more features, … You could always ask if they can release a new version with those missing services.
0