Bugs item #1162286, was opened at 2005-03-12 22:59
Message generated for change (Comment added) made by dgp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1162286&group_id=10894
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 38. Package Manager
Group: development: 8.5a4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Hemang Lavana (hemanglavana)
Assigned to: Don Porter (dgp)
Summary: Inconsistent Tcl_PkgRequire return values
Initial Comment:
Hi,
The documentation for "package" command recommends that
"package provide <pkg> <ver>" should be at the bottom
of the library. However, most users are not aware of
the problem that can occur if the "package provide" cmd
is at the top of the library. This is illustrated in
the following example:
hlavana-u5:138> cat foo.tcl
# foo.tcl
package provide foo 0.9.1
proc foo args {puts "PRINT: foo"}
set a ;# syntax error: var a is not defined
hlavana-u5:139>
hlavana-u5:139> cat pkgIndex.tcl
# pkgIndex.tcl
package ifneeded foo 0.9.1 [list source [file join $dir
foo.tcl]]
hlavana-u5:140>
hlavana-u5:140> cat run_foo.tcl
# run_foo.tcl
catch {package require foo} out1
puts "First time=$out1"
catch {package require foo} out2
puts "Second time=$out2"
hlavana-u5:141>
hlavana-u5:141> tclsh run_foo.tcl
First time=can't read "a": no such variable
Second time=0.9.1
hlavana-u5:142>
This example shows that a script might end up thinking
that the package foo has been loaded successfully even
though there were errors in loading it.
Moreover, most users like to see the "package provide
.." command appear at the top of the library even after
I have explained this issue to them. Note that many of
the packages in tcllib module have the "package
provide" command at the top of the script.
To overcome these problems, I would like to request an
enhancement: whenever "package require ..." fails to
load correctly, it should internally invoke "package
forget <pkg>".
This specific solution does have one side-effect
though: consider that package foo, version 0.9 has been
successfully loaded and the script is trying to load
package foo, version 1.1. If foo1.1 is not found, then
blindly calling "package forget foo" will
unload(forget) foo0.9 as well which is not correct.
I hope this issue can be resolved in the tcl-core
instead of asking users to move "package provide"
command to the bottom of the library.
Hemang.
----------------------------------------------------------------------
>Comment By: Don Porter (dgp)
Date: 2005-11-16 12:55
Message:
Logged In: YES
user_id=80530
Attached patch makes Tcl 8.4.12
more forgiving of the
package ifneeded foo 1 {package provide foo 1.1}
category of error, because reportedly
a very large number of deployed
packages need such forgiveness. :P
Not committing the patch right now.
Just wanted it available in case it's
determined that the pending Tcl 8.4.12
release must have it.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2005-11-09 10:02
Message:
Logged In: NO
Hi,
You also need to delete the following lines (in case you
haven't already fixed it) from the package man page:
http://www.tcl.tk/man/tcl8.4/TclCmd/package.htm
---
When writing a package implementation, you should put the
following at the bottom of your library script so it is only
called once the package has been successfully set up:
package provide foobar 1.0
---
Hemang.
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2005-11-08 13:42
Message:
Logged In: YES
user_id=80530
that was an intentional backport
of a set of related tests,
namespace-25.7,8 and pkg-2.25,26 .
----------------------------------------------------------------------
Comment By: Hemang Lavana (hemanglavana)
Date: 2005-11-08 13:38
Message:
Logged In: YES
user_id=81875
The 8.4 patch contains two tests for namespace cmd which I
suspect are not related to this bug. Rest of the changes
look fine to me -- I have verified it on solaris2.8 with
tcl8.4 version.
Hemang.
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2005-11-08 13:29
Message:
Logged In: YES
user_id=80530
patches committed
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2005-11-08 13:04
Message:
Logged In: YES
user_id=80530
here's the corresponding patch
for 8.4
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2005-11-07 16:42
Message:
Logged In: YES
user_id=80530
ok, the original report was one
case of several where the
value returned by Tcl_PkgRequire
could be inconsistent with the
state of the package database.
Please review this patch against
HEAD for taking care of these
matters (with tests).
----------------------------------------------------------------------
Comment By: Hemang Lavana (hemanglavana)
Date: 2005-11-04 11:56
Message:
Logged In: YES
user_id=81875
Packages should never have circular dependencies. If these
can be easily detected, circular dependencies should be
always reported as error.
Here's another (modified) example where detection of
circular dependencies will improve/aid debugging:
% package ifneeded foo 1 {
package require bar 1
package provide foo 1
}
% package ifneeded bar 1 {
package require foo 1
package provide bar 1
}
% package require foo
too many nested evaluations (infinite loop?)
%
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2005-11-04 09:59
Message:
Logged In: YES
user_id=80530
Before applying that patch:
% package ifneeded foo 1 {
package require bar 1
package provide foo 1
}
% package ifneeded foo 2 {
package provide foo 2
}
% package ifneeded bar 1 {
package require foo 2
package provide bar 1
}
% package require foo 1
conflicting versions provided for package "foo": 2, then 1
% package provide foo
2
After the patch:
(... same setup ...)
% package require foo 1
conflicting versions provided for package "foo": 2, then 1
% package provide foo
%
In this situation, there could now be
a weird mixture of foo 1 and foo 2 now
loaded in the interp. It makes a bit
more sense not to claim one version or
the other, so the patch helps a bit.
However, the error message seems
misleading. Perhaps would be better
to explictly detect and report circular
dependencies?
comments?
----------------------------------------------------------------------
Comment By: Hemang Lavana (hemanglavana)
Date: 2005-11-03 16:30
Message:
Logged In: YES
user_id=81875
Excellent. Your patch works fine for me. Hope this can be
committed to 8.4 branch.
Thank you.
Hemang.
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2005-11-03 15:48
Message:
Logged In: YES
user_id=80530
Give this patch a try.
As the comment in the
patch notes, this looks more
like a bug than a feature
request, because of the
inconsistent return values
of repeated calls to
Tcl_PkgRequire.
----------------------------------------------------------------------
Comment By: Hemang Lavana (hemanglavana)
Date: 2005-09-16 23:54
Message:
Logged In: YES
user_id=81875
On further thought, tcl interpreter already knows the
explicit version number it is trying to load when evaluating
the body of [package ifneeded ..] cmd. So there should not
be any side-effects if tcl internally invokes "package
forget <name> <version>" right after a failed 'sourcing' of
[package ifneeded] body.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1162286&group_id=10894
|