Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The New AWS Command-Line Interface

aws.typepad.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: The New AWS Command-Line Interface

#51

Post by HNLogInShit »

the_mitsuhiko wrote: post #41
sivers wrote: post #35

Earlier quoted context omitted.

I just like knowing what's on my system. `pip install awscli` just installed 26 other modules besides awscli. Now I feel a little obliged to go check out those 26, as well, to see what they are. I agree about not re-inventing the wheel. But the amount of stuff installed is definitely a considering factor when choosing between two seemingly identical scripts.

> `pip install awscli` just installed 26 other modules besides awscli. Now I feel a little obliged to go check out those 26, as well, to see what they are. So? Use a virtualenv and stop worrying. These 26 dependencies will be separately updated and maintained, who knows what warts are sitting in the monolithic perl scripts.

Yeah, let's add work for the customer so Amazon can continue shipping bloated SDKs and clients.

Meanwhile, their documentation sucks, and their Web-based interface doesn't even offer a way to delete a file from S3. Seriously: You can browse files in a giant list, but there's no way to find one and delete it. That's pathetic.

Re: The New AWS Command-Line Interface

#52

Post by aidos »

dencold wrote: post #37

Long-time user of boto[1] here. It has been the go to library to hook your python code into AWS and has a fairly active following on github[2]. One API point that I've found lacking in boto is a "sync" command for S3. Take a source directory and a target bucket and push up the differences ala rsync, that's the dream. Boto gives you a the ability to push/get S3 resources, but I've had to write my own sync logic. So, t…

That is good news. I too wrote a sync layer to sit above boto for a previous project. My use-case is a little different in that I sync from S3 to RackspaceCloud as a backup. I just use file name (object name) as the key because I know that files never change (though are added and removed). I create a complete object listing of S3 and a complete object listing of CF, diff and then sync.

One disappointing issue is that the listing process on CF is a magnitude faster than S3.

    CF: real	2m7.628s
    S3: real	14m15.680s
Keep in mind that this is all being run from an EC2 box, so really, S3 should win hands down.

Re: The New AWS Command-Line Interface

#53

Post by garnaat »

the_mitsuhiko wrote: post #41
sivers wrote: post #35

Earlier quoted context omitted.

I just like knowing what's on my system. `pip install awscli` just installed 26 other modules besides awscli. Now I feel a little obliged to go check out those 26, as well, to see what they are. I agree about not re-inventing the wheel. But the amount of stuff installed is definitely a considering factor when choosing between two seemingly identical scripts.

> `pip install awscli` just installed 26 other modules besides awscli. Now I feel a little obliged to go check out those 26, as well, to see what they are. So? Use a virtualenv and stop worrying. These 26 dependencies will be separately updated and maintained, who knows what warts are sitting in the monolithic perl scripts.

With boto, I battled for years trying to avoid any dependencies. But that has a lot of negative side effects, too. One of the great things about Python is the amazing variety and quality of libraries available. We decided to embrace that with AWS CLI. We have 10 direct dependencies. Four of those are our own packages that we decided to split to allow maximum reuse. Then there are fundamental things like requests, six, docutils. The rest are things that, we think, improve the experience. Virtualenv is an awesome way to manage this. I highly recommend it.

Re: The New AWS Command-Line Interface

#56

Post by tekacs »

benologist wrote: post #26
kondro wrote: post #9

Whilst this is a much better solution that the existing slow tools Amazon provided, I don't understand why this is being reported as if command-line tools for AWS are a new thing. Command-line tools used to be your only option for managing AWS and Amazon always create their API and shell tools before the Console.

It's probably 'news' because AWS is at risk of losing mindshare on HN as more competitors target this community - Rackspace just started giving everyone free credit, Linode gave everyone big free upgrades, DigitalOcean are just killing it, and then there's Docker etc threatening to reduce them all to interchangeable dumb infrastructure.

Given the number of major, established services running on AWS that go down perfectly in sync every time there's an AWS outage, it seems unlikely that the service is likely to fall out of most of HN's mindset for quite some time to come. ;)

Might lose some favour for new projects, though.

Re: The New AWS Command-Line Interface

#57

Post by rlpb »

hendry wrote: post #44

aws-cli/0.16.0 gripes: • slow • crap ton of dependencies, making it a pain to install on Arch https://aur.archlinux.org/packages/aws-cli/ Hint: static build ffs • broken help. `aws s3 help` instead of `aws help s3` which is more natural to git users • no glacier support • no s3 progress for downloads or uploads • many jarring UX issues https://github.com/aws/aws-cli/issues/305 https://github.com/aws/aws-cli/issues/30…

> • no glacier support

I'm the author of glacier-cli (github.com/basak/glacier-cli). I'd be happy to see it move into aws-cli. If anyone wants to do this, please get in touch to coordinate.

Re: The New AWS Command-Line Interface

#58

Post by jamespo »

the_mitsuhiko wrote: post #41
sivers wrote: post #35

Earlier quoted context omitted.

I just like knowing what's on my system. `pip install awscli` just installed 26 other modules besides awscli. Now I feel a little obliged to go check out those 26, as well, to see what they are. I agree about not re-inventing the wheel. But the amount of stuff installed is definitely a considering factor when choosing between two seemingly identical scripts.

> `pip install awscli` just installed 26 other modules besides awscli. Now I feel a little obliged to go check out those 26, as well, to see what they are. So? Use a virtualenv and stop worrying. These 26 dependencies will be separately updated and maintained, who knows what warts are sitting in the monolithic perl scripts.

If you want to use RPM packaging those 26 dependencies will be rather painful.

There are pros and cons to both sides.

Post reply on HN