Menu
▾
▴
tcl-core
|
From: Jeff H. <je...@ac...> - 2006-04-28 22:45:23
|
TIP #268: ENHANCE 'PACKAGE' VERSION HANDLING ============================================== Version: $Revision: 1.1 $ Author: Jeff Hobbs <jeffh_at_activestate.com> Hemang Lavana <hlavana_at_cisco.com> State: Draft Type: Project Tcl-Version: 8.5 Vote: Pending Created: Friday, 28 April 2006 URL: http://purl.org/tcl/tip/268.html WebEdit: http://purl.org/tcl/tip/edit/268 Post-History: ------------------------------------------------------------------------- ABSTRACT ========== This TIP proposes enhancing the Tcl *package* command to understand version numbers containing "a", "b" and "rc". RATIONALE =========== The current Tcl *package* command is limited to understanding package versioning based strictly on an infinite number of dot-separated positive integers. Regardless, Tcl extensions and the core itself use version numbers that have "a" for alpha, "b" for beta and "rc" for release candidate in the version scheme. This proposal seeks to make those identifiers properly understood by Tcl's *package version* semantics. SPECIFICATION =============== *Current version specification:* (Summary of <URL:http://www.tcl.tk/man/tcl8.4/TclCmd/package.htm#M15>) Version numbers consist of one or more decimal numbers separated by dots, such as 2 or 1.162 or 3.1.13.1. The first number is called the /major/ version number. Larger numbers correspond to later versions of a package, with leftmost numbers having greater significance. For example, version 2.1 is later than 1.3 and version 3.4.6 is later than 3.3.5. Missing fields are equivalent to zeroes: version 1.3 is the same as version 1.3.0 and 1.3.0.0, so it is earlier than 1.3.1 or 1.3.0.2. *Recommended version specification adds:* In addition, the letters 'a' (alpha) or 'b' (beta) and/or 'rc' (release candidate) may appear exactly once to replace a dot for separation. These letters semantically add a negative specifier into the version, where 'a' is -3, 'b' is -2 and 'rc' is -1. Each may be specified only once, and 'a' or 'b' are mutually exclusive in a specifier. Thus 1.3a1 becomes 1.3.-3.1, 1.3b1 is 1.3.-2.1, 1.3a1rc1 is 1.3.-3.1.-1.1. Negative numbers are not directly allowed in version specifiers. A version specifier with a negative indicator will not be considered compatible in version comparisons by default, unless a request for a version with a negative indicator is made. This means that 1.4b1 does not satisfy a request for 1.3, but it does satisfy a request for 1.4a1. This allows only final releases to be considered in standard version comparisons. A new subcommand will be added to control the threshold level at which version comparisons operate. *package threshold* ?/threshold/? This subcommand will get or set the current threshold. The /threshhold/ argument (which must be present to set the threshold) must be one of *stable*, *rc*, *beta*, or *alpha* (or a unique prefix), and if unspecified the current threshold is returned. The default threshold will be *stable*, which will result in behavior equivalent to the old style of version number processing (other than the parsing of the extended specification for version numbers, of course). If the threshold is *rc*, then release candidates will also be considered (i.e. version numbers containing no element smaller than -1), if the threshold is *beta* then the minimal element value will be -2, and if the threshold is *alpha* the minimal element value will be -3, allowing the selection of prerelease software of various degrees of stability in version comparisons (and hence commands like *package require*). For example: % package threshold => stable % package vsatisfies 1.5b1 1.4 => 0 % package threshold beta => beta % package vsatisfies 1.5b1 1.4 => 1 % package vsatisfies 1.5a1 1.4 => 0 If you need to do *expr* comparisons, use the *in* operator, like so: % expr {[package threshold] in {stable beta}} => 1 An environment variable (TCL_PKG_THRESHOLD), taking the same value, is also proposed to seed the *package threshold* value. EXAMPLES ---------- Valid version numbers: 1.3a1 1.3a1rc1 Invalid version numbers: 1.3a 1.3a1b2 1.3.a1 DISCUSSION ============ Tcl RFE 219296 proposes similar support with the addition of a *threshold* method to *package*. This proposal operates by modelling the *a*, *b* and *rc* specifiers as negative version specifiers. REFERENCE IMPLEMENTATION ========================== [To be uploaded to SourceForge and URL added to this TIP.] COPYRIGHT =========== This document has been placed in the public domain. ------------------------------------------------------------------------- TIP AutoGenerator - written by Donal K. Fellows |
|
From: <dg...@ni...> - 2006-04-29 04:12:19
|
Quoting Jeff Hobbs <je...@ac...>: > TIP #268: ENHANCE 'PACKAGE' VERSION HANDLING While I'm happy to see a proposal to get alpha/beta version numbers handled, after a first skim, this proposal appears to be derived from a patch I put together a few years back, and I now consider that patch a failed experiment. In particular, I think the [package threshold] command doesn't work well, though if someone (Hemang?) has experience to the contrary and can report that they have been able to use it effectively, I'd like to hear about it. I'll need to read more carefully and review a bit to recall all the details why I came to believe [package threshold] wasn't a good solution, and it doesn't appear I'll have time to do that until next week. In general, to evaluate any proposal regarding [package] one must examine at least the two perspectives of the package author (the [package provide] side) and the package user (the [package require] side). Try to establish examples of how they will use the proposed feature, and whether the new usage patterns are sufficiently useful and sufficiently convienient that they will actually be welcome. My recollection is that [package threshold] failed this test because it became a command that for the [package require] side led to ongoing maintenance to support testing. In practice, if a script has to be modified in order to get tested, then it won't get tested. Rather than control availability of packages to be tested via a [package threshold], I came to the opinion it makes more sense to control availability by installing packges under test in a separate part of the filesystem, and enable/disable their availability by adding/removing that filesystem area from the TCLLIBPATH. I'll try to offer more a clearer, more concrete analysis/criticism when I have time next week. DGP |
|
From: Jeff H. <je...@Ac...> - 2006-04-29 16:13:31
|
dg...@ni... wrote: > Quoting Jeff Hobbs <je...@ac...>: >> TIP #268: ENHANCE 'PACKAGE' VERSION HANDLING > > While I'm happy to see a proposal to get alpha/beta > version numbers handled, after a first skim, this > proposal appears to be derived from a patch I put > together a few years back, and I now consider that > patch a failed experiment. Please reread the TIP carefully. I only read your RFE after hashing out the basic structure, and then made a few small modifications. For one, threshold works differently than your original proposal, and the general design is different. This TIP works on trust levels - you either trust beta (or alpha) quality packages, or you don't. > I'll try to offer more a clearer, more concrete analysis/criticism > when I have time next week. Again, reread the TIP. I didn't like your original proposal either. ;) I believe this varies it enough to be workable. Jeff |
|
From: Hemang L. <hl...@ci...> - 2006-04-30 13:50:22
|
dg...@ni... wrote: > Quoting Jeff Hobbs <je...@ac...>: > >> TIP #268: ENHANCE 'PACKAGE' VERSION HANDLING > ... > > > In general, to evaluate any proposal regarding [package] > one must examine at least the two perspectives of the > package author (the [package provide] side) and the package > user (the [package require] side). Try to establish > examples of how they will use the proposed feature, > and whether the new usage patterns are sufficiently > useful and sufficiently convienient that they will > actually be welcome. > The main purpose of this proposal is to deliver pre-release software to the end user for early testing and make this process as simple as possible. This is achieved as follows: 1. Ask the user to download and install the new package(s) in standard tcl installation path where scripts can find it. End-user should not have to remember the path where such a package is installed. 2. Enable the level of threshold via environment variable TCL_PKG_THRESHOLD to one of "alpha", "beta" or "rc". I don't think asking end-users to modify their scripts to specify the threshold level will be an acceptable solution. Note that this approach does have a limitation: it does not provide a finer level of control over which packages to load at a given threshold level. If there are two beta packages: foo and bar, it will not be possible to enable only foo package. If users need such finer control, they will be recommended to install desired packages under a separate path in the filesystyem which can be added using TCLLIBPATH and specify threshold level as "alpha". For most end-users, I believe that installing under std tcl path and specifying the threshold level via TCL_PKG_THRESHOLD should suffice. Hemang. |
|
From: Neil M. <ne...@cs...> - 2006-04-30 14:44:33
|
Jeff Hobbs wrote: > TIP #268: ENHANCE 'PACKAGE' VERSION HANDLING [...] > A new subcommand will be added to control the threshold level at which > version comparisons operate. > > *package threshold* ?/threshold/? Is this threshold per-interp, or per-application? If the threshold is "alpha", and I have two versions of package "foo", 1.3a1 and 1.2 and I do a [package require foo 1.2], which version do I get? The newer alpha? Or the stable version? Consider: package threshold alpha package require bar 1.1a1 .... forget to reset the threshold ... package require foo 1.2 ;# gets buggy 1.3a1 instead of stable 1.2 Wouldn't it be better to specify the threshold as an option to [package require]? -- Neil |
|
From: Hemang L. <hl...@ci...> - 2006-05-01 15:49:44
|
Neil Madden wrote:
> Jeff Hobbs wrote:
>> TIP #268: ENHANCE 'PACKAGE' VERSION HANDLING
> [...]
>> A new subcommand will be added to control the threshold level at
>> which version comparisons operate.
>> *package threshold* ?/threshold/?
>
> Is this threshold per-interp, or per-application?
I think it should be per-interp. Jeff can correct me if it is going to
be otherwise.
> If the threshold is "alpha", and I have two versions of package "foo",
> 1.3a1 and 1.2 and I do a [package require foo 1.2], which version do I
> get? The newer alpha? Or the stable version?
The new alpha version.
> Consider:
>
> package threshold alpha
> package require bar 1.1a1
> .... forget to reset the threshold ...
> package require foo 1.2 ;# gets buggy 1.3a1 instead of stable 1.2
>
> Wouldn't it be better to specify the threshold as an option to
> [package require]?
As Don pointed out in another e-mail, most users would avoid installing
and trying out pre-release packages if they are required to modify their
scripts to load the package. I think the easiest way to specify the
threshold would be via env variable TCL_PKG_THRESHOLD.
But you raise an interesting scenario: is it necessary to specify the
threshold level to "alpha" if you are explicitly specifying it in the
[package require]? If the following is specified:
package require bar 1.1a1
package require foo 1.2
then the threshold is implicit in the [package require] statement for
the bar and it should only load the stable version of foo package.
Moreover, if bar 1.1b2 is also installed, then it should load the beta
version unless the -exact flag is specified:
package require bar -exact 1.1a1
If this approach seems reasonable then the tip can be updated accordingly.
Hemang.
|
|
From: Hemang L. <hl...@ci...> - 2006-05-01 17:06:19
|
Neil Madden wrote:
> Hemang Lavana wrote:
>>
>> As Don pointed out in another e-mail, most users would avoid installing
>> and trying out pre-release packages if they are required to modify their
>> scripts to load the package. I think the easiest way to specify the
>> threshold would be via env variable TCL_PKG_THRESHOLD.
>
> I don't understand the use-case for TCL_PKG_THRESHOLD, or indeed for
> any application- (or even interpreter-) wide threshold setting. Surely
> you evaluate whether you want an alpha release (to get some new
> feature) on a package-by-package basis? I can't imagine a scenario
> where I'm developing an application and think "I want all the very
> latest bleeding-edge packages, even if I don't actually need the new
> features".
The primary purpose of TCL_PKG_THRESHOLD variable is to allow an
end-user to load pre-release packages without having to modify their
scripts. As for package-by-package evaluation, it is quite possible that
a new feature or a bug fix spans multiple packages. In such cases, it
would involve editing multiple [package require] stmts to load all the
bleeding-edge packages.
Another idea is to explicitly require the end-user to list the packages
(glob-style pattern) to load for every threshold level, see below:
setenv TCL_PKG_THRESHOLD "rc {foo bar*} alpha {log*}"
This implies that it should load release-candidate versions for packages
foo and bar and alpha version for log*. Again, I am mostly interested in
the ability to control threshold level of package loading without
requiring end-users to modify their script.
> The point I was trying to make was that these [package threshold]
> commands could be anywhere, and everywhere. Trying to track down a bug
> because package A set the threshold to alpha and so now package B gets
> a buggy version of package C ... well, it just doesn't sound like fun.
>
> I'd much rather just say
>
> package require -threshold alpha Tcl 8.5
>
> and know that the threshold is confined to that particular statement
> and can't have adverse effects on the rest of the codebase.
>
> BTW, [package require Tcl 8.5] already loads the alpha version.
> However, you state that the default threshold is "stable", which will
> reject alphas. So, will 8.5 become 8.5a4 and thus not be able to be
> required without setting the threshold to "alpha"?
Yes: that's correct. The [package provide Tcl] currently returns "8.5"
which seems to imply that it is a stable version which is not correct.
>> But you raise an interesting scenario: is it necessary to specify the
>> threshold level to "alpha" if you are explicitly specifying it in the
>> [package require]? If the following is specified:
>>
>> package require bar 1.1a1
>> package require foo 1.2
>>
>> then the threshold is implicit in the [package require] statement for
>> the bar and it should only load the stable version of foo package.
>> Moreover, if bar 1.1b2 is also installed, then it should load the beta
>> version unless the -exact flag is specified:
>>
>> package require bar -exact 1.1a1
>>
>> If this approach seems reasonable then the tip can be updated
>> accordingly.
>>
>
> I thought this was already part of the TIP? The discussion of a,b,rc
> being like -3,-2,-1 version numbers gave me the impression that it
> would work like this anyway. If you explicitly ask for an alpha
> version, then it should definitely load it if available, whatever the
> current threshold setting. Again, this seems like another reason to
> just drop the interp-wide threshold setting.
If you have an alternate approach of loading pre-release packages that
does not require modifying scripts, please let us know.
Hemang.
|
|
From: Michael S. <sch...@is...> - 2006-05-01 17:24:30
|
Hemang Lavana schrieb: > If you have an alternate approach of loading pre-release packages that > does not require modifying scripts, please let us know. > How about a TCL_PKG_VERSION_OVERRIDE environment variable, or somethink like it, where you list: pkgName1,versionOld1->versionBleedingEdge1; pkgName2,versionOld2->versionBleedingEdge2 and then have the package require mechanism magically map those versions, so if you do a package require: package require pkgName1 versionOld1 it is interpreted as: package require pkgName1 versionBleedingEdge1 In a generalized form this could even be used to create some kind of 'virtual' packages like those catch all rpms, which just require some kind of httpd but don't specify which exactly. Would massivly simplify those convoluted pkgIndex.tcl files used by things like tclxml, or some of the constructs used by tcllib to load critcl built accelerator commands. Michael |
|
From: Neil M. <ne...@cs...> - 2006-05-01 17:51:37
|
Hemang Lavana wrote: [...] > > The primary purpose of TCL_PKG_THRESHOLD variable is to allow an > end-user to load pre-release packages without having to modify their > scripts. OK. I really don't think that is a good idea. It is the developer of the code surely who decides whether the code relies on bleeding edge features, not the end-user. Again, what's the use-case? Why would the end-user be wanting to load pre-release packages unless they have already modified the script to rely on new functionality? > As for package-by-package evaluation, it is quite possible that > a new feature or a bug fix spans multiple packages. In such cases, it > would involve editing multiple [package require] stmts to load all the > bleeding-edge packages. Generally, I wouldn't expect a bug fix to go into the alpha but not into the stable version, unless it required a redesign of APIs etc. But if that has happened then your end user needs a more substantial script upgrade than just setting TCL_PKG_THRESHOLD to grab a new alpha version. Having to change multiple package require statements doesn't seem like sufficient justification for introducing a global setting which can affect the behaviour of *all* subsequent package requires. [...] >> >>BTW, [package require Tcl 8.5] already loads the alpha version. >>However, you state that the default threshold is "stable", which will >>reject alphas. So, will 8.5 become 8.5a4 and thus not be able to be >>required without setting the threshold to "alpha"? > > Yes: that's correct. The [package provide Tcl] currently returns "8.5" > which seems to imply that it is a stable version which is not correct. Fair enough. It's a potential incompatibility with current 8.5 users though, who will have to be aware of the new theshold stuff if they have scripts that [package require Tcl 8.5] and expect them to work with the alpha versions (I know I do). I think it's probably worth breaking though. -- Neil |
|
From: Jeff H. <je...@Ac...> - 2006-05-01 18:08:12
|
Neil Madden wrote: > Hemang Lavana wrote: > > The primary purpose of TCL_PKG_THRESHOLD variable is to allow an=20 > > end-user to load pre-release packages without having to modify their = > > scripts. >=20 > OK. I really don't think that is a good idea. It is the developer of = the=20 > code surely who decides whether the code relies on bleeding edge=20 > features, not the end-user. Again, what's the use-case? You two are not using the same terms ... Hemang's "end-user" is the = developer of the script, so it is the right person making the decision. > Why would the end-user be wanting to load pre-release packages unless=20 > they have already modified the script to rely on new functionality? What makes you think that new versions only have new functionality? = There are fixes in 8.5 that aren't in 8.4, and that goes with ALL packages. > Generally, I wouldn't expect a bug fix to go into the alpha but not = into=20 > the stable version, unless it required a redesign of APIs etc. But if=20 Uh-oh, this one doesn't hold water for the core, as noted above. Jeff |
|
From: Neil M. <ne...@cs...> - 2006-05-01 22:15:58
|
Jeff Hobbs wrote: > Neil Madden wrote: > >>Hemang Lavana wrote: >> >>>The primary purpose of TCL_PKG_THRESHOLD variable is to allow an >>>end-user to load pre-release packages without having to modify their >>>scripts. >> >>OK. I really don't think that is a good idea. It is the developer of the >>code surely who decides whether the code relies on bleeding edge >>features, not the end-user. Again, what's the use-case? > > > You two are not using the same terms ... Hemang's "end-user" is the developer > of the script, so it is the right person making the decision. OK. But the developer obviously has access to the script in order to put the right [package require] in then, so once again: what is the use-case for TCL_PKG_THRESHOLD or any interp-wide threshold value? >>Why would the end-user be wanting to load pre-release packages unless >>they have already modified the script to rely on new functionality? > > > What makes you think that new versions only have new functionality? There are > fixes in 8.5 that aren't in 8.4, and that goes with ALL packages. Why put a bug fix only into the alpha if it doesn't affect compatibility? If the fix is incompatible with the previous documented usage, then you probably need to alter your script anyway to make use of the fixed code. If it isn't incompatible, then why keep it out of the stable release? But anyway, how does [package threshold] or TCL_PKG_THRESHOLD possibly help in this situation? If the intended end-users are the script developers, how does TCL_PKG_THRESHOLD help them? If they can change their code to add a call to [package threshold] then they can certainly change their [package require]. If they can't change the code, then how do they arrange for an environment variable to be set on their clients' machines? I don't have a problem with adding support for alpha and beta releases to the package mechanism -- it's a very good idea. I just don't see the need for an interp-wide (or is it application-wide?) threshold level. I suspect it will cause more problems than it solves. -- Neil |
|
From: Jeff H. <je...@Ac...> - 2006-05-01 23:06:25
|
Neil Madden wrote: > Jeff Hobbs wrote: > >>>The primary purpose of TCL_PKG_THRESHOLD variable is to allow an > >>>end-user to load pre-release packages without having to modify their > >>>scripts. > > OK. But the developer obviously has access to the script in order to put > the right [package require] in then, so once again: what is the use-case > for TCL_PKG_THRESHOLD or any interp-wide threshold value? Quick testing. > > What makes you think that new versions only have new functionality? > > There are fixes in 8.5 that aren't in 8.4, and that goes with ALL > > packages. > > Why put a bug fix only into the alpha if it doesn't affect > compatibility? If the fix is incompatible with the previous Ah, great question, for which I don't have a great answer. I can only tell you that it happens, and for multiple, unrelated items. Of course, that's with the core, where we try to take care and keep stable lines going as long as possible. When you get to personal package management, it's a totally different case with much more understandable reasons for not being able to keep stable lines going simultaneous to dev. That's where this becomes more important. > I don't have a problem with adding support for alpha and beta releases > to the package mechanism -- it's a very good idea. I just don't see the > need for an interp-wide (or is it application-wide?) threshold level. I > suspect it will cause more problems than it solves. The idea is to have it interp-wide, where TCL_PKG_THRESHOLD (if set) would be seeded (one-time) into each interpreter on creation. If you think it will cause problems, then don't use it. It is intended to be a power-user, watch foot and gun type of feature. Jeff |
|
From: Neil M. <ne...@cs...> - 2006-05-01 23:54:44
|
Jeff Hobbs wrote:
> Neil Madden wrote:
[...]
>>
>>Why put a bug fix only into the alpha if it doesn't affect
>>compatibility? If the fix is incompatible with the previous
>
>
> Ah, great question, for which I don't have a great answer. I can only tell
> you that it happens, and for multiple, unrelated items. Of course, that's
> with the core, where we try to take care and keep stable lines going as long
> as possible. When you get to personal package management, it's a totally
> different case with much more understandable reasons for not being able to
> keep stable lines going simultaneous to dev. That's where this becomes more
> important.
OK, that's certainly understandable. I'm still not really sure how
[package threshold] or TCL_PKG_THRESHOLD helps in this situation, but
I'm prepared to concede that you know much more about this than me.
>
>>I don't have a problem with adding support for alpha and beta releases
>>to the package mechanism -- it's a very good idea. I just don't see the
>>need for an interp-wide (or is it application-wide?) threshold level. I
>>suspect it will cause more problems than it solves.
>
>
> The idea is to have it interp-wide, where TCL_PKG_THRESHOLD (if set) would be
> seeded (one-time) into each interpreter on creation. If you think it will
> cause problems, then don't use it. It is intended to be a power-user, watch
> foot and gun type of feature.
Well, my primary concern is that other packages may use it without me
knowing, and so affect how [package require] works for me. For instance,
if I [package require foo] and foo somewhere does [package threshold
alpha], then my subsequent [package require]s may get alpha versions
where I was expecting stable versions. So even if I don't use the
feature it may still affect my code.
BTW, another alternative that lies somewhere in between the two
approaches would be to let [package threshold] take a block of code and
set the threshold just for the duration of that code block, i.e.:
package threshold alpha {
package require foo 1.0
package require bar 2.1
}
-- Neil
|
|
From: Jeff H. <je...@Ac...> - 2006-05-02 00:13:27
|
Neil Madden wrote:
> Jeff Hobbs wrote:
> > The idea is to have it interp-wide, where TCL_PKG_THRESHOLD (if set) =
> > would be seeded (one-time) into each interpreter on creation. If =
you=20
> > think it will cause problems, then don't use it. It is intended to =
be=20
> > a power-user, watch foot and gun type of feature.
>=20
> Well, my primary concern is that other packages may use it without me=20
> knowing, and so affect how [package require] works for me. For =
instance,=20
> if I [package require foo] and foo somewhere does [package threshold=20
> alpha], then my subsequent [package require]s may get alpha versions=20
> where I was expecting stable versions. So even if I don't use the=20
> feature it may still affect my code.
OK, I am now beginning to understand the concern. The 'package =
threshold' is
not intended to be used by module authors (in the same way that =
tcl_precision
should not have been). That's of course a loose directive, not =
something that
can be enforced.
> BTW, another alternative that lies somewhere in between the two=20
> approaches would be to let [package threshold] take a block of code =
and=20
> set the threshold just for the duration of that code block, i.e.:
>=20
> package threshold alpha {
> package require foo 1.0
> package require bar 2.1
> }
But this is equivalent to:
package require foo 1.0a0
package require bar 2.1a0
and remove the 'a0' when you no longer want allow alpha code. The use =
of the
package threshold is more meta (and thus intended for the script =
author). We
are talking about installations with lots of packages, where you may =
well have
10 versions of a package installed of various quality levels. When you =
make
use of TMs and have other means for managing large repos of extensions, =
the
need for this meta level of control becomes more apparent (and least, =
the
belief in that need ;) ).
Jeff
|
|
From: <dg...@ni...> - 2006-05-01 22:01:35
|
Quoting Jeff Hobbs <je...@ac...>: > An environment variable (TCL_PKG_THRESHOLD), taking the same value, is > also proposed to seed the *package threshold* value. On this point I need some clarification. Will every call to [package] re-examine this environment variable so that its value is always in control? Or does the value of this environment variable merely set an initial threshold value, so that later [package threshold] commands can change it to something else? DGP |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X