How to provide the same package with two names

[Sharad]

Hi

I have a couple of TCL packages developed over a period of time.
The package names started initially with a standard naming convention
but deviated from the standard during the course of development.

I now want to standardize the names keeping the mind the backward
compatibility constraint (as there are users using these libraries).

One of the ways that I could think of was duplicating my code in
pkgIndex.tcl with the new name.
Something like:
Old Code
-----------

package ifneeded x {
.
.
.
package provide x
}

New Code
-----------

package ifneeded x {
.
.
.
package provide x
}

package ifneeded new_x {
. ;# Duplication
.
.
package provide new_x
}

This'll work but will result in code redundancy and will be
problematic from the maintenance perspective as these packages are
frequently updated.

I'm exploring other better ways of doing this. Need the expert advice
of the TCL gurus.

Please let me know the alternate ways of doing this.

Thanks
Sharad

[Arjen Markus]

Why not simply:

pkgIndex.tcl:

package ifneeded X [list source [file join $dir mysource.tcl]]
package ifneeded Xnew [list source [file join $dir mysource.tcl]]

And in mysource.tcl:

package provide X 1.0
package provide Xnew 1.0

... rest of the source ...

There is nothing that says that a particular source file
can contain only one package.

If you do not like this solution though, consider:

package ifneeded X {
source mysource.tcl
package provide X
}
package ifneeded Xnew {
source mysource.tcl
package provide Xnew
}

(That way you have two files and only one containing the actual
code)

Regards,

Arjen

[mark anthony]

On Apr 2, 6:53 am, "Sharad" <sharad1...@gmail.com> wrote:
> Hi
>
> I have a couple of TCL packages developed over a period of time.
> The package names started initially with a standard naming convention
> but deviated from the standard during the course of development.
>
> I now want to standardize the names keeping the mind the backward
> compatibility constraint (as there are users using these libraries).

Lets say you had a package sample and the codefile sample.tcl

I would move sample.tcl to sample-legacy.tcl

replace package provide sample by package provide sample-legacy

Put all the sane code that follows the new guidelines in sample.tcl,
and add package require sample-wrap.

for all procs that do not, put wrapper procs in sample-wrap.tcl
like this or something similar

::proc ::sample::sample { args } {
## old style API
## this overides the wrapper
::package require sample-legacy

## do the request
::eval [::info body ::sample::sample]
}

hope this wrapper works, but i guess you got the idea behind it.

downside, if you stick to a name but change the arg list this
legacy layer does not work. you could also add code to unknown
instead of the wrappers.

uh and dump a warnings to stderr or something

[Don Porter]

Arjen Markus wrote:
> There is nothing that says that a particular source file
> can contain only one package.

That is true, but I would recommend handcrafting your pkgIndex.tcl
files, and not expecting [pkg_mkIndex] to be able to figure such a
thing out.

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

[Glenn Jackman]

At 2007-04-02 12:53AM, "Sharad" wrote:
> Hi
>
> I have a couple of TCL packages developed over a period of time.
> The package names started initially with a standard naming convention
> but deviated from the standard during the course of development.
>
> I now want to standardize the names keeping the mind the backward
> compatibility constraint (as there are users using these libraries).
>
> One of the ways that I could think of was duplicating my code in
> pkgIndex.tcl with the new name.

How about simply:

package ifneeded new_x { package require old_x }

--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry

[Sharad]

Thanks for all the suggestions. Appreciate the quick help.

package ifneeded new_x { package require old_x } is indeed the
simplest solution.
But just a catch, I got a small error "can't find package new_x"
though all the API's of old_x were loaded.

I modified the code as :

package ifneeded new_x $VERSION [ subst -nocommands {
package require old_x $VERSION
package provide new_x $VERSION
}]

and it works.

Thanks again to all for the quick response.

Regards
Sharad

[Sharad]

Another requirement is to make the package names case-insensitive.
So, I'd like to have new_x, New_x, nEw_x, etc (all possible
variations) to point to the same package. One way is to copy the same
code with all these options, but this results in redundant code and
once the package names is long - it'll be troublesome.

Any ideas on this.

Regards
Sharad

[Arjen Markus]

That ought to be simple:

rename package _package

proc package {args} {
set name [string tolower [lindex $args 1]]
lset args 1 $name
eval _package $args
}

(That is, if all subcommands of package that you use
take the package name as the second argument, but most do:
package require/provided/ifneeded)

Regards,

Arjen

[Uwe Klein]

"Overload" the package command.

G!
uwe

[Robert Heller]

This is best done with a specially crafted pkgIndex.tcl file. The
package will have one conanacial name (e.g New_x), but the pkgIndex.tcl
file will have a chunk of Tcl code that has case-folded package
if-needed lines, either explicitly, or generated on-the-fly (whenever the
pkgIndex.tcl file is loaded).

>
> Any ideas on this.
>
> Regards
> Sharad
>
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk

[Don Porter]

Sharad wrote:

> package ifneeded new_x $VERSION [ subst -nocommands {
> package require old_x $VERSION
> package provide new_x $VERSION
> }]
>
> and it works.

My guess is that you'll want to modify that to:

package ifneeded new_x $VERSION [subst {
package require -exact old_x $VERSION
package provide new_x $VERSION
}]

(where the [subst] could really just be done with "" quoting).