[Tclish-devel] An extension installer

[Steve Cassidy <steve.cassidy@mq...>]

I've just whipped up a prototype extension installer for tcl as a first step 
in putting together an installer library.  My code retrieves a zip file from 
a remote site and unpacks it to an appropriate place; it's very simple but 
then this isn't a hard problem, just one that requires agreement.


I've started a wiki page [Tcl Based Installers]: 

http://mini.net/tcl/1896.html

You can download my source from:

http://www.shlrc.mq.edu.au/~steve/tcl


-- 
Steve Cassidy............SHLRC, Macquarie University, Sydney, Australia
...............<URL: http://www.shlrc.mq.edu.au/~steve>;................

Re: [Tclish-devel] Re: Installer applications

[Kris Raney <kris@kr...>]

>   

Steve Cassidy wrote:

> package install tcllib
> 
This is great, but I'd like to see it as a totally separate layer that 
sits on top the installer. Basically, I'd like all the installation of 
tcl-related stuff be just a specific case for a generalized installer. 
The "package install" command would invoke the install libraries to 
handle the interactive aspects of the install, but to the installer 
itself this is just Yet Another Package to be installed, where the fact 
that it's a tcl extension is totally irrelevant.

The installer should be sufficiently customizable to make it seems like 
it knows all about tcl, but all that knowledge should be customization, 
not built in. We can make the tcl-related customization available with 
the tool as a matter of course, but someone who's not using TCL should 
still be able to use the installer for their application.

So I think our effort should be divided into layers something like this:

4. high level tcl commands (like "package install" - or what about 
"package update" to keep things current?) that hide all the dirty work 
of finding, downloading, and installing tcl packages.
-----------------------------------------------------------------
3. A set of customizations, (or plugins or whatever you want to call it) 
that set up the generalized installer to know where to look for tcl 
packages, to understand things like TEA, etc.
-----------------------------------------------------------------
2. A generalized, highly customizable (but easy to configure) installer 
that has no obvious ties to TCL from the point of view of the casual 
user. It should be able to install from CDROM or via download, and 
should provide a simple means of checking for updates a la red-carpet. 
It should probably work in either a GUI or non-GUI environment. It would 
be nice if the install could be scripted, so it could for example be run 
automatically on several machines, after answering the questions one time.
-----------------------------------------------------------------
1. A set of libraries (probably in tcllib) that support the job of doing 
installs - like creating a single-file statically linked executable that 
doesn't need TCL already installed, editing windows registry, updating 
RPM database, downloading/resuming download of large tarfiles, etc.


In addition to these, we might want to provide a user-friendly 
application to help create an install for general applications, or for 
tcl extensions

-- 
Kris Raney

Re: [Tclish-devel] Re: Installer applications

[Steve Cassidy <steve.cassidy@mq...>]

On Monday 23 July 2001 00:53, Donald G Porter wrote:
> > For a non-gui version are you imagining something like:
> >
> > package install tcllib
> >
> > which could then be invoked from package unknown in some circumstances
> > (although not by default I think).
>
> If you're coming to OSCON, see my Friday talk, "Fulfilling the promise
> of [package unknown]" for a proposal along these lines.
>
> If not, I'll follow up here after I get back.


I won't be unfortunately, please report back here with anything relevant. 

Steve

Re: [Tclish-devel] Installer modules -- gui stuff

[Steve Cassidy <steve.cassidy@mq...>]

On Thursday 19 July 2001 19:05, Peter Farmer wrote:
>
> > ** package installergui, Tk installer elements
> >  - Provides a framework for a graphical installer with the standard GUI
> >    elements like package selectors, directory selectors etc.
>
> installer widgets ... check 8-).  Possible including :
>  ... lots of good suggestions...
>
> also perhaps :
>
> ** package/file retrieval library - FTP/HTTP/WEBDAV/RSYNC/CVS?
>    - probably some good packages already that just need to
>      be bundled together with some glue to create the API
>    - if such a beast doesnt already exist (Perl already
>      has a good one) it can be an extension/package
>      in its own right.

tclish uses the existing http package for this, George uses the FTP package. 
I can see a benifit in a CVS interface but are others interesting?? I guess 
that if we can provide an interface which uses HTTP/FTP then others could be 
added by those with an interest in providing that kind of repository. One 
other useful protocol might be HTTPS and theres already a package which does 
this for us.

Another useful function will be to be able to verify a digital signature so a 
general interface to an encryption library would be useful.


> not to forget tcllib
> hmm - Whats needed is a thorough survey of what TCL code is out there
> before inventing our new wheels ...
> Oh for "CTAN" 8-)

Hopefully we can between us remember or find code that's been announced.

Steve

Re: [Tclish-devel] Re: Installer applications

[Donald G Porter <dgp@em...>]

> For a non-gui version are you imagining something like:
> 
> package install tcllib
> 
> which could then be invoked from package unknown in some circumstances 
> (although not by default I think). 

If you're coming to OSCON, see my Friday talk, "Fulfilling the promise
of [package unknown]" for a proposal along these lines.

If not, I'll follow up here after I get back.

| Don Porter          Mathematical and Computational Sciences Division |
| donald.porter@...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [Tclish-devel] Installer modules

[Steve Cassidy <steve.cassidy@mq...>]

On Thursday 19 July 2001 19:05, Peter Farmer wrote:
>
>    - interface to the TEA build system

I'd rather see this the other way around: an interface from TEA to the 
installer.  I guess that what you mean here is that the installer can query 
the TEA config.status or tclConfig.sh to find useful bits of information. I 
have a script that does this as does your installer.  I think this would be 
most useful as part of a TEA support library which can be invoked to write a 
config file for the installer for a project.  



>    - de/compression utils

You mention a tcl only unzipper later, how feasable do you think this is? 
The mkZipLib extension is C but should be very portable and is quite small.  



>    - comprehensive filesystem abstraction layer ?
>      - especially determing available filespace,

Very good point, how doable is this. I imagine it would need a call to a 
system routine on Mac and Win, of course on Unix you can df. Is there another 
way on non unix platforms?

>        checking/setting access permissions,
we have [file stat...]

>        handling case-insensitive filesystems,
I guess you should be warned if your package contains names that might clash 
under some O/S. So some kind of package verifier would be needed.

>        handling mangled namespaces (like fat16)

Must we...;-(

>
>    - filesystem recursers/crawlers, file search
>    - file renaming (based patterns/regexps)

>    - system level "config repository" abstraction layer ?
>      (for Windows Registry/Ini files, Unix system config files etc)
>    - user level "config repository" abstraction layer ?
>      (Windows Registry, Unix ~/. files etc)

I'd be in favour of leaving this alone unless someone can come up with a good 
x-platform solution.  We can provide tools to make these things easier to set 
up and suggest standard recipes for x-platform installation.  

>    - config file parsing tools & geneartion tools
>      (maybe serialization tools that feed into a DOM driven update
> engine
>       and then xslt files to generate the updated native file ?)

See the comments above, I really think that the simpler this config file can 
be the better.  A simple tcl only extension consisting of one source file 
should have a package description file which is trivial to write and 
comprehend once written (if it's generated automatically).  Those used in 
tclish and your tclxml installer are just about right in my mind.


>    - internationalisation support - beyond just UTF 8 capability.
>    - some sort of key-variable management system that
>      is aware of relationships/dependencies between themselves
>      and propagates the changes through the dependancy chain.

I'm not sure I get these.


I'll cut this here and comment on the rest in another msg.

Steve

Re: [Tclish-devel] Re: Installer applications

[Steve Cassidy <steve.cassidy@mq...>]

On Thursday 19 July 2001 18:05, Peter Farmer wrote:
> Steve Cassidy wrote:
> > My current feeling is that the following applications should come into
> > being:
> >
> >  A tcl package installer. Able to download and install tcl extensions
> > consisting of either pure tcl code or tcl and shared libraries. This
> > might one day be included in the core distribution.
>
> Yup. immediately useful for most TCL projects. No reason it have A GUI
> version as well.

Jeff Hobbs has just indicated that Active State is on this trail.  I'm not 
sure what the scale of their system will be (I note that Andeas is a 
subscriber to this list though...).  I don't think that this should stop us 
talking about a solution since I think the package description format used 
here should be the same as that for other installer components.

For a non-gui version are you imagining something like:

package install tcllib

which could then be invoked from package unknown in some circumstances 
(although not by default I think). 


> > These should be platform neutral where possible
>
> The main reason I started the tclxml installer was to have a
> crossplatform installation facility. I would hope this project strives
> to be as inclusive as possible. I guess that means coming up with a
> really comprehensive virtualisation of the union of existing platform
> capabilities . It also means allowing plenty of hooks into the process
> to allow quick hacks to support unforeseen platform-specific issues.

Since the major function of an installer is copying files to some location, 
the core functionality should be easy to put into place. On windows there are 
some obvious additional things to want to do, on unix there are some similar 
things that could be done under, eg. Gnome and KDE, on a Mac, there doesn't 
seem to be a lot to do at all. 


> > and configured via a simple
> > package description file such as that used by tclish or the tclxml
> > installer.
>
> cant think of a better way - except maybe "IXML" - eXtensible Installer
> Language ;-) . Steve Ball may have some
> enthusiasm for designing such a beast 8-).

While I'm certainly keen to sell XML, I don't know if it's appropriate here 
just because of the baggage needed to handle it in the installer (although 
the tcl only parser in tclxml is impressively small).  I think what we need 
here is something more like what you already have in your installer which is 
essentially a attribute/value list augmented with tcl code.


> Speaking on Steve Ball's behalf, it would be good to have the general
> designs take into account that we would want it to pug into a future
> x-platform build system with minimum fuss.


I think the relationship to a build system should be considered but it's my 
feeling at the moment that it should be a separate system to the installer. 
There are many systems where building can't take place but installing can 
(eg. most windows systems) and so any required dependancy between a build 
system and the install system is likely to cause trouble.  I really think 
that the install problem is quite a simple one which just needs some agreed 
decisions and shared code. The build problem is much harder.

Steve

Re: [Tclish-devel] Installer modules

[Peter Farmer <peter.farmer@zv...>]

Stev wrote:

> I thought I'd get the ball rolling with some organisational suggestions and a
> brief review of what we already have.
> 
> My current feeling is that we should develop at least two packages in
> addition to whatever installer applications are deemed useful.  These would
> be:
> 
> ** package installerutils, Tcl installer utilities.
>  - This would include useful routines for installation scripts on various
>    platforms.  If possible these should be abstracted away from platform
>    specifics.
> 

Yes modularity will be important. We can always bundle it up (e.g via
Tclkit) to make it simple to use. I am very keen to see abstraction
given max priority.


>  - This package should define the configuration file language/data
>    structures.

seems a reasonable way to start. 
some other possible components :

   - interface to the TEA build system 
   - de/compression utils
   - comprehensive filesystem abstraction layer ?
     - especially determing available filespace, 
       checking/setting access permissions,
       handling case-insensitive filesystems,
       handling mangled namespaces (like fat16)

   - filesystem recursers/crawlers, file search
   - file renaming (based patterns/regexps)
   - system level "config repository" abstraction layer ?  
     (for Windows Registry/Ini files, Unix system config files etc)
   - user level "config repository" abstraction layer ? 
     (Windows Registry, Unix ~/. files etc)
   - config file parsing tools & geneartion tools 
     (maybe serialization tools that feed into a DOM driven update
engine
      and then xslt files to generate the updated native file ?)
   - internationalisation support - beyond just UTF 8 capability.
   - some sort of key-variable management system that 
     is aware of relationships/dependencies between themselves
     and propagates the changes through the dependancy chain.

> 
> ** package installergui, Tk installer elements
>  - Provides a framework for a graphical installer with the standard GUI
>    elements like package selectors, directory selectors etc.
> 

installer widgets ... check 8-).  Possible including :

   - Window manager abstraction for Windoze/Mac Finder/CDE/KDE/Gnome/...
     for API to upate menus, icon bars etc, and maybe even drag & drop
support !!!
   - progress bars and other processing feedback widgets (spinners et.
al.)
   - help system framework for displaying documentation.
   - a widget for visually laying out the filesystem tree of installed
components
     that is updated as parameters are input during installation
process.
   - ???

also perhaps :

** package/file retrieval library - FTP/HTTP/WEBDAV/RSYNC/CVS?
   - probably some good packages already that just need to 
     be bundled together with some glue to create the API
   - if such a beast doesnt already exist (Perl already 
     has a good one) it can be an extension/package 
     in its own right.


> For installerutils there are already some useful routines available:
> 
> ms_shell_setup by Earl Johnson. <url: http://www.erols.com/earl-johnson/>;
>  provides an interface for manipulating file associations on windows.
> 
> RegisterFileType by Kevin Kenny
>  similar to ms_shell_setup for creating associations only.
> 
> progman.tcl by me <url: http://www.shlrc.mq.edu.au/~steve/tcl/>;
>  adding start menu entries via dde on windows.
> 
> tclish
>  defines a configuration file format and a collection of GUI elements based
>  on code from Effective Tcl including a configurable form displayer.  Can
>  grab packages from local directories or archives  or remote archives via
>  http.
> 
> tclxml
>  some overlap with tclish, provides another configuration file format. Can
>  extract some configuration info from TEA config files.
> 
> There are also some relevant packages that might be made use of in an
> installer application:
> 
> freewrap and/or prowrap - packaging up distributions or installers into
> single file applications.
>

I'd prefer tclkit, but I know little about freewrap - probably need to
discuss what features are needed.

> 
> tlink32 - creates shortcuts on windows
> 
> mkZiplib - a simple wrapper around the zip/unzip library, allows unpacking of
> zip files from tcl.
> 

cool. but perhaps it would be better to avoid binary components as much
as possible to maximise portability. A TCL only unzipper is possible.
Would it be viable ? - I dont know.

> I'd welcome some discussion on this partitioning of packages. If there is
> some agreement we should think about what should go into each and begin by
> collecting together what we have and filling in the blanks.
> 

not to forget tcllib 
hmm - Whats needed is a thorough survey of what TCL code is out there
before inventing our new wheels ...
Oh for "CTAN" 8-)

-- 
Peter Farmer            |  Custom XML software   | Internet Engineering 
Zveno Pty Ltd           | Website XML Solutions  | Training & Seminars
http://www.zveno.com/   |   Open Source Tools    |   - XML XSL Tcl
Peter.Farmer@...  +------------------------+---------------------
Ph. +61 8 92036380      | Mobile +61 417 906 851 | Fax +61 8 92036380

[Tclish-devel] My Setup Code...

[Georgios Petasis <petasis@ii...>]

Hi all,

In general I agree with the proposal of breaking things into small
packages (and perhaps sub-packages) like the installerutils and
the GUI related stuff.

My only problem is what the interaction will be with TEA extensions.
Usually, all my extensions are based on TEA, so at least under unix,
I use configure/makefile. Shouldn't we have a way to extract useful 
information from the makefile at least i.e. regarding files that have to
be installed etc.

If we have to also specify things in a configuration file for the installer,
perhaps will lead to (small) problems. Perhaps a script to automatically
create the configuration script from TEA makefiles?

I have tried to develop a cross-platform installer for one of my applications
that followed the following procedure:
It presented a GUI where the user could select things like the Installation 
dirs, etc.
Then under unix, the installer was just a front-end to 
gunzip/tar/configure/make to do the job.
Under windows, again it used gunzip/tar/make to simply install
precompiled binaries. The needed executables came along with the installer.
But I had plans to parse the makefile and extract from it the files that had 
to be copied. Also, I created shortcuts from plain tcl...

Anyway, this introduction was simply because I have attached the code of this
installer. Consider it under tcl licence:-) We can extract and use whatever 
parts of it we may find useful:-) If you think that anything from there 
should be turned into a package, I am willing to extract it...

Regards,

George

[Tclish-devel] Re: Installer applications

[Peter Farmer <peter.farmer@zv...>]

Steve Cassidy wrote:

> 
> My current feeling is that the following applications should come into being:
> 
>  A tcl package installer. Able to download and install tcl extensions
> consisting of either pure tcl code or tcl and shared libraries. This might
> one day be included in the core distribution.
> 

Yup. immediately useful for most TCL projects. No reason it have A GUI
version as well.

>  A GUI installer which can install Tcl/Tk itself and any other application or
> tcl extension (or in fact any file or set of files).
>

Definitely. 

>  A command line installer with the same capabilities as the GUI one.
> 

Most often requested improvement for the TCLXML Installer is a tclsh
only version.

> These should be platform neutral where possible 

The main reason I started the tclxml installer was to have a
crossplatform installation facility. I would hope this project strives
to be as inclusive as possible. I guess that means coming up with a
really comprehensive virtualisation of the union of existing platform
capabilities . It also means allowing plenty of hooks into the process
to allow quick hacks to support unforeseen platform-specific issues.

> and configured via a simple
> package description file such as that used by tclish or the tclxml installer.
> 

cant think of a better way - except maybe "IXML" - eXtensible Installer
Language ;-) . Steve Ball may have some 
enthusiasm for designing such a beast 8-).

Speaking on Steve Ball's behalf, it would be good to have the general
designs take into account that we would want it to pug into a future
x-platform build system with minimum fuss. 

-- 
Peter Farmer            |  Custom XML software   | Internet Engineering 
Zveno Pty Ltd           | Website XML Solutions  | Training & Seminars
http://www.zveno.com/   |   Open Source Tools    |   - XML XSL Tcl
Peter.Farmer@...  +------------------------+---------------------
Ph. +61 8 92036380      | Mobile +61 417 906 851 | Fax +61 8 92036380

[Tclish-devel] Installer modules

[Steve Cassidy <steve.cassidy@mq...>]

I thought I'd get the ball rolling with some organisational suggestions and a 
brief review of what we already have. 

My current feeling is that we should develop at least two packages in 
addition to whatever installer applications are deemed useful.  These would 
be: 

** package installerutils, Tcl installer utilities. 
 - This would include useful routines for installation scripts on various     
   platforms.  If possible these should be abstracted away from platform      
   specifics.  

 - This package should define the configuration file language/data
   structures. 


** package installergui, Tk installer elements
 - Provides a framework for a graphical installer with the standard GUI
   elements like package selectors, directory selectors etc. 


For installerutils there are already some useful routines available:

ms_shell_setup by Earl Johnson. <url: http://www.erols.com/earl-johnson/>; 
 provides an interface for manipulating file associations on windows.

RegisterFileType by Kevin Kenny 
 similar to ms_shell_setup for creating associations only.

progman.tcl by me <url: http://www.shlrc.mq.edu.au/~steve/tcl/>;
 adding start menu entries via dde on windows.

tclish
 defines a configuration file format and a collection of GUI elements based
 on code from Effective Tcl including a configurable form displayer.  Can
 grab packages from local directories or archives  or remote archives via
 http. 

tclxml 
 some overlap with tclish, provides another configuration file format. Can
 extract some configuration info from TEA config files.  

There are also some relevant packages that might be made use of in an 
installer application: 

freewrap and/or prowrap - packaging up distributions or installers into 
single file applications.

tlink32 - creates shortcuts on windows

mkZiplib - a simple wrapper around the zip/unzip library, allows unpacking of 
zip files from tcl.


I'd welcome some discussion on this partitioning of packages. If there is 
some agreement we should think about what should go into each and begin by 
collecting together what we have and filling in the blanks.  

Steve

[Tclish-devel] Installer applications

[Steve Cassidy <steve.cassidy@mq...>]

My current feeling is that the following applications should come into being: 

 A tcl package installer. Able to download and install tcl extensions 
consisting of either pure tcl code or tcl and shared libraries. This might 
one day be included in the core distribution.

 A GUI installer which can install Tcl/Tk itself and any other application or 
tcl extension (or in fact any file or set of files).  

 A command line installer with the same capabilities as the GUI one. 

These should be platform neutral where possible and configured via a simple 
package description file such as that used by tclish or the tclxml installer. 

Steve