Prototype buildsystem "Drake"

Jacob Carlborg doob at me.com
Wed Jul 20 03:30:58 PDT 2011


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


More information about the Digitalmars-d mailing list