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
