I definitely think Python needs more opinionated guides so this is a win. I feel like Python does have enough "do it this way because". I think it has to do with the community just wanting to remain neutral. But you don't often get the best viewpoints when you stay in the middle.
yes, it's the same story when someone asks for an IDE - most guides are just a list of 20 IDEs without any commentary or opinion - despite the fact that some of them represent centuries of developer effort, while others are one guy's 6 month project. It took me a while to find the one I like (Wing IDE)
I agree. I feel like through Github the Ruby community forks, argues, and resolves problems faster than most Python projects do. Maybe I don't read enough mailing lists to see the angry posts, but maybe a bit more contention would be good to move things forward.
Part of the reason that Python has no canonical package management is that it is rooted in Linux, where the distro is perfectly capable of handling the task of package installation. It's an unfortunate artifact of shitty software management in Windows and OSX that we even have language-centric package management at all.
An installed package has and fulfills dependencies, no matter what language you use. Requiring each language to reimplement aptitude or emerge or macports or homebrew or asdf or rpm or gems in its own quirky way is bad for both end users and library developers.
Part of the reason that Python has no canonical package management is that it is rooted in Linux, where the distro is perfectly capable of handling the task of package installation. It's an unfortunate artifact of shitty software management in Windows and OSX that we even have language-centric package management at all.
Fantastic! Of course it's a bit of a bummer that as a dev I now have to handle setting up my python package so that it is acceptable to each of the major Linux distributions. And as a user, it does kind of suck, having to wait for said distributions to publish the package.
I see language-specific package managers as being complementary to system package management, not competition. A ruby gem to me is the equivalent of distributing a package written in C via a tarball/autotools, except it is much more user-friendly. As a developer, I can publish the gem myself, without having to fight with the distribution managers over the one true way to package up my software. In fact, that whole fight can be handled by the language package management system - so for example you only need rubygems to be compliant with Debian's rules, or Fedora's, and it will correctly install gems for your system, in much the same way that each distribution has its own implementation of pkg-config for autotools. Admittedly there have been many bitter battles when this has failed to be the case, but technically there is nothing stopping this from being a very effective, and flexible way of distributing software.
In ruby, I simply have to do gem install ABC and I have it regardless of distro.
I would accept your argument if python were giving library installation instructions in terms of distro-independent puppet configuration - but basically, you do have to build the abstraction somewhere.
Its not about technology - I think lisp has a bunch of different package managers and it is the same problem that ruby solves using gem (bad example?). Clojure has different package-management tools, but a single packaging format - that would have been a recipe for future disaster which hopefully has been averted (http://groups.google.com/group/clojure/browse_thread/thread/...)
I think this is the opposite of what happened. Python packaging works perfectly — operating systems and external packaging managers have no business managing python packages.
The Gem system has endured its own share of controversy, but it's certainly helped Ruby that there's been "one way to do it" when it comes to package management for so long.
