July 19, 2011 Re: Prototype buildsystem "Drake" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | "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" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | "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" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ulrik Mikaelsson | 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" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ulrik Mikaelsson | 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" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | > 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" | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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" | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ulrik Mikaelsson | 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" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ulrik Mikaelsson | 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 |
Copyright © 1999-2021 by the D Language Foundation