Re: Distribution mechanisms

On Aug 25, 11:34 am, Kevin Walzer <k...@xxxxxxxxxxxxxxx> wrote:

We've gone from having an extremely simple range of distribution
mechanisms to having a vast array.


Let's start by defining what you mean by "distribution mechanism". I
asked Mr. Nash the same question.

One meaning of the term is "way people locate copies of extensions for
use on their site". For tcl, this has been a long term complaint.
People didn't want to have to search comp.lang.tcl, google, etc. to
locate extensions. They, in fact, still have to do this, but
Activestate's teapot mechanism is another tool for locating them.
Think of teapot as being a package distribution system - similar to
what ActivePerl has (or for that matter, similar to what some Linux
distributions have).

On the wiki page you mentioned "distribution method" was being used by
Mr. Nash as "file format and the Tcl commands used to load a new
command".

There are six variations listed on the page in question - however, do
note that most actually use one or two Tcl basic commands.

As for the question of why do we have 6 alternatives - it is called
"evolution". We could have stayed at the original "source" command in
the first Tcl, but that required one to hard code path commands. That
was inconvenient and made scripts non-portable, so first auto_load
(which depends on tclIndex to find the file to source), and then the
"package" command was created (which initially depended on the
pkgIndex file) so that a path was searched. This helped, but still
required people to link different versions of tclsh with C libraries,
but that was awkward and led site admins to having dozens of tclsh
variations. People asked for dynamic loading, and so the load command
was created and was tied into the package command. Now we had 3
different extension formats (plain source, source with tclIndex, and
binary or source with pkgIndex). Next came things like freewrap and
starkit - experiments with creating one file distribution mechanisms
as installation aids. The starkits can hold any of the previous
extension directory layouts, but required one to use a special starkit
package to access the extension from a virtual filesystem, but
requires special programming techniques to get binary extensions to
load.

Finally, a TIP was submitted, discussed, and passed for Tcl modules -
an alternative to starkit that appears, to me, to supersede starkits.

Do we have 6 different alternatives? Well, from what I can see,
auto_load uses load, package uses load or source. and Tcl modules use
load and source. So there are several wrappers on top of load and
source, different to provide path searching, parsing of file formats,
etc. Only 5 of these alternatives are in the core - starkit support
isn't built in.

I think, from reading your original posting, your question seems to
boil down to:
how is an extension writer supposed to determine the preferred
directory (or file) format when preparing an extension for
distribution to users?

To date, the recommendation from at least some of the experts has been
the Tcl Extension Architecture. That recommendation would be a
directory containing the pkgIndex.tcl as well as a number of other
files. However, I also see people report difficulties generating
these, even with the sample provided at tcl.sf.net .

Also, Tcl modules were approved for loading, but no tools are, as of
yet, included with Tcl for creating this format. So, from at least
_this_ software writer's perspetive, that format doesn't seem to me to
be ready for prime-time yet. Handcrafting files in this format is
going to lead to unexpected decisions on developers part that may
cause incompatibilties or difficulties in loading the files.
Hopefully this is going to be resolved.

Now, it seems like choosing a
Tcl-package distribution mechanism is as complicated as choosing a Tcl
object system.

It doesn't seem that difficult to me.

1. Do you want to put hard coded paths for your extension in program?
Use source or load to the files needed for your commands.
2. Do you want to invent your own way for dynamically loading your
extension? Use source or load.
3. Is your extension a tcl script? Create the tclIndex file and put it
and the tcl code into a directory, package that, and distribute.
4. Does your extension include binary? Then find the TEA sample
extension and pattern your code after that. More help for developers
unfamilar with all the autoconf tools would be beneficial here.
5. Do you want the ease that a single file extension provides? Learn
about Tcl Modules and read the TIP to see if you can understand how to
construct one. More help for developers unfamilar with Tcl Modules
would be beneficial here.



Specifically:

1. What is the purpose of Teacup? Is this a convenient central
repository where I can grab extensions without having to compile them
myself?

Well, teacup is the administrative client to a software repository
where the administrator can grab extensions which have been packaged
into a single file. Teapot is the server side of this combo, which
allows one to run their own repository.

What is Teacup's relation to ActiveTcl and what are the
licensing terms for binaries obtained from Teacup?

teacup is provided with the recent ActiveTcl distributions. With the
8.5 beta distributions, it is the primary means for an administrator
to load the majority of the extensions that an ActiveTcl developer
expects to find available, as well as a number of new extensions.

Your question about the licensing terms is a good one.

Is anyone using
Teacup, and would you recommend it?

I'm using teacup. It is required if you are going to use ActiveTcl
8.5 .


I am certainly open to experimenting with new approaches, but I want a
clear understanding of their advantages over the current system, and the
documentation on these items in particular is a bit sparse at this
point. Reports from adventurous developers are appreciated.

I agree that more information, as well as more tools, would be
appreciated. Read over the activetcl archives for some of the
information I've gleaned. I've had time to add a bit of that
information (relating to teacup) at http://wiki.tcl.tk/teacup . More
information is needed there as people learn it. More information at
http://wiki.tcl.tk/Tcl+Modules as well.


.

Relevant Pages

  • Anyone going to work on getting OO into tcl 8.5 core distribution?
    ... etc. regarding whether Tcl should have OO in the core. ... To add new extensions or features into the Tcl source code distribution ... maintained OO extension into the core? ...
    (comp.lang.tcl)
  • Re: Documentation
    ... The only extensions that are included with the Tcl distribution are: ... the registry extension and something on MacOS. ... Many of the packages sit there for years and nobody uses them. ... most authors are not strictly Tcl developers. ...
    (comp.lang.tcl)
  • dynamic vs static extension
    ... I have a dynamic extension to Tcl. ... The Expect I'm using is statically linked to Tcl. ... Is it possible to load my extension in this case? ...
    (comp.lang.tcl)
  • Re: Goodbye TCL
    ... anyone that likes TCL and TK and wants to see ... support for the language increase rather then decrease and usage increase ... Unfortunately it is not the TCL core, it comes with restrictions, anf it ... "distribution of record" for what clearly many users want - an extension ...
    (comp.lang.tcl)
  • Re: Porting *nix binary extensions to Win32
    ... >example extension I just wrote under OS X and compile it on Windows. ... Tcl extensions on Windows, circa 2006, as I understand them: ... Note that even if you're using MSVC6, you still need MinGW ... > Also, the comment "If you use Borland, ...
    (comp.lang.tcl)