View mode: basic / threaded / horizontal-split · Log in · Help
July 19, 2011
Re: Prototype buildsystem "Drake"
"Russel Winder" <russel@russel.org.uk> wrote in message 
news:mailman.1770.1311086829.14074.digitalmars-d@puremagic.com...
>There are some potentially tricky issues here.  Ruby gets round it by
>having a language specific package and build system which therefore
>causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive
>headaches.  Haskell/Cabal, Python/Eggs, etc.  The conflict between
>language packaging and platform packaging is central.  Having a D
>language packaging system that was in some way harmonious with Apt/Deb,
>Yum/RPM, Ports, etc. would make a lot of people very happy.  Indirectly
>it would make traction a whole lot easier.  As evidence I present Java,
>Ruby, Python, Haskell, etc.

What would be needed for a D package manager to be "harmonious with" such 
systems? I don't know anything about the issues OS packagers face regarding 
language-oriented package systems.
July 19, 2011
Re: Prototype buildsystem "Drake"
"Nick Sabalausky" <a@a.a> wrote in message 
news:ivviur$2ks8$1@digitalmars.com...
> "Jacob Carlborg" <doob@me.com> wrote in message 
> news:ivp1gd$500$2@digitalmars.com...
>>
>> Ok, have you thought about how this will look (in code) and behave?
>>
>
> Not extensively, but here's what I have in mind so far. In an early 
> initial version of Drake, it would be like this:
>
>    task("configure", "drake.conf");
>
>    file("drake.conf",
>        (Target t)
>        {
>            // Do all configuring here and save to drake.conf
>        }
>    );
>

Actually, I think that might have to be more like:

   // This part added:
   if(DrakeArgs.target == "configure")
       remove("drake.conf");

   task("configure", "drake.conf");

   file("drake.conf",
       (Target t)
       {
           // Do all configuring here and save to drake.conf
       }
   );

Otherwise "drake configure" wouldn't re-generate the configuration unless 
drake.conf was manually deleted first. Or, maybe there should just be a 
"--force" option (also accesible from code? on a per-task basis?) to skip 
the dependency checks and forcefully rebuild.

Oh, and maybe the configuration fle should just be named "configure":

   // Use --force to re-configure
   file("configure",
       (Target t)
       {
           // Do all configuring here and save to 'configure'
       }
   );

Pardon the public brainstorming...
July 20, 2011
Re: Prototype buildsystem "Drake"
2011/7/19 Jacob Carlborg <doob@me.com>:
> On 2011-07-19 16:46, Russel Winder wrote:
>>
>> There is clearly a string coupling between configuration and package
>> management.   Autoconf, Waf and SCons have to be portable across package
>> management since they are not dedicated to one scheme -- springing up as
>> they did from before package management as standard.
>
> Ok.
>
>> There are some potentially tricky issues here.  Ruby gets round it by
>> having a language specific package and build system which therefore
>> causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive
>> headaches.  Haskell/Cabal, Python/Eggs, etc.  The conflict between
>> language packaging and platform packaging is central.  Having a D
>> language packaging system that was in some way harmonious with Apt/Deb,
>> Yum/RPM, Ports, etc. would make a lot of people very happy.  Indirectly
>> it would make traction a whole lot easier.  As evidence I present Java,
>> Ruby, Python, Haskell, etc.
>
> The whole point of having a D package manager is so I don't have to create
> packages for all these system specific package managers.

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.

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.
July 20, 2011
Re: Prototype buildsystem "Drake"
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
July 20, 2011
Re: Prototype buildsystem "Drake"
On 7/20/11 10:36 AM, Ulrik Mikaelsson wrote:
> […]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), […]

Do you happen to known what issues they experienced in more detail? I'm 
curious because I personally found Rails deployment to be quite 
convenient, extending the Gemfile during development as needed, and then 
using Bundler (http://gembundler.com/) to ensure that the exact same 
versions of the dependencies are used when staging and deploying…

David
July 20, 2011
Re: Prototype buildsystem "Drake"
> So what are you suggesting, that we don't have a package manager for D?
I'm suggesting, I'm not likely to use it, and developing a D-specific
package manager should not accidentally exclude stand-alone building
of packages. As I said before, the build-system and packaging system
must be independent, but well integrated.

Quoting again from Russel Winder:
>> Having a D language packaging system that was in some way harmonious
>> with Apt/Deb, Yum/RPM, Ports, etc. would make a lot of people very happy.
>> Indirectly it would make traction a whole lot easier.
July 20, 2011
Re: Prototype buildsystem "Drake"
2011/7/20 David Nadlinger <see@klickverbot.at>:
> Do you happen to known what issues they experienced in more detail? I'm
> curious because I personally found Rails deployment to be quite convenient,
> extending the Gemfile during development as needed, and then using Bundler
> (http://gembundler.com/) to ensure that the exact same versions of the
> dependencies are used when staging and deploying…

I do not know exactly what their problems was. For me, it was mainly
conflicts between OS package manager and language-specific. I recall
curl-bindings, and MySQL binding causing a lot of problems, also I
recall some graphics library depending on GTK breaking spectacularly.
Perhaps it's more polished now, or perhaps I just had bad luck.
July 20, 2011
Re: Prototype buildsystem "Drake"
On 2011-07-20 12:50, David Nadlinger wrote:
> On 7/20/11 10:36 AM, Ulrik Mikaelsson wrote:
>> […]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), […]
>
> Do you happen to known what issues they experienced in more detail? I'm
> curious because I personally found Rails deployment to be quite
> convenient, extending the Gemfile during development as needed, and then
> using Bundler (http://gembundler.com/) to ensure that the exact same
> versions of the dependencies are used when staging and deploying…
>
> David

Exactly.

-- 
/Jacob Carlborg
July 20, 2011
Re: Prototype buildsystem "Drake"
On 2011-07-20 14:01, Ulrik Mikaelsson wrote:
>> So what are you suggesting, that we don't have a package manager for D?
> I'm suggesting, I'm not likely to use it, and developing a D-specific
> package manager should not accidentally exclude stand-alone building
> of packages. As I said before, the build-system and packaging system
> must be independent, but well integrated.

Of course, they should be independent. If I gave the impression of 
anything else, then that's a misunderstanding.

> Quoting again from Russel Winder:
>>> Having a D language packaging system that was in some way harmonious
>>> with Apt/Deb, Yum/RPM, Ports, etc. would make a lot of people very happy.
>>> Indirectly it would make traction a whole lot easier.


-- 
/Jacob Carlborg
July 20, 2011
Re: Prototype buildsystem "Drake"
On 2011-07-20 14:05, Ulrik Mikaelsson wrote:
> 2011/7/20 David Nadlinger<see@klickverbot.at>:
>> Do you happen to known what issues they experienced in more detail? I'm
>> curious because I personally found Rails deployment to be quite convenient,
>> extending the Gemfile during development as needed, and then using Bundler
>> (http://gembundler.com/) to ensure that the exact same versions of the
>> dependencies are used when staging and deploying…
>
> I do not know exactly what their problems was. For me, it was mainly
> conflicts between OS package manager and language-specific. I recall
> curl-bindings, and MySQL binding causing a lot of problems, also I
> recall some graphics library depending on GTK breaking spectacularly.
> Perhaps it's more polished now, or perhaps I just had bad luck.

What do you need curl for? Ruby has built-in support for bascially all 
curl's functionality. I haven't had any problems with using Ruby on 
Rails together with MySQL, on Linux.

-- 
/Jacob Carlborg
7 8 9 10 11 12
Top | Discussion index | About this forum | D home