where does macports store it's installed application database?

[Panayotis Katsaloulis]

On 10 Δεκ 2009, at 2:32 π.μ., Ryan Schmidt wrote:

> 
> 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)"

Yes I know ;) I just haven't finished yet the configuration dialog :)
The first "official" release won't have these problems.

Btw, there is a serious bug in my code, which was produced while moving around files to make them publishable for google-code.
I am uploading a fix soon :)

> 
>> 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.

I didn't know this application, and I tried to install it right now. But (hehe) I wasn't able to use it :)
It crashes (so I probably need to make a new bug report about it).
From the seconds I was able to have a look at it, I am sure there are things that I prefer in my own solution :)


> 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.

Yes, that's probably a good solution. But in any case I am a bit concerned about speed issues.
In any case, I totally agree with 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.

You are wrong!
;)
I think like everything else, being "compatible" with the look & feel of the underlying system is actually how much effort the programmer wants to use.
For example Porticus (which was my only knowledge of macports front-ends) although is written in Cocoa, is as ugly (or pretty) as a KDE application :) .
I believe that, when you'll manage to see my application, you'll change you idea about Java!

Java has a lot of advantages, like for example is a protected language. See for example your situation (the exception you got) and you know exactly what happened.
In Pallet I got only something like 
10/12/2009 2:48:02 π.μ.	com.apple.launchd.peruser.501[274]	([0x0-0xac0ac].org.MacPorts.Pallet[14275]) Job appears to have crashed: Segmentation fault
What can I do now?  :-)

Still, my original idea why to use java is because it's multi-platform and the knowledge I get from working with Java under mac, could be possible to move it under Linux.
With Obj-C I am tied up to Mac platform, which is something I hate (since I've changed so so many platforms from my day-1 in computers).
Java has served me rather good for a long time, longer than any other alternative.

I might agree with you, it's not always the "best choice", but it is a good choice and - at least!!! - it's open source.
And finally, if you were really  worried about performance, you wouldn't use tk, right ?
;-)

Anyway, CafePort (will) use external programs to do the job, so under this context, won't differ much from *C