Orbit - Package Manager - Specification/ideas

[Jacob Carlborg]

On 2011-07-14 11:07, Johannes Pfau wrote:
> 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?
>>
>> Orbfile section:
>>
>> The "orb" command that accepts git/hg/svn repositories should also
>> allow for a tag/commit parameter I think.
>>
>> The "orb" commands second parameter could also be a list of serveral
>> repositories to try in order for fallback.
>>
>> I guess a user configuration file in ~/.orb could contain "source"
>> commands as well.
>>
>> 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.
>>
>> 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.
>> 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.
>>
>> Additionally the architecture should be added to the name:
>> /orb/<package>-<version>_<build>-<arch>
>> Now it is just like how debian files look like :)
>>
>> Maybe put the file in an arch subdir
>> /orb/<arch>/<package>-<version>_<build>
>>
>> I'm really in favor of doing this in D instead of ruby though.
>>
>> /Jonas
>>
>>
>>
>>
>
> And in Package SubTypes:
> No documentation subtype for now?

I though they were quite self explanatory. But I can add documentation 
for them if necessary.

> Do Library and Dynamic library always contain the .d/.di headers?

Library (which is static library) needs to contain headers yes. Dynamic 
library will probably contain headers as well.

> In orbspec:
> The callbacks are run when the package is being build, correct? (The
> install callback could also be called when the package is being
> installed, but I think we don't need this functionality)

I see now that I have to give this some thought. The "build" callback 
could be called both when all files are built into the package and when 
the package later is built to be installed.

> So those are the hooks to use any custom build system?

Yes and no. There is also the "build" field which allow you yo call a 
custom shell script or custom build tool. Something like this:

build :shell, "my_custom_build_script.sh"

> Are Check Platform and Set Platform really needed in the orbspec? I
> think this can be left to drake or other build systems, can't we keep
> orbspecs platform agnostic?

Absolutely, the orbspecs are as platform agnostic as possible. But I see 
no harm in having the possibility to check the platform. I'm pretty sure 
at least someone will find a need for it.

> I'd make build_dependencies and dependencies a required field.
> (Although empty is ok. Can we distinguish between not set and empty?)

I see no point in setting the build_dependencies and dependencies fields 
if the package doesn't have any dependencies. nil/null would be not set 
and an empty array (in this case) would be empty.

-- 
/Jacob Carlborg