where does macports store it's installed application database?

Ryan Schmidt ryandesign at macports.org
Wed Dec 9 16:32:03 PST 2009


On Dec 9, 2009, at 16:29, Panayotis Katsaloulis wrote:

> I am in the process of creating a front-end for macports, and I wanted to know where does it store the list of installed applications.
> I've found, for example in the default installation, that the list of available ports is found under 
> /opt/local/var/macports/sources/rsync.macports.org/release/ports/PortIndex
> 
> which is convenient and easily parsable.

Yes... but you can't rely on that being the case. The user may have their ports tree elsewhere (as configured in ${prefix}/etc/macports/sources.conf), and their ${prefix} may not be /opt/local. My ports tree is elsewhere, and on my system, your CafePorts-0.0.1-Beta1.jar hangs at "Please wait... reading database" and the Console shows "java.io.FileNotFoundException: /opt/local/var/macports/sources/rsync.macports.org/release/ports/PortIndex (No such file or directory)"


> P.S. is someone wants to beta test my application (which is open source of course), I'd be glad to collaborate and listen to a second opinion.
> I've just uploaded it to google code here:
> https://code.google.com/p/cafeports/

Thanks for letting us know. It can be good to have more options. But I hope you're aware we already have multiple GUI clients for MacPorts. For example Pallet (sudo port install pallet) is free and officially sanctioned by MacPorts, and was recently refreshed during Google Summer of Code '09; its code is in the MacPorts repository. You may want to consider whether contributing fixes and new features to Pallet would be more effective than starting a new client from scratch.

We have a Tcl interface available for potential GUI (or non-GUI) clients to use; Pallet uses it. Using this interface insulates you from changes we may make to MacPorts in the future. If you choose not to use that and try to parse MacPorts receipts, port indexes, and other files directly, your app will probably break in the future as MacPorts revises how it uses those files, which will be more work for you.

As a side note, I am curious about your choice to use Java for this client, since MacPorts is primarily used on Mac OS X, whereas Java apps have historically had bad reception on Mac OS X. Certainly I avoid Java apps on the Mac if at all possible, because they typically have worse performance than native Mac OS X Cocoa apps, and their interfaces never seem to quite fit in with the Mac look and feel.




More information about the macports-users mailing list