How can I help?

[Kyle Heath]

Hi Ryppl developers,

Short version: 

I am excited to learn about ryppl.  I have fought with many of the issues ryppl is trying to solve and have built my own tools.  I want to learn more about the state of ryppl and find out if I can help.  What are the project's current needs?  

Long version:

Over the past few years, I've built a library of CMake macros to simplify complex development workflows I use in my research as a grad student.  These workflows involve messy dependency chains of c++, python, java, swig, protobuffer, qt, and cuda binary and library targets.  In my workflows, I frequently build binaries to be distributed and run on fresh-installed cloud instances and used the as-static-as-possible linking strategy to reduce runtime dependency management hell.   I've posted my tools which I call CMake SNAP with some examples here: https://github.com/cmakesnap/snap.

Rambling version:

My SNAP system only tackles a tiny subset of the problems ryppl seeks to address...  For example, SNAP only builds projects where nearly all dependencies have been vendored into the source tree in order to dodge the complexities of a full-blown distributed package manager.   I've vendored popular packages like Eigen, opencv, boost, snappy, libjpeg into my research project source trees and patched them to work as reusable modules with my cmake SNAP build system...  I've decided that manualy vendoring + syncing subproject code is not efficient for reusing my own modules and will never work to enable a vibrant development community.  I dream of the day that I can easily publish my own cross-language-platform source and binary packages so that others can easily reuse them.  In researching approaches to the package management problem, I found node.js' NPM design very elegant and no doubt a major factor of that community's (surprising ?) rapid growth.  Seeking a cross platform and language package solution, led me to zeroinstall.  Reading everything I could about zeroinstall, I heard some noise about ryppl.  I would love to see the day when a dev can just express in one-line a dependency on a local (dev) or remote (git published and semantic versioned) package in any language for any platform and the magic build system automatically resolves versions, fetches, and builds all dependencies.  Let me know how I could help.

Cheers,

Kyle Heath

http://www.stanford.edu/~heathkh

[Dave Abrahams]

on Sat Jun 08 2013, Kyle Heath <heathkh-AT-gmail.com> wrote:

> Hi Ryppl developers,
>
> Short version:
> I am excited to learn about ryppl. I have fought with many of the
> issues ryppl is trying to solve and have built my own tools. I want
> to learn more about the state of ryppl and find out if I can help.
> What are the project's current needs?

It's probably not a very satisfying answer for someone with your
interests, but right now the most immediate need is to complete Boost's
conversion from SVN to modularized Git. Until that is done, those of us
with a bigger vision for Ryppl will probably be somewhat (<<==
understatement) preoccupied.

> Long version:
> Over the past few years, I've built a library of CMake macros to
> simplify complex development workflows I use in my research as a grad
> student. These workflows involve messy dependency chains of c++,
> python, java, swig, protobuffer, qt, and cuda binary and library
> targets. In my workflows, I frequently build binaries to be
> distributed and run on fresh-installed cloud instances and used the
> as-static-as-possible linking strategy to reduce runtime
> dependency management hell. I've posted my tools which I call CMake
> SNAP with some examples here: https://github.com/cmakesnap/snap.

Nifty. It'd be great to have more CMake experts aboard.

> Rambling version:
> My SNAP system only tackles a tiny subset of the problems ryppl seeks
> to address... For example, SNAP only builds projects where nearly
> all dependencies have been vendored into the source tree in order to
> dodge the complexities of a full-blown distributed package manager.
> I've vendored popular packages like Eigen, opencv, boost, snappy,
> libjpeg into my research project source trees and patched them to
> work as reusable modules with my cmake SNAP build system... I've
> decided that manualy vendoring + syncing subproject code is
> not efficient for reusing my own modules and will never work to
> enable a vibrant development community.

Agreed.

> I dream of the day that I can easily publish my own
> cross-language-platform source and binary packages so that others can
> easily reuse them. In researching approaches to the package
> management problem, I found node.js' NPM design very elegant and no
> doubt a major factor of that community's (surprising ?) rapid growth.

Yes, I've heard really good things about that, but don't know that much
about it.

> Seeking a cross platform and language package solution, led me to
> zeroinstall. Reading everything I could about zeroinstall, I heard
> some noise about ryppl. I would love to see the day when a dev can
> just express in one-line a dependency on a local (dev) or remote (git
> published and semantic versioned) package in any language for any
> platform and the magic build system automatically resolves versions,
> fetches, and builds all dependencies. Let me know how I could help.

Feel like working on the Git conversion problem?

> Cheers,
> Kyle Heath
> http://www.stanford.edu/~heathkh

If you're at Stanford, perhaps we should get together for coffee at
some point and discuss Ryppl in person? I moved to San Jose in February
to work at Apple...

--
Dave Abrahams