View mode: basic / threaded / horizontal-split · Log in · Help
March 18, 2011
Re: Dream package management system (Was: a cabal for D ?)
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
March 18, 2011
Re: Dream package management system (Was: a cabal for D ?)
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
March 18, 2011
Re: a cabal for D ?
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
March 18, 2011
Re: a cabal for D ?
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
March 18, 2011
Re: a cabal for D ?
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
March 19, 2011
Re: a cabal for D ?
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
March 19, 2011
Re: Dream package management system (Was: a cabal for D ?)
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
March 19, 2011
Re: a cabal for D ?
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
March 19, 2011
Re: a cabal for D ?
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
March 19, 2011
Re: a cabal for D ?
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.
1 2 3 4
Top | Discussion index | About this forum | D home