Why two "http" packages?
Zbiggy
and http 2.7.2.
Why is that? Is it a mistake - or that "lower version" is really required
for something?
--
Z
Gerald W. Lester
Yes, both are required. Some older programs are coded to the the 1.0 API.
The 2.x API is not backwardly compatible to the 1.0 API.
Tcl manages multiple version of packages nicely -- why worry about the fact
that two version are there?
--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+
Zbiggy
> Tcl manages multiple version of packages nicely -- why worry about the fact
> that two version are there?
Well, the "management" mentioned above in fact isn't that nice; I had much
trouble today trying to find out, what actually is going on. I'll try to
reproduce my steps, that led to the problem.
Does there exist a list of packages, that are in need of that very old
version of http package?
--
Z.
Gerald W. Lester
Are you using package require?
If so what arguments are you giving it?
Larry W. Virden
> Does there exist a list of packages, that are in need of that very old
> version of http package?
Note that there are hundreds of thousands of lines of tcl code in the
world - no one maintains a list of every program that every developer
ever wrote in tcl.
The remark about there being code dependant on http 1.0 did not
necessarily mean "there are popular tcl packages being distributed
every day that are dependant on http 1.0". It just meant that people
have written programs depending on the behaviors of http 1.0.
Zbiggy
> Are you using package require?
>
> If so what arguments are you giving it?
I reproduced my steps; I was trying an example taken from Wiki:
#v+
% package require vfs::urltype
1.0
% package require vfs::http
0.6
% vfs::urltype::Mount http
Mounted at "http://"
% set fd [open http://sourceforge.net/projects/tcl]
invalid command name "::http::geturl"
#v-
But if - at the very beginning - I started with "package require http"
(got 2.7.2), it properly responds with "mem0" as the "handle".
Further investigation shows, that vfs::http loads old version of http
package, although for proper functionality (see above) it needs that
NEWER one:
#v+
% package require vfs::http
0.6
% package present http
1.0
#v-
--
Z.
Zbiggy
> The remark about there being code dependant on http 1.0 did not
> necessarily mean "there are popular tcl packages being distributed
> every day that are dependant on http 1.0". It just meant that people
> have written programs depending on the behaviors of http 1.0.
Are there any other packages, "by default" installed in two different
versions at the same time (without any explicit user requirement for this)?
--
Z.
Gerald W. Lester
That would depend on what distro you are using. If you are compiling Tcl
yourself and doing a "bare bones" intallation, then only the following
packages are installed:
encoding - Manipulate encodings
http - Client-side implementation of the HTTP/1.0 protocol
msgcat - Tcl message catalog
platform - System identification support code and utilities
platform::shell - System identification support code and utilities
As for myself, I have several versions of a lot of packages installed --
particularly tcllib and the WS:: packages.
Zbiggy
> As for myself, I have several versions of a lot of packages installed --
> particularly tcllib and the WS:: packages.
So you are aware, that you've got packages in several versions; IMHO no
package should be installed "by default" in two version at the same time,
without explicit user requirement. So the installation of http 1.0 should
be one of "configure" options, with default set to "no".
--
Z.
Don Porter
That's nonsense. One of the strengths of Tcl's packaging system is the
fact that it does handle selection among several installed versions of
one package to meet the requirements declared by the program. It would
be foolish to behave as if we did not have this capability.
If some Tcl code has gotten into trouble by getting http 1.0 when it
really needs http 2+ to function, then the bug is in that Tcl code
failing to make its version requirements known. Fix the bug.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Zbiggy
> That's nonsense.
What is "nonsense"? Letting the user decide, whether he wants to risk
getting into trouble - or not?
> One of the strengths of Tcl's packaging system is the
> fact that it does handle selection among several installed versions of
> one package to meet the requirements declared by the program. It would
> be foolish to behave as if we did not have this capability.
Just gave you an example, that sometimes it works as expected, but sometimes
not.
> If some Tcl code has gotten into trouble by getting http 1.0 when it
> really needs http 2+ to function, then the bug is in that Tcl code
> failing to make its version requirements known. Fix the bug.
Not sure, what it's depending on. When I type "package require http" - I've
got the expected, newest version. When the same command is issued by
vfs::http package - the old version is loaded.
I used the workaround by changing the command there to "package require http
2.0".
--
Z.
Gerald W. Lester
Because something is saying:
package require http 1.0
Please read the package require man/help page to understand why it loads 1.0
and not 2.*.
Zbiggy
>> Not sure, what it's depending on. When I type "package require http" - I've
>> got the expected, newest version. When the same command is issued by
>> vfs::http package - the old version is loaded.
>>
>> I used the workaround by changing the command there to "package require http
>> 2.0".
>
> Because something is saying:
>
> package require http 1.0
No. There isn't any "1.0".
--
Z.
Don Porter
>> If some Tcl code has gotten into trouble by getting http 1.0 when it
>> really needs http 2+ to function, then the bug is in that Tcl code
>> failing to make its version requirements known. Fix the bug.
>
> Not sure, what it's depending on. When I type "package require http" - I've
> got the expected, newest version. When the same command is issued by
> vfs::http package - the old version is loaded.
>
> I used the workaround by changing the command there to "package require http
> 2.0".
That's not a "workaround", it's a bug fix. Code that requires
version 2 of a package should ask for version 2 of a package.
Zbiggy
> That's not a "workaround", it's a bug fix. Code that requires
> version 2 of a package should ask for version 2 of a package.
Maybe I'm wrong(?), but IMHO code issuing "package require http" (with no
version given explicitly) wants NEWEST AVAILABLE version of package.
Am I wrong?
--
Z.
Don Porter
Yes, you are wrong.
[package require foo $requirement] will deliver some version of foo
that satisfies the $requirement. If the [package] database knows about
multiple versions that all satisfy, then it will pick the latest, but
if it knows about only some subset of installed packages, and something
in that subset satisfies the requirement, it will not go looking for
something newer.
Zbiggy
> Yes, you are wrong.
>
> [package require foo $requirement] will deliver some version of foo
> that satisfies the $requirement. If the [package] database knows about
> multiple versions that all satisfy, then it will pick the latest, but
> if it knows about only some subset of installed packages, and something
> in that subset satisfies the requirement, it will not go looking for
> something newer.
It seem, that some bad guy wrote incorrect(?) statement into the docs:
"If multiple versions are suitable the implementation with the highest
version is chosen".
If you didn't notice yet: there was just plain "package require http" in
that package - and nothing more. No conditions were examined.
OK, I reported the problem - what else can I do.
--
Z.
Don Porter
> It seem, that some bad guy wrote incorrect(?) statement into the docs:
>
> "If multiple versions are suitable the implementation with the highest
> version is chosen".
Again, the key distinction is that this selection is made among the
versions *that [package] knows about*. If it has never had reason to
discover that another version is available for finding, it will not
take its possible presence into account when it does not need to in
order to satisfy the requirement.
In order to meet your apparent expectations, every [package require]
would be forced to perform a complete new search for versions of the
package just in case something newer is available.
Much better to fix the broken programs that are not telling [package]
about the requirements they have. [package require http] means "I'll
take any version you have." It is not the fault of [package] that it
believes what it is told.
> If you didn't notice yet: there was just plain "package require http" in
> that package - and nothing more. No conditions were examined.
>
> OK, I reported the problem - what else can I do.
I hope you mean you reported it to the authors of the code who have
a bare [package require http] in their program. That's where the fix
needs to be done.
Patrick Dunnigan
Donal K. Fellows
> What file is the package database stored stored in?
>
It's not. It's stored in memory. It's built at runtime by the unknown
package handler which is called the first time a package is encountered
in [package require] which isn't already in the in-memory database. It's
built by sourcing (in a special environment) all the pkgIndex.tcl files
on the list of directories in the global $auto_path variable (and maybe
also their direct subdirectories; I forget exactly what's going on
there). Tcl modules are also (from 8.5 onwards) supported, though they
have a different indexing scheme (no sourcing required AIUI).
A benefit of this is that a pkgIndex.tcl file can deal with non-trivial
requirements for a package (e.g., "this only works on Windows 7").
Donal.