27 ms·

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 thos

by sivers 13y ago

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.

the_mitsuhiko 13y ago
> `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.
- saym 13y ago
  I feel like it's a valid concern for someone to want to know what's on their system. Sure virtualenv is a great solution, and I'm sure the person you're responding to knows about it. But there is a place for skepticism in required dependencies, and perhaps the OP parses Perl better than Python.
- HNLogInShit 13y ago
  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.
- garnaat 13y ago
  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.
- jamespo 13y ago
  If you want to use RPM packaging those 26 dependencies will be rather painful. There are pros and cons to both sides.
jrochkind1 13y ago
In a pre pip/rubygem auto-installer world, this would have been one package that had the 26 dependencies embedded as modules inside it. You wouldn't have known they were unless you looked at the source code. You also wouldn't be able to update them independently, you'd get updates when a new release of the original thing was available that included embedded updates. Would this make you feel more like you knew what was installed on your system? Would you have felt the need to look at the source code, including the source code for any embedded dependencies, in, say, a 'vendor' or 'lib/dist' directory or something? What are the plusses and minuses of each approach? There are some plusses and some minuses either way. After considering them, do you still have a problem with the 'new way' of doing things, where a program might install along with explicit dependencies via pip (or rubygems in ruby) separated out in a different place in the file system, vs. embedded/bundled dependencies?

by sivers 13y ago

the_mitsuhiko 13y ago

> `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.

saym 13y ago
I feel like it's a valid concern for someone to want to know what's on their system. Sure virtualenv is a great solution, and I'm sure the person you're responding to knows about it. But there is a place for skepticism in required dependencies, and perhaps the OP parses Perl better than Python.
HNLogInShit 13y ago
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.
garnaat 13y ago
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.
jamespo 13y ago
If you want to use RPM packaging those 26 dependencies will be rather painful. There are pros and cons to both sides.

jrochkind1 13y ago

In a pre pip/rubygem auto-installer world, this would have been one package that had the 26 dependencies embedded as modules inside it. You wouldn't have known they were unless you looked at the source code. You also wouldn't be able to update them independently, you'd get updates when a new release of the original thing was available that included embedded updates. Would this make you feel more like you knew what was installed on your system? Would you have felt the need to look at the source code, including the source code for any embedded dependencies, in, say, a 'vendor' or 'lib/dist' directory or something? What are the plusses and minuses of each approach? There are some plusses and some minuses either way. After considering them, do you still have a problem with the 'new way' of doing things, where a program might install along with explicit dependencies via pip (or rubygems in ruby) separated out in a different place in the file system, vs. embedded/bundled dependencies?