I personally have a deep ambivalence to MacPorts. I would say about 90% of the time I really love it, and 10% of the time I really hate it. Those 10% of the times usually lead me to explore workarounds which also have their own dificiencies, and I always end up back at MacPorts.<div>
<br></div><div>Right now is one of the 10%, because Atlas has been broken for a few weeks, breaking tons of ports, notably numpy. A reportedly working patch has been chilling on the trac for at least a week, but it has yet to get pushed out, and so my ports are languishing and I'm forced into workarounds. </div>
<div><br></div><div>But when everything works like it should, which is really a lot of the time, I love MacPorts. As Marc says, the issues that WG are currently trying to address are really complex, and every package manager also has to deal with them in different ways and make different tradeoffs. MacPorts picks its ways (e.g. the various python version hacks) for better or worse. But they keep a huge amount and variety of packages. It's rare that they don't have what I need. </div>
<div><br></div><div>The problem with MacPorts is larger than MacPorts. The problem is that platforms, compilers, APIs, and 3rd party libraries are all moving targets, for better or worse and often for better. Keeping up is hard, but can be made easier by unittests, automated build systems that report errors, etc. These won't fix all your problems -- e.g. when an important third party dependency decides to be a stick in the mud rather than go with the flow (like wx and ogre).</div>
<div><br></div><div>Just my $.02.</div><div><br></div><div>--Nick</div><div><br></div><div><br><br><div class="gmail_quote">On Tue, Aug 2, 2011 at 10:43 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 class="im">On Tue, Aug 2, 2011 at 4:51 AM, William Woodall <<a href="mailto:wjwwood@gmail.com">wjwwood@gmail.com</a>> wrote:<br>

> You've basically described Homebrew, I have been wanting to take a look at<br>
> Homebrew for a while, I think you would be surprised, if you don't already<br>
> know, to see how close what you just laid out lines up with<br>
> there philosophies.  Specifically, they don't try to manage python eggs,<br>
> ruby gems, or perl modules because of pip/gem/cpan? do that already, and<br>
> they don't encourage duplicating libraries and/or applications that are<br>
> already OS X.  In addition Homebrew strives to be sudo free.  It does,<br>
> however, have its package "scripts" written in Ruby, and I don't really know<br>
> if that is a plus or minus =D.<br>
> <a href="http://mxcl.github.com/homebrew/" target="_blank">http://mxcl.github.com/homebrew/</a><br>
> Either way it should be in the considerations, though I think pkgsrc is also<br>
> a good option.<br>
<br>
</div>Thanks for the pointer; I'm checking it out now (I'm taking the<br>
recommended action of uninstalling MacPorts first).<br>
<br>
The philosophy is definitely in keeping with what I prefer.  My only<br>
knocks so far are (1) the version provided by formulas isn't<br>
immediately obvious and (2) they don't differentiate different OS X<br>
versions, so I wonder what the future transition costs will be.<br>
<br>
A third and more generic concern is that you probably shouldn't have<br>
Homebrew and MacPorts both installed, so it will definitely require a<br>
consensus in the ROS community.  My personal antipathy to MacPorts is<br>
probably clear by now, but I defer to those like you who have gotten<br>
further with integrating rviz and the like.<br>
<font color="#888888"><br>
 - Ken<br>
</font><div><div></div><div class="h5"><br>
> --<br>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
> William Woodall<br>
> Graduate Software Engineering<br>
> Auburn University<br>
> <a href="mailto:w@auburn.edu">w@auburn.edu</a><br>
> <a href="mailto:wjwwood@gmail.com">wjwwood@gmail.com</a><br>
> <a href="http://williamjwoodall.com" target="_blank">williamjwoodall.com</a><br>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
><br>
><br>
> On Tue, Aug 2, 2011 at 3:32 AM, Ken Conley <<a href="mailto:kwc@willowgarage.com">kwc@willowgarage.com</a>> wrote:<br>
>><br>
>> 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>><br>
>> > 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>
>> 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>
>><br>
>> - Ken<br>
>><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>
><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>
><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>