GSoC idea for the binary issue (yet again)

[Anders F Björklund]

Erik Österlund wrote:

> Issue 2
> The second issue is that binary packages and ports compiled and installed from source do not know about each other; they do not share the same registry. So part of the job will be to make sure the new pkg command uses the same registry as the ports command. 
> 
> What I am thinking here is to use the MacPorts.framework to interact with the registry as this is already implemented.
> 
> If I am right, MacPorts.framework still depends on TCL, so a TCL interpreter is still needed. But it does not require the ports tree, right?

It should be possible to have it just require the PortIndex.
And then read the archive's +PORTFILE, for the current port.

Or have it require dports/, it's not the end of the world...
As long as it doesn't require Developer Tools, it's still OK.

> The solution
> I would implement a pkg(1) command in Objective-C using MacPorts.framework to interact with the registry.
> The command would fetch archives and their belonging Portfile, unarchive it at destroot and run the scripts in the Portfile using a TCL interpreter (but still without need for the ports tree or Xcode).
> 
> Why Objective-C and not TCL?
> There are two reasons. One reason is that I heard making everything in Objective-C is something that might be done later but is a different project. So by creating the tool in Objective-C it is more compatible with the predicted future.
> The second reason is that I am simply much better at Objective-C since I actively programmed with it since I was 12.
> If it has to be made in TCL, I am open for that too, but I'm simply better at Objective-C.

Actually, the suggestion to do it in Tcl was because that it
would be *easier* since it could re-use a lot of existing code.
It probably has to wrap Tcl anyway, for ports and for registry,
so you might end up doing it twice (like in MacPorts.framework).

But if you want to go ahead with the MP "conversion" to Obj-C,
like has already started with the MP GUI, then go right ahead.
That goes for pkg(1) as well as for port(1), even if neither is
required to be converted to Objective-C and you might need both. 

i.e. my recommendation would be to implement it in Tcl first,
and then convert to Objective-C for the speed/size improvement ?

It should still be using the "same" MacPorts API, either way...
Sometimes the Tcl version sticks around, like base or "DPGUI"*.

--anders

* http://sourceforge.net/projects/dpgui/
  now known as Port Authority (shareware)