GSoC idea for the binary issue (yet again)

[Erik Österlund]

Greetings,

After a several hours long discussion on IRC and some mailing about the binary issue(s), I think I have finally become clear in what should be done.

Here is my conclusion and what I would like to do for GSoC:

The goal
Being able to download and install binary "packages".

Binaries‚ what are they
In my proposal, the idea is to use binary archives instead of "real" packages to keep it simple, doable, and make it happen. So each port will be compiled and archived by MPAB, and the result is used.

What needs doing
There are 2 problems to solve as I see it.

Issue 1
The first issue is that a command for installing binaries without requiring Xcode or the ports tree is wanted, so that users can easily install binaries without needing a whole bunch of dependencies. The suggestion is to create a new command, which is what I want to do during the summer. This command, let's call it pkg, will install binaries only, without the need for the whole ports environment (ports tree and Xcode, but still registry and TCL).

Note here that a TCL interpreter is still needed because of the scripts in the Portfiles! There are as I see it 3 options. 

1) Having only pre-defined operations for the pre/post install/activate/deactivate scripts.
2) Having a TCL interpreter and the necessary ports APIs, but without the ports tree.
3) A combination of 1 and 2, meaning that ports that use non-predefined operations in their scripts have a dependency to the stuff in 2 and run in a TCL interpreter.

I would like to go for #2 as the TCL stuff is necessary in the second issue too.

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?

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.

I think the focus will be exclusively creating the new pkg command, and less about doing things in MPAB. I will simply use the archives it produces.

If time allows, I would like to look at the build-aspect of the system too with MPAB, but it feels like a different project, does it not?

Does this seem like a clear and good idea, or a waste of time? Am I missing something?

Thanks,

- Fisk