[doap-interest] Extending DOAP for software packaging

[Zack Williams]

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 

-- 
Zack Williams - Artisan Computer Services - 520.867.8701
zdw at artisancomputer.com   http://www.artisancomputer.com
Apple Certified System Administrator, Apple Consultants Network
Microsoft Certified Professional, Small Business Specialist
Sun Certified System Administrator
Linux Professional Institute LPIC-1