On 2011-07-20 10:36, Ulrik Mikaelsson wrote:
In my experience with gem and easy_install, it's not really practical for the end-user. After several attempts, I always ran into problems. Especially library-bindings in the language-specific package-manager tends to conflict with what library is installed in the system, causing problems. In all the cases I ended up biting the bullet and create a OS-package for the Python/Ruby packages we're using in production. I've later learned the experience is shared with others, I know one company who even went back to .NET due to too much hassle with Ruby On Rails deployments (gem), and I suppose distribution-developers wouldn't put as much effort into packaging all the Python and Ruby-packages they do if not others had seen problems with per-language packagers.
I never had this problem with Ruby or Rails. I find it very hard to belive that the only reason they switch back to .NET was problems with the package manager. I mean Ruby on Rails is the easiest platform I've used, just list the packages you want in a file and run "bundle" and everything is installed.
So what are you suggesting, that we don't have a package manager for D?
Especially, if D is to gain traction and attract developers, getting proof-of-concept applications out in the respective "app store" of the target OS:es is quite important, which requires working with the native packaging format.
Linux and FreeBSD is the only platforms that have a native package manager. Mac OS X has macports and homebrew, none of which are installed by default. Windows doesn't have any package manager, as far as I know.
So you suggest that I should create, something like, six packages for one library just to support all platforms and package mangers. And then it won't even support Windows. That would probably also be in 6 different "languages" for the package scripts.
-- /Jacob Carlborg
