[doap-interest] Extending DOAP for software packaging

[Shadi Abou-Zahra]

Maybe somewhat similar to this request we found that DOAP is great for 
describing software development projects but less so for instances of 
actual software (builds).

The currently draft W3C Evaluation and Report Language (EARL) proposes 
earl:Software that is a sub-class of doap:Project, to describe a piece 
of software instance:
  - <http://www.w3.org/TR/EARL10-Schema/#Software>

It would be better to have this be directly part of the DOAP Schema 
rather than in EARL or other secondary schemas.

I'd appreciate feedback on this. Maybe there's a better way to do this?

Best,
   Shadi


On 6.1.2012 20:39, Zack Williams wrote:
> Just an idea for moving forward with DOAP on a slight tangent.
>
> I see DOAP as being extendable so that occupies the middle ground between development and deployment, and reduces friction for creating packaged, installable software from code.
>
> Current development practice, at it's best, is someone starts a project, develops code, and hopefully puts it in version control posted somewhere online.  Depending on the language, there may be build requirements, runtime requirements, etc., which are hopefully communicated in a README file, or through failure of the build process.  This is great for humans, but not for machines.
>
> Deployment of software is ideally done via a system's package management, ports system, or similar.  If a project isn't available in those natively, a sysadmin will manually download tarballs or check out code from version control, then build it manually.  The problem is that the manual process doesn't scale as it isn't automatically updated, doesn't integrate with existing package management (writes untracked changes to files throughout the system), and doesn't follow best practices.
>
> Imagine DOAP as filling this gap, and allowing a system independent way of giving a project description (it already does), how to get the code (again, already done), basic build methods (say, if the project is built with make, autotools, etc.) a list of dependencies (at build and runtime), and various other attributes.  The DOAP file wouldn't be tied to any specific packaging method.
>
> Then, a DOAP enabled package creation tool could work as follows:
>
>   - You'd point the tool at a DOAP enabled URL or file with DOAP data
>
>   - The tool would check your OS's package system/ports tree for prior existence of that project, and if found, give you the option of installing the version given there.
>
>   - If not found, give the option of attempting to create a package from the DOAP information.  It would download and build the code as DOAP specifies, then create a package for use on the system.  Also, in cases where there's a specific need, this could also be used to generate your own packages from a specific VCS-branch that isn't packaged otherwise.
>
>   - The tool could periodically check the DOAP supplied information to keep packages up to date, and rebuild as necessary.
>
> This wouldn't be the only use - for example, the data could be used to configure a continuous integration system, or any other automated system that needs to grab code, get it compiled, and run it.
>
> There are already tools that are similar to this for arbitrary package building (FPM comes to mind: https://github.com/jordansissel/fpm/wiki ), which could benefit from this.
>
> Does this seem like a viable idea, or would it go beyond the intended goals of DOAP?
>
> Thanks,
> Zack
>

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, W3C/WAI International Program Office
Evaluation and Repair Tools Working Group (ERT WG)
Research and Development Working Group (RDWG)