On 17/03/2011 22:49, Jason E. Aten wrote:
> Somewhat tongue in cheek, we could call it dabal.
>
> As in, "get on dabal!"  :-)

If D gets accepted for Google Summer of Code, I think this would be a great idea for a project and I would be interested in implementing it as a student. Although, it does seem overly ambitious so maybe only some of this could be for the gsoc (and if I do this It'd be great to carry on working on it anyway).

What does everybody think about this? Should I draw up a proposal of some kind?

Chris

On 03/18/2011 06:04 PM, Chris Manning wrote:
> On 17/03/2011 22:49, Jason E. Aten wrote:
>> Somewhat tongue in cheek, we could call it dabal.
>>
>> As in, "get on dabal!" :-)
>
> If D gets accepted for Google Summer of Code, I think this would be a great
> idea for a project and I would be interested in implementing it as a student.
> Although, it does seem overly ambitious so maybe only some of this could be for
> the gsoc (and if I do this It'd be great to carry on working on it anyway).

+++

> What does everybody think about this? Should I draw up a proposal of some kind?

Dunno how it's supposed to be done...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Fri, 2011-03-18 at 10:41 -0400, Jesse Phillips wrote:
[ . . . ]
> Otherwise I would be for using the native packaging system, but it isn't easy for the contributor, the maintainer of the server, or the one building a system that works with all of them.

The problem is that the system administrator wants to use just the OS packaging system to make things easy for them to maintain the system. The user wants to be able to install stuff easily and may not have sufficient permissions to actually use the OS packaging system.  Sys admins don't want to have to learn N packages to deal with N languages, the use probably only works in a couple of languages and so doesn't care if they have to learn two different packagin systems so as to get stuff done.

This is not an easy issue.  I just find the knee-jerk reaction of "we have this new language therefore we must have a brand new (build system| packaging system|shell|implementation of every comms protocol|new user interface library|operating system)" leads to too many distractions from getting stuff done using the good tools that are already available.

I still think basing a D packaging system on Git to be the best direction.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Fri, 18 Mar 2011 18:42:36 +0000, Russel Winder wrote:
> I still think basing a D packaging system on Git to be the best direction.

Basing package distribution on Git or hg could be a big win, and would help establish a customary case for revision control which is one of the things that make cabal work so well (they use darcs for everything). I find these revision control systems ver fast and very easy to use.

The other thing that cabal standardizes is the make/build system.  I've updated bud/build to compile under D2, with all the latest patches, but I'm far from convinced that it should be a make system of choice.  I have limited experience here, but a "D aware" build system would seem to be highly preferable.

What are people's experiences with the various options for build systems with D?

To me, I like the design goals of Andreas Fredriksson's Tundra build system (he wants speed of incremental of builds prioritized over all else, which means utilizing multicores for builds as much as possible to get the quickest build), because fast builds are critical for game development, where D is very attractive.  Game projects compile tens of thousands of files. Tundra is GPL and it would be easy to extend to support D.

http://voodoo-slide.blogspot.com/2010/08/tundra-my-build-system.html https://github.com/deplinenoise/tundra https://github.com/deplinenoise/tundra/downloads

On 18/03/11 09.52, Russel Winder wrote:
> On Thu, 2011-03-17 at 20:44 +0000, Jason E. Aten wrote:
>> Please correct me if I'm wrong, but I observe that there doesn't appear
>> to be a package management system / standard repository for D libraries.
>> Or is there?
>>
>> I'm talking about something as easy to use as R's CRAN,
>>> install.packages("rforest")
>>
>> or cpan for perl, ctan for latex, dpgk/apt for debian, cabal for Haskell/
>> Hackage, etc.
>
> Note that every language-specific package manager conflicts directly
> with every operating system package manager.  Thus RubyGems, CPAN,
> Cabal, Maven, Go, etc. conflicts with the package management of Debian,
> Fedora, SUSE, FreeBSD, MacPorts, etc. leading to pain.  Pain leads to
> anger.  Anger leads to hate.  Hate leads to suffering.
>
>> If there's not a commonly utilized one currently, perhaps we could
>> "borrow" cabal, with a trivial port.  cabal is Haskell's package manager.
>>
>> Not only does having a standard package install system facilitate
>> adoption, it greatly facilitates code sharing and library maturation.
>
> At the expense of easy system administration.
>
> I guess the only up side of language specific package management is that
> it enables people whose operating systems are not package structured to
> do things sensibly.  Alternatively Windows users could switch to a
> sensible operating system ;-)

The worst thing is that dependency tracking is lost when the sysadm uses another package system e.g CPAN. If the dependency problem could be solved in an elegant way I think a sysadm would be ok with it.

> Given that D has chosen to switch to Git for version control, doesn't
> this imply that package management transported over DVCS is the way
> forward.  Go has certainly taken this route.  It prioritizes Mercurial
> but supports Bazaar and Git as well.

I like how Go uses git but there is room for improvements.

No reason the limit the protocols as long a it can be resonable supported. It is just a place to download from. Put http, ftp, samba, torrent, dropbox, facebook... in there as well :)

DSSS was actually a nice solution. Maybe it could be brought up to date and improved to fit the needs?


/Jonas

On 2011-03-17 22:47, Lutger Blijdestijn wrote:
> Jason E. Aten wrote:
>
>> Please correct me if I'm wrong, but I observe that there doesn't appear
>> to be a package management system / standard repository for D libraries.
>> Or is there?
>>
>> I'm talking about something as easy to use as R's CRAN,
>>> install.packages("rforest")
>>
>> or cpan for perl, ctan for latex, dpgk/apt for debian, cabal for Haskell/
>> Hackage, etc.
>>
>> If there's not a commonly utilized one currently, perhaps we could
>> "borrow" cabal, with a trivial port.  cabal is Haskell's package manager.
>>
>> Not only does having a standard package install system facilitate
>> adoption, it greatly facilitates code sharing and library maturation.
>
> There used to be one called dsss (d shared software system). It was widely
> used, I think some D1 libraries still use it but it hasn't been maintained
> for years.

It's still working fine for building and installing local libraries with D1, it's the net capabilities that doesn't work.

-- 
/Jacob Carlborg

On 2011-03-17 23:44, Jason E. Aten wrote:
>>> On 3/17/11 4:00 PM, Tomek Sowiński wrote:
>>> Yes, we need it badly.
>>> I think it's a good moment to start a discussion. First off, what
>>> exactly do we want from a package management system?
>
>> On Thu, 17 Mar 2011 16:28:37 -0500, Andrei Alexandrescu wrote:
>> Yah, would be great. It would be awesome if an expert in e.g. apt would
>> join D and create the design of a package management system.
>
> I would invite interested parties to review the cabal/cabal-install/
> Hackage system documentation. It is described here.
>
> http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_program
>
> Haskell has over 2000 contributed user libraries--largely because they
> have such a nice, easy to use, and well documented package system.
>
> Rather than expend much effort, in the tradition of lazy evaluation and
> getting 80/20 the way there, I would prefer to just do a clone of an
> already successful system such as cabal (or ?) and then take feedback to
> based on actual usage with D.
>
> Thoughts?  Comments welcome.
>
> Jason

I would clone RubyGems.

-- 
/Jacob Carlborg

On 2011-03-18 09:52, Russel Winder wrote:
> On Thu, 2011-03-17 at 20:44 +0000, Jason E. Aten wrote:
>> Please correct me if I'm wrong, but I observe that there doesn't appear
>> to be a package management system / standard repository for D libraries.
>> Or is there?
>>
>> I'm talking about something as easy to use as R's CRAN,
>>> install.packages("rforest")
>>
>> or cpan for perl, ctan for latex, dpgk/apt for debian, cabal for Haskell/
>> Hackage, etc.
>
> Note that every language-specific package manager conflicts directly
> with every operating system package manager.  Thus RubyGems, CPAN,
> Cabal, Maven, Go, etc. conflicts with the package management of Debian,
> Fedora, SUSE, FreeBSD, MacPorts, etc. leading to pain.  Pain leads to
> anger.  Anger leads to hate.  Hate leads to suffering.
>
>> If there's not a commonly utilized one currently, perhaps we could
>> "borrow" cabal, with a trivial port.  cabal is Haskell's package manager.
>>
>> Not only does having a standard package install system facilitate
>> adoption, it greatly facilitates code sharing and library maturation.
>
> At the expense of easy system administration.
>
> I guess the only up side of language specific package management is that
> it enables people whose operating systems are not package structured to
> do things sensibly.  Alternatively Windows users could switch to a
> sensible operating system ;-)

Another advantage that as least RubyGems has, in the combination with RVM, is that you can have different gems/packages installed for different Ruby compilers.

> Given that D has chosen to switch to Git for version control, doesn't
> this imply that package management transported over DVCS is the way
> forward.  Go has certainly taken this route.  It prioritizes Mercurial
> but supports Bazaar and Git as well.
>
>


-- 
/Jacob Carlborg

On 2011-03-18 22:20, Jason E. Aten wrote:
> On Fri, 18 Mar 2011 18:42:36 +0000, Russel Winder wrote:
>> I still think basing a D packaging system on Git to be the best
>> direction.
>
> Basing package distribution on Git or hg could be a big win, and would
> help establish a customary case for revision control which is one of the
> things that make cabal work so well (they use darcs for everything). I
> find these revision control systems ver fast and very easy to use.
>
> The other thing that cabal standardizes is the make/build system.  I've
> updated bud/build to compile under D2, with all the latest patches, but
> I'm far from convinced that it should be a make system of choice.  I have
> limited experience here, but a "D aware" build system would seem to be
> highly preferable.
>
> What are people's experiences with the various options for build systems
> with D?

It's not very easy to make an incremental build system for D because of several reasons. Some are due to how the language works and some are due to how DMD works:

* DMD doesn't output all data in all the object files - This can perhaps be solved by compiling with the -lib switch

* When you change one D file you need to recompile ALL files that depend on the changed file. To compare with C/C++ which has source and header files you only need to recompile the source file if you change it

* DMD doesn't keep the fully qualified module name when naming object files resulting in foo.bar will conflict with bar.bar. Issue 3541.

> To me, I like the design goals of Andreas Fredriksson's Tundra build
> system (he wants speed of incremental of builds prioritized over all
> else, which means utilizing multicores for builds as much as possible to
> get the quickest build), because fast builds are critical for game
> development, where D is very attractive.  Game projects compile tens of
> thousands of files. Tundra is GPL and it would be easy to extend to
> support D.
>
> http://voodoo-slide.blogspot.com/2010/08/tundra-my-build-system.html
> https://github.com/deplinenoise/tundra
> https://github.com/deplinenoise/tundra/downloads


-- 
/Jacob Carlborg

Russel Winder wrote:

> On Thu, 2011-03-17 at 20:44 +0000, Jason E. Aten wrote:
>> Please correct me if I'm wrong, but I observe that there doesn't appear to be a package management system / standard repository for D libraries. Or is there?
>> 
>> I'm talking about something as easy to use as R's CRAN,
>> > install.packages("rforest")
>> 
>> or cpan for perl, ctan for latex, dpgk/apt for debian, cabal for Haskell/ Hackage, etc.
> 
> Note that every language-specific package manager conflicts directly with every operating system package manager.  Thus RubyGems, CPAN, Cabal, Maven, Go, etc. conflicts with the package management of Debian, Fedora, SUSE, FreeBSD, MacPorts, etc. leading to pain.  Pain leads to anger.  Anger leads to hate.  Hate leads to suffering.
> 
>> If there's not a commonly utilized one currently, perhaps we could "borrow" cabal, with a trivial port.  cabal is Haskell's package manager.
>> 
>> Not only does having a standard package install system facilitate adoption, it greatly facilitates code sharing and library maturation.
> 
> At the expense of easy system administration.

Not necessarily, fedora has rpm packages of gems for example.

> I guess the only up side of language specific package management is that it enables people whose operating systems are not package structured to do things sensibly.  Alternatively Windows users could switch to a sensible operating system ;-)
> 

It's also often easier to package libraries with system specifically designed to do so for a particular language. That, combined with a common repository, usually results in a much wider selection of apis than a native distribution offers.