Menu
▾
▴
tclish-devel — for people who want to conspire... er, contribute
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(17) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Steve C. <ste...@mq...> - 2001-07-29 13:49:23
|
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>................ |
|
From: Kris R. <kr...@kr...> - 2001-07-23 01:06:07
|
> 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 |
|
From: Steve C. <ste...@mq...> - 2001-07-22 23:12:50
|
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 |
|
From: Steve C. <ste...@mq...> - 2001-07-22 23:12:08
|
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 |
|
From: Donald G P. <dg...@em...> - 2001-07-22 14:53:27
|
> 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 | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Steve C. <ste...@mq...> - 2001-07-22 13:09:43
|
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 |
|
From: Steve C. <ste...@mq...> - 2001-07-22 12:48:14
|
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 |
|
From: Peter F. <pet...@zv...> - 2001-07-19 09:05:40
|
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
Pet...@zv... +------------------------+---------------------
Ph. +61 8 92036380 | Mobile +61 417 906 851 | Fax +61 8 92036380
|
|
From: Georgios P. <pe...@ii...> - 2001-07-19 08:43:50
|
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 |
|
From: Peter F. <pet...@zv...> - 2001-07-19 08:05:34
|
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 Pet...@zv... +------------------------+--------------------- Ph. +61 8 92036380 | Mobile +61 417 906 851 | Fax +61 8 92036380 |
|
From: Steve C. <ste...@mq...> - 2001-07-17 13:28:39
|
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 |
|
From: Steve C. <ste...@mq...> - 2001-07-17 13:28:23
|
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 |
