Orbit - Package Manager - Specification/ideas

Johannes Pfau spam at example.com
Fri Jul 15 02:21:40 PDT 2011


Jacob Carlborg wrote:
>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.

Sorry, my question wasn't clear:
I meant where will 'api documentation' for libraries go? In a special
'documentation' subtype or in the library packages?

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

Well, having to set it explicitly makes it less likely to forget those
fields, but that's the only reason.

-- 
Johannes Pfau



More information about the Digitalmars-d mailing list