You've basically described Homebrew, I have been wanting to take a look at Homebrew for a while, I think you would be surprised, if you don't already know, to see how close what you just laid out lines up with there philosophies.  Specifically, they don't try to manage python eggs, ruby gems, or perl modules because of pip/gem/cpan? do that already, and they don't encourage duplicating libraries and/or applications that are already OS X.  <meta http-equiv="content-type" content="text/html; charset=utf-8">In addition Homebrew strives to be sudo free.  It does, however, have its package "scripts" written in Ruby, and I don't really know if that is a plus or minus =D.<div>

<br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://mxcl.github.com/homebrew/">http://mxcl.github.com/homebrew/</a></div><div><br></div><div>Either way it should be in the considerations, though I think pkgsrc is also a good option.</div>

<div><br></div><div>--</div><div><br clear="all">~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>William Woodall<br>Graduate Software Engineering<br>Auburn University<br><a href="mailto:w@auburn.edu" target="_blank">w@auburn.edu</a><br>

<a href="mailto:wjwwood@gmail.com" target="_blank">wjwwood@gmail.com</a><div><a href="http://williamjwoodall.com" target="_blank">williamjwoodall.com</a><br>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</div><br>
<br><br><div class="gmail_quote">On Tue, Aug 2, 2011 at 3:32 AM, Ken Conley <span dir="ltr"><<a href="mailto:kwc@willowgarage.com">kwc@willowgarage.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On Tue, Aug 2, 2011 at 12:21 AM, Serge Stinckwich<br>
<<a href="mailto:serge.stinckwich@gmail.com">serge.stinckwich@gmail.com</a>> wrote:<br>
> On Fri, Jul 29, 2011 at 11:09 PM, Brian Gerkey <<a href="mailto:gerkey@willowgarage.com">gerkey@willowgarage.com</a>> wrote:<br>
>> hi,<br>
>><br>
>> Thanks to Stefan Schaal, who gave me a hard time last month for ROS<br>
>> having mediocre OS X support, especially given that I carry a MBPro, I<br>
>> can report on some progress.<br>
><br>
> Thank you Stefan&Brian for this effort !<br>
><br>
>> Wim and I started bringing up devel_electric builds of stacks on OS X.<br>
>>  The dashboard is here:<br>
>>  <a href="http://build.willowgarage.com/view/os-x/" target="_blank">http://build.willowgarage.com/view/os-x/</a><br>
>> The stacks that we're currently building (or trying to build) are<br>
>> listed below.  More stacks are being added all the time, so check the<br>
>> dashboard above to see current status.<br>
>><br>
>> These builds are testing the Electric development branch of each stack<br>
>> (often, but not always, trunk/default) against the Electric released<br>
>> versions of the stacks it depends on.  The machine the builds are<br>
>> running on is 10.6.x (Snow Leopard) and was bootstrapped according to<br>
>> the standard install instructions<br>
>> (<a href="http://www.ros.org/wiki/electric/Installation/OSX" target="_blank">http://www.ros.org/wiki/electric/Installation/OSX</a>).<br>
>><br>
>> I did *not* follow wjwwood's suggestion to configure MacPorts as<br>
>> strictly 32-bit (<a href="https://github.com/wjwwood/ros-osx/wiki" target="_blank">https://github.com/wjwwood/ros-osx/wiki</a>).  As a<br>
>> result, I expect that we'll have trouble with anything using wx (e.g.,<br>
>> rviz).  In the future, we'll probably bring up a OS X 10.7 (Lion)<br>
>> machine, which reportedly will resolve these issues.  In the meantime,<br>
>> we can make progress on building all the non-wx stuff.<br>
>><br>
>> The goal of these builds is to keep track of what works, and to<br>
>> prevent regressions.  A stack "works" when you can successfully<br>
>> `rosmake --rosdep-install -t <stack>`, which means that all system<br>
>> dependencies are correctly resolved, and everything builds and tests.<br>
>><br>
>> How you can help:<br>
>> * If you're working on OS X, suggest stacks that you know to build<br>
>> that should be added to the list.<br>
>> * A lot of the work is in resolving system dependencies, in particular<br>
>> for things aren't available from MacPorts.  In those cases, we need<br>
>> "source rosdep" definitions.  Have a look at<br>
>> <a href="https://kforge.ros.org/rosrelease/viewvc/sourcedeps/" target="_blank">https://kforge.ros.org/rosrelease/viewvc/sourcedeps/</a> for examples.<br>
>> * If you get email from Hudson about an OS X failure, please have a<br>
>> look at it.  If you can't figure out what went wrong, forward it to me<br>
>> and we can dig into it together.<br>
><br>
> I think also that this is important to have continuous builds just to<br>
> check where are the problems<br>
><br>
> I was wondering recently if using pkgsrc instead of macports could be<br>
> a better solution for distributing ROS on OS X.<br>
> Pkgsrc is the NetBSD Packages Collection and there is an OS X version:<br>
> <a href="http://www.netbsd.org/docs/software/packages.html" target="_blank">http://www.netbsd.org/docs/software/packages.html</a><br>
> What is cool is that they also provide binary packages for several<br>
> platforms (not sure about OS X) and a quaterly stable release (not<br>
> daily updates like with Macports). There is more than 10000 packages<br>
> currently.<br>
<br>
</div></div>In general, +1 to:<br>
<br>
 * moving away from macports<br>
 * quarterly release, lots of packages<br>
<br>
It doesn't appear they provide binaries for OS X, though.<br>
<br>
I have a strawman proposal, which is multi-pronged:<br>
<br>
 1) migrate all Python* dependencies to use pip + the Apple Python<br>
interpreter, which will take care of a small percentage of<br>
dependencies.<br>
 2) where possible, use MacOS-specific binaries for thirdparty<br>
libraries (generalization of #1). This may not be possible to fully<br>
automate.<br>
 3) where available, use source rosdeps (e.g. eigen) provided by ROS.<br>
These are generally dependencies that are not yet commonly available<br>
via a package manager.<br>
 4) either create new source rosdeps, or utilize something like pkgsrc<br>
to provide remaining dependencies.<br>
<br>
i.e. the lesson learned from MacPorts is use to as much pure OS X as<br>
possible, and also do as much integration on top of fixed/known<br>
targets as possible.  Obviously #2 and #4 require much more thought to<br>
expand out.<br>
<font color="#888888"><br>
- Ken<br>
</font><div><div></div><div class="h5"><br>
><br>
> Regards,<br>
> --<br>
> Serge Stinckwich<br>
> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam<br>
> Every DSL ends up being Smalltalk<br>
> <a href="http://doesnotunderstand.org/" target="_blank">http://doesnotunderstand.org/</a><br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div>