July 19, 2011
"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
"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
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
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
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
> 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
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
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
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
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