ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> tdk
tdk
Re: [TDK] teapots created with conflicting versions
by Andreas Kupries other posts by this author
Jun 4 2007 2:09PM messages near this date
view in the new Beta List Site
[TDK] teapots created with conflicting versions | Re: [TDK] teapots created with conflicting versions
The reason behind the insertion of 'package provide' into the generated
'pkgIndex.tcl' is that the original customer for whom we created TEApot
requested that, with the understanding that the package implementation
itself would not have such a statement. At which point timestamp or not does
not make a difference. (They also will not have a pkgIndex.tcl to scan,
after the initial migration to teapot.txt).

As is, I see only a workaround, which is to remove the 'package provide'
statement from your code.
Removing it from the pkgIndex.tcl would be bad, because then your 'ifneeded'
command has the timestamped version, and your implementation has not, and
that is a bug under Tcl 8.5.

For the future ... Several options come to mind ...

(1) Have a generator option which disables (or enables) the insertion of
'package provide' in the generated "pkgIndex.tcl". Both possible defaults
(insert yes/no) have drawbacks: Insert yes as default means that most
developers will have to specify 'no', after bitten at least once, when using
timestamps. Insert no means that our original customer has to change their
operation.

(2) More complex, but feasible (*): Scan the package implementation and
check if it does its own 'package provide' or not. If it doesn't, insert a
provide statement in the generated 'pkgIndex.tcl'. If it does, don't insert,
and disable timestamping to prevent a conflict between generated index and
untouchable implementation. Note: This scan has to happen when generating,
not when we generate teapot.txt. Because if we store such information in the
teapot.txt it gets easily out of sync with the actual implementation.
Note: While this is mainly about zip archives it is also relevant to Tcl
Modules. While they have no pkgIndex.tcl their filename contains their
version and must not get out of sync with a provided version.
Note: When doing that scan we also have to check an implementation provided
version against 'teapot.txt', these two might become out of sync for that
case too. This is not possible in the originial customers setup as the
implementation doesn't provide a version, and as such can't get out of sync,
the teapot.txt is the master information source.


(*) Given that we already do something similar in the 'scanner'
functionality.
--
        Andreas Kupries <andreask@[...].com> 
        Developer @ http://www.ActiveState.com
        Tel: +1 778-786-1122


  -----Original Message-----
  From: tdk-bounces@[...].com
[mailto:tdk-bounces@[...].com]On Behalf Of Brandt, Joe
  Sent: Monday, June 04, 2007 1:31 PM
  To: tdk@[...].com
  Subject: [TDK] teapots created with conflicting versions


  When creating a teapot with tclpe it is required that you have a
pkgIndex.tcl to scan the package automatically.  In the final product it
ignores your pkgIndex.tcl file and creates its own.  In this created
pkgIndex.tcl it is doing a "package provide" statement for the package.  I
also have a "package provide" statement inside my own code calling out the
same rev.  This does not call out the same rev when you use the "timestamp
the version" option, you get a warning about "conflicting versions provided
for package .".



  Is there a better way to create these to avoid the duplicate "package
provide" statements or should we just not worry about this warning?



  NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply email and
destroy all copies of the original message.
Thread:
Joe Brandt
Andreas Kupries
Joe Brandt

Privacy Policy | Email Opt-out | Feedback | Syndication
© 2004 ActiveState, a division of Sophos All rights reserved