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.

Jason E. Aten napisał:

> 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?

No, there isn't.

> 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.

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?

-- 
Tomek

On Thursday, March 17, 2011 13:44:42 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.

D has nothing like that. Periodically someone will bring it up, but until someone actually sits down and implements something, it doesn't look like it's going to happen anytime soon. Like many things around here, it's only going to get done if someone who really wants it done has both the time and the know-how to do it (and then actually takes the time to do it). And that hasn't happened yet.

- Jonathan M Davis

On 3/17/11 4:00 PM, Tomek Sowiński wrote:
> Jason E. Aten napisał:
>
>> 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?
>
> No, there isn't.
>
>> 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.
>
> 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?

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.

Andrei

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.

>> 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

Somewhat tongue in cheek, we could call it dabal.

As in, "get on dabal!"  :-)

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 ;-)

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.


-- 
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

Russel Winder Wrote:

> At the expense of easy system administration.

Specifics? It allows for one packaging system across all operating systems. This means you don't need to figure out how to package your source in RPM, Deb, ipgk, arc, emerge, zip, or whatever else Linux has.

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.

2011/3/18 Jesse Phillips <jessekphillips+D@gmail.com>:
> Russel Winder Wrote:
>> At the expense of easy system administration.
> Specifics? It allows for one packaging system across all operating systems. This means you don't need to figure out how to package your source in RPM, Deb, ipgk, arc, emerge, zip, or whatever else Linux has.

For the developer, yes. For the user, it just means that you have to learn N different packaging systems, which not uncommonly cause conflicts, for instance in language-bindings conflicting with "native" libraries.

I know of at least one company that were quite serious about migrating their webapps from Java to Ruby/rails, but after a while cancelled due to just those packaging issues with gems creating weird conflicts and silent errors when bindings were complied slightly differently from the native C-lib.

----
For the record, their apps were designed for deployment on Ubuntu Server, which at the time had native support for almost all Java-related packages, but less wide support for Ruby. The situation have changed a little since then, and quite a lot of Ruby-packages are now in native Ubuntu.