Requiring package from inside procs

[Victor Wagner]

I'm thinking about idea of requiring package not the from top level of
my package, but from some proc of this package.

Reason is - package has some optional functionality, which would be used
only by some users. And this functionality requires additional package
(say, base64).

If I require base64 package from top level of my package script, all
users of my package would need to have it available (yes, most of us
have tcllib anyway, but there are wrapped single-file applications).

If I require this package only from procedure which uses it,
applications, which do not use this procedure, would happily live
without this additional package.

But, then if application uses this procdure and package is not
available, error would be detected not on the application startup, but
only when procedure is invoked. At this time application might spent
considerable time (and user waste considerable effort) to produce
results which cannot be properly saved without this procedure.

Other way around is to split my package into two parts, one of which
uses third party package and second doesn't.

What do you, think of these options?

--

[Pa_McClamrock]

I think the first one (waiting until the procedure is invoked) would be
really bad, and the second (splitting the package) would involve
unnecessary work. Try something like this on startup (obviously,
substituting the name of your package and your function for "bogomips"
and "Bogo-X"):

package require Tk
if {[catch {package require bogomips} errmess]} {
tk_messageBox -message "$errmess\nThis application\
needs package \"bogomips\" to perform function Bogo-X.\
Other functions will work properly without\
package \"bogomips.\"" -type ok
}

David McClamrock

[Uwe Klein]

Victor Wagner wrote:
> I'm thinking about idea of requiring package not the from top level of
> my package, but from some proc of this package.
>
> Reason is - package has some optional functionality, which would be used
> only by some users. And this functionality requires additional package
> (say, base64).

What about going through all requirements at the beginning, setting some flags
and then going the autoconf way:

if {$have_hyperduper} {
create super_hyperduper
package provide super_hyperduper
} else {
foreach f $functions_that_would_require_hyperduper {
grayout $f
balloon_help $f "this would require $hyperduper to be installed"
}
}

uwe

[Don Porter]

Victor Wagner wrote:
> Reason is - package has some optional functionality, which would be used
> only by some users. And this functionality requires additional package
> (say, base64).

<options snipped>

> What do you, think of these options?

I think the base64 package is widely available: part of tcllib,
part of ActiveTcl, part of the Mac "BI" distribution.

Given that, you ought to just [package require base64] at startup.

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

[keithv]

Victor Wagner wrote:
> I'm thinking about idea of requiring package not the from top
> level of my package, but from some proc of this package.

I've been doing this for years with no problems.

I don't usually do it that way but there are instances when I
feel you get a cleaner solution by keeping all the pieces of
a given feature together in one part.

Another benefit can be a slightly faster start up time.

Keith

[Victor Wagner]

Don Porter <d...@email.nist.gov> wrote:
> <options snipped>
> > What do you, think of these options?
> I think the base64 package is widely available: part of
> tcllib, part of ActiveTcl, part of the Mac "BI" distribution.
> Given that, you ought to just [package require base64] at

On most Unix systems people don't use ActiveTcl even if it is available
for given platform.

They use system provided Tcl and Tk packages. You will be surprised to
know how many distribution out there do not provide tcllib package, or
provide outdated version.

On Windows system I cannot expect user to download and install
ActiveTcl. And even cannot distribute it with my application without
purcashing a commercial license.

Anyway it is disk space hog.

Moreover, on Windows I always use my custom patched build of Tcl.

Typically there is either proper installshield installer which installs
Tcl with some packages and my application(s), or freewrapped
self-contained executable.

First way is used if either there are several applications, to avoid
clobbering user's disk with multiple copies of Tcl/Tk, or application
needs some compiled extensions. I hate the idea of binary executables
(dlls) which are written on disk during program execution and then
loaded into program - it is dangerous race condition. So, only things
which are executable directly from vfs can be wrapped.

But there is set of extensions which are suitable for most applications.

I think that following set of packages covers most cases of Windows
automation:

1. tcom
2. Michael Schwartz's printer extension
3. Winhelp extension
4. Tile (to make interface look like native)
--
Anybody want a binary telemetry frame editor written in Perl?
-- Larry Wall in <1997080122...@wall.org>

[Don Porter]

Don Porter <d...@email.nist.gov> wrote:
>> I think the base64 package is widely available: part of
>> tcllib, part of ActiveTcl, part of the Mac "BI" distribution.
>> Given that, you ought to just [package require base64] at

Victor Wagner wrote:
<Rejects that advice>

1) I wonder why people ask a question when they don't want to hear
the answer?

2) In any of the situations you describe, I believe you will be
doing the users a great favor to get them to install the base64
package via any of the distributions noted above.

> On Windows system I cannot expect user to download and install
> ActiveTcl. And even cannot distribute it with my application without
> purcashing a commercial license.
>
> Anyway it is disk space hog.

I find that claim ridiculous.

What are we paying these days? A penny for 10 MB? The world is
awash in storage space.

Anyhow, my fallback advice since you reject encouraging your users
to install a complete Tcl environment for themselves is for you
to use any of the single-file deployment solutions to just include
all the packages you need as part of the application you provide.

But really, for good effectiveness, app writers just need to get
in the habit of using packages, and expecting them to be available.

<snipped lots more without reading>