Orbit - Package Manager - Specification/ideas

[Jacob Carlborg]

On 2011-07-13 22:20, jdrewsen wrote:
> Den 13-07-2011 21:19, Jacob Carlborg skrev:
>> I've written a more formal specification of my ideas for a package
>> manager for D.
>>
>> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
>>
>> Note that I am exploring the possibility of using D as the language for
>> all the files mentioned in the link above.
>>
>> The current status is that building packages and installing them works,
>> but quite limited. No dependency tracking or central repository so far.
>>
>> Please comment and suggest.
>
> Nice work!
>
> Orb - tool section:
>
> Describe what the "use" command does. I guess it simply adds a required
> orb to the Orbfile in the current directory?

I'm not sure if this is possible or not (specially on multiple 
platforms) but I was thinking something like this:

Say that you have several versions of the dwt package installed and you 
want to use a particular version, you can run the command like this:

"orb use dwt --version 0.3.5"

Then when you link with the "dwt" library it will link with the 0.3.5 
version.

> Orbfile section:
>
> The "orb" command that accepts git/hg/svn repositories should also allow
> for a tag/commit parameter I think.

Absolutely.

> The "orb" commands second parameter could also be a list of serveral
> repositories to try in order for fallback.

That might be a good idea.

> I guess a user configuration file in ~/.orb could contain "source"
> commands as well.

Sounds reasonable.

> Orb package section:
>
> I think the versioning scheme should be set in stone actually. Most
> other packaging systems does that. It makes your life much easier.

So you mean I shouldn't allow custom version strings?

> Central repository section:
>
> Please let us settle for one format for the metadata.xxx file. My vote
> is for json or yaml. XML is too verbose for my taste. I also think that
> it should be compressed e.g. metadata.json.bzip since it will quickly
> grow quite large and the packaging system has to be fast.

I haven't actually thought about what format to use. I just listed a few 
reasonable formats. Settling for one format is probably a good thing. 
Probably json since both Phobos and Tango has json modules and it's 
available in most languages.

> Maybe add the build revision on /orb/<package>-<version>_<build>
> since it is quite common reupload the same package version with at
> simple build fix.

If you read the version scheme I was thinking about having the last 
number as a build number:

major.minor.build

* Increment "build" when an implementation detail change
* Increment "minor" when a non-braking API change is made, i.e. adding a 
new function
* Increment "major" when a braking API change is made, i.e. removing a 
function

Maybe there should be a patch level of some king as well and alpha, beta 
and release candidates as well.

> Additionally the architecture should be added to the name:
> /orb/<package>-<version>_<build>-<arch>
> Now it is just like how debian files look like :)

Hm, this will take some though. I don't like the idea that the developer 
has to create multiple packages for a single package.

> Maybe put the file in an arch subdir
> /orb/<arch>/<package>-<version>_<build>

That is probably better.

I haven't actually thought that much about binary packages. I was mostly 
thinking about source packages that need to be built when installing 
them. Source packages don't have these problems.

> I'm really in favor of doing this in D instead of ruby though.
>
> /Jonas

I guess most people are.

-- 
/Jacob Carlborg