Dream package management system (Was: a cabal for D ?)

[Jacob Carlborg]

On 2011-03-19 17:05, Chris Manning wrote:
> On 19/03/2011 14:36, Jacob Carlborg wrote:
>> On 2011-03-18 18:04, 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?
>>>
>>> Chris
>>
>> I've been thinking for quite some time to build a package management
>> system for D, lets call it dpac as an example. This is the ideas that I
>> have:
>>
>> Basically copy how RubyGems works.
>> Use Ruby as a DSL for dpacsepc files which is used to create to create
>> the dpac file. This is an example for how a file used to build a package
>> could look like:
>>
>> name "Foo Bar"
>> summary "This is the Foo Bar package"
>> version "1.0.0"
>> type :lib
>> author "Jacob Carlborg"
>> files ["lib.d"] # list of the files in the package
>> build :make # other options could be :dsss :cmake and so on
>> dversion 2 # D1 or D2
>>
>> Build a dpac package out of the dpacspec file:
>>
>> dpac foobar.dpacspec
>>
>> Publish the package:
>>
>> $ dpac publish foobar
>>
>> Install the package:
>>
>> $ dpac install foobar
>>
>> A dpac package would just be a zip file (or some other type of archive)
>> containing all the necessary files to build the package and a file with
>> meta data.
>>
>> All packages would be manged on a basic RESTful web server. Using GET to
>> download a package and POST to publish a package.
>>
>> I'm working on a build system for D that I was thinking about to
>> integrate with the package management system. Then the build system
>> could track the files needed to build the package, making the "files"
>> attribute optional.
>>
>> I also has a tool called DVM, https://bitbucket.org/doob/dvm , used for
>> installing and managing different versions of D compilers. I was
>> thinking about integrating DVM with the package management system to be
>> able to install different packages for different compilers.
>>
> I was thinking about something more similar to portage's ebuild system
> or arch's AUR. This would mean that the sources could be stored anywhere
> and just the info to build a package would be stored in a centralised
> location.
>
> For publishing these build "scripts", again, AUR's system comes to mind,
> although perhaps something more controll(ed/able). Also, gentoo's
> sunrise overlay.
>
> Of course, this comes with the downside of the user having to compile
> the packages on their end.
>
> Chris

Oh, I forgot a part. Just as with RubyGems you would be able to install 
a package from a repository (git, mercurial or something else) as long 
as it contains the file containing the package specification file 
(dpacspec).

Of course you could manually downloading a package and installing it.

-- 
/Jacob Carlborg