>  How do people envision running tcl module applications that have been
>  installed into a transparent/installation repository?  Besides the
>  obvious just run it.
 
>  The builtin tcl module stuff appears to only be looking at items under
>  the package directory.

Yes. Scripts need only packages, so they look only for them.
Applications are of no interest to the package management code of the
Tcl core.

>  The package side of things makes sense.  However once you get
>  applications installed, some with multiple versions, in multiple
>  architectures what mechanisms are in place, or planned, to determine
>  which application is the correct one to run.

None. 

>  For instance I don't readily see a builtin way of getting the
>  architecture that you are currently on, same string anyways (ie
>  linux-glibc2.3-ix86).

package require platform
platform::identify

>  Also with the version being incorporated into the filename it's
>  not a straight forward "add this directory to the PATH".

>  It would seem like you would always be stuck updating some sort of
>  startup wrapper to run these applications, or creating a more
>  intelligent wrapper to start these to fit you needs. An intelligent
>  wrapper in some cases would not be much different than the whole
>  package tcl module mechanism only for starting the latest version of
>  a given application for your given architecture via an exec.

Ah, you are thinking about 'exec' (tcl exec? shell exec?). I was not
thinking about that one at all. Only about starting from a shell,
i.e. terminal. But even for that, I know that the current setup of the
repository is not very good, due to the PATH issues, and no clear way
to handle multiple versions, or architectures.

Currently the best way of dealing with applications is to 'get' them,
and then place them in some directory of your choice on the
PATH. 'install'ing applications does not really make sense yet.

I will keep your idea of an 'intelligent' wrapper in mind while this
is percolating through my subconscious.

... I should note that such a wrapper doesn't have to be that
intelligent ... The information about the latest version can be
written into it by the repository manager, and the platform is
queryable, albeit requiring a proper tclsh in the PATH.

	#!/bin/sh
	p=`echo 'package require platform;puts [platform::identify];exit'|tclsh`
	exec /repository/application/${p}/foo-X.Y

In this small shell script the X.Y would be writen by the repo
manager, based on its knowledge of the installed versions of foo.


>  I realize this is more up to the end user to decide on, but I'm
>  curious if there is more of a plan to this that we haven't been
>  shown yet

No.

>  or if I'm just blind to something more obvious.

No, there is nothing obvious around, at least not to me.

>   Maybe
>  I'm just looking at the application end of a
>  transparent/installation repository wrong?

No, you are not. 

I think when I wrote this part and made applications installable it
was more for forms sake (*), so that the repository could be used as a
source for other repositories. It is becoming ever more clear that
running 'installed' applications is difficult at best.

(*) This does not mean that I was aware of this when I did the
writing. I am currently trying to understand what I was (maybe)
thinking.

--
        Andreas Kupries <andreask@[...].com> 
        Developer @ http://www.ActiveState.com
        Tel: +1 778-786-1122

_______________________________________________
TDK mailing list
TDK@[...].com
http://listserv.ActiveState.com/mailman/listinfo/tdk