Well said, also I think there is a --no-atlas variant of numpy that doesn't require it, though I don't know at what cost to performance. --- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ William Woodall Graduate Software Engineering Auburn University w@auburn.edu wjwwood@gmail.com williamjwoodall.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Tue, Aug 2, 2011 at 1:43 PM, Nicholas Butko wrote: > 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. > > 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. > > 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. > > 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). > > Just my $.02. > > --Nick > > > > On Tue, Aug 2, 2011 at 10:43 AM, Ken Conley wrote: > >> On Tue, Aug 2, 2011 at 4:51 AM, William Woodall >> wrote: >> > 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. 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. >> > http://mxcl.github.com/homebrew/ >> > Either way it should be in the considerations, though I think pkgsrc is >> also >> > a good option. >> >> Thanks for the pointer; I'm checking it out now (I'm taking the >> recommended action of uninstalling MacPorts first). >> >> The philosophy is definitely in keeping with what I prefer. My only >> knocks so far are (1) the version provided by formulas isn't >> immediately obvious and (2) they don't differentiate different OS X >> versions, so I wonder what the future transition costs will be. >> >> A third and more generic concern is that you probably shouldn't have >> Homebrew and MacPorts both installed, so it will definitely require a >> consensus in the ROS community. My personal antipathy to MacPorts is >> probably clear by now, but I defer to those like you who have gotten >> further with integrating rviz and the like. >> >> - Ken >> >> > -- >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > William Woodall >> > Graduate Software Engineering >> > Auburn University >> > w@auburn.edu >> > wjwwood@gmail.com >> > williamjwoodall.com >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > >> > >> > On Tue, Aug 2, 2011 at 3:32 AM, Ken Conley >> wrote: >> >> >> >> On Tue, Aug 2, 2011 at 12:21 AM, Serge Stinckwich >> >> wrote: >> >> > On Fri, Jul 29, 2011 at 11:09 PM, Brian Gerkey < >> gerkey@willowgarage.com> >> >> > wrote: >> >> >> hi, >> >> >> >> >> >> Thanks to Stefan Schaal, who gave me a hard time last month for ROS >> >> >> having mediocre OS X support, especially given that I carry a MBPro, >> I >> >> >> can report on some progress. >> >> > >> >> > Thank you Stefan&Brian for this effort ! >> >> > >> >> >> Wim and I started bringing up devel_electric builds of stacks on OS >> X. >> >> >> The dashboard is here: >> >> >> http://build.willowgarage.com/view/os-x/ >> >> >> The stacks that we're currently building (or trying to build) are >> >> >> listed below. More stacks are being added all the time, so check >> the >> >> >> dashboard above to see current status. >> >> >> >> >> >> These builds are testing the Electric development branch of each >> stack >> >> >> (often, but not always, trunk/default) against the Electric released >> >> >> versions of the stacks it depends on. The machine the builds are >> >> >> running on is 10.6.x (Snow Leopard) and was bootstrapped according >> to >> >> >> the standard install instructions >> >> >> (http://www.ros.org/wiki/electric/Installation/OSX). >> >> >> >> >> >> I did *not* follow wjwwood's suggestion to configure MacPorts as >> >> >> strictly 32-bit (https://github.com/wjwwood/ros-osx/wiki). As a >> >> >> result, I expect that we'll have trouble with anything using wx >> (e.g., >> >> >> rviz). In the future, we'll probably bring up a OS X 10.7 (Lion) >> >> >> machine, which reportedly will resolve these issues. In the >> meantime, >> >> >> we can make progress on building all the non-wx stuff. >> >> >> >> >> >> The goal of these builds is to keep track of what works, and to >> >> >> prevent regressions. A stack "works" when you can successfully >> >> >> `rosmake --rosdep-install -t `, which means that all system >> >> >> dependencies are correctly resolved, and everything builds and >> tests. >> >> >> >> >> >> How you can help: >> >> >> * If you're working on OS X, suggest stacks that you know to build >> >> >> that should be added to the list. >> >> >> * A lot of the work is in resolving system dependencies, in >> particular >> >> >> for things aren't available from MacPorts. In those cases, we need >> >> >> "source rosdep" definitions. Have a look at >> >> >> https://kforge.ros.org/rosrelease/viewvc/sourcedeps/ for examples. >> >> >> * If you get email from Hudson about an OS X failure, please have a >> >> >> look at it. If you can't figure out what went wrong, forward it to >> me >> >> >> and we can dig into it together. >> >> > >> >> > I think also that this is important to have continuous builds just to >> >> > check where are the problems >> >> > >> >> > I was wondering recently if using pkgsrc instead of macports could be >> >> > a better solution for distributing ROS on OS X. >> >> > Pkgsrc is the NetBSD Packages Collection and there is an OS X >> version: >> >> > http://www.netbsd.org/docs/software/packages.html >> >> > What is cool is that they also provide binary packages for several >> >> > platforms (not sure about OS X) and a quaterly stable release (not >> >> > daily updates like with Macports). There is more than 10000 packages >> >> > currently. >> >> >> >> In general, +1 to: >> >> >> >> * moving away from macports >> >> * quarterly release, lots of packages >> >> >> >> It doesn't appear they provide binaries for OS X, though. >> >> >> >> I have a strawman proposal, which is multi-pronged: >> >> >> >> 1) migrate all Python* dependencies to use pip + the Apple Python >> >> interpreter, which will take care of a small percentage of >> >> dependencies. >> >> 2) where possible, use MacOS-specific binaries for thirdparty >> >> libraries (generalization of #1). This may not be possible to fully >> >> automate. >> >> 3) where available, use source rosdeps (e.g. eigen) provided by ROS. >> >> These are generally dependencies that are not yet commonly available >> >> via a package manager. >> >> 4) either create new source rosdeps, or utilize something like pkgsrc >> >> to provide remaining dependencies. >> >> >> >> i.e. the lesson learned from MacPorts is use to as much pure OS X as >> >> possible, and also do as much integration on top of fixed/known >> >> targets as possible. Obviously #2 and #4 require much more thought to >> >> expand out. >> >> >> >> - Ken >> >> >> >> > >> >> > Regards, >> >> > -- >> >> > Serge Stinckwich >> >> > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> >> > Every DSL ends up being Smalltalk >> >> > http://doesnotunderstand.org/ >> >> > _______________________________________________ >> >> > ros-users mailing list >> >> > ros-users@code.ros.org >> >> > https://code.ros.org/mailman/listinfo/ros-users >> >> > >> >> _______________________________________________ >> >> ros-users mailing list >> >> ros-users@code.ros.org >> >> https://code.ros.org/mailman/listinfo/ros-users >> > >> > >> > _______________________________________________ >> > ros-users mailing list >> > ros-users@code.ros.org >> > https://code.ros.org/mailman/listinfo/ros-users >> > >> > >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >