|
From: Andreas K. <aku...@sh...> - 2008-11-20 02:20:20
|
> >> For non-interactive use the same would fail, but the error message > >> could be extended with a hint about availiable near-matches: > >> > >> can't find package tk (perhaps you meant Tk) > That's not the way the [package require] implementation makes use of > the [package unknown] handler. > As written, [package require tk $requirement] will pass along > arguments "tk" and $requirement (if any) to the [package unknown] > handler. The contract is that the [package unknown] handler should > find packages that match what it was told to look for. If it wants, > it can look for other things too and the default one does, but that > has not been required. Yes. And a big thank you for reminding me of this, as I am currently not adressing this in the TIP at all, and will have to. > So, either we would need to change the contract so that [package > unknown] handlers are expected to search for matching packages of > all cases variations, causing some existing [package unknown] > handlers to become "broken" according to the new standard, I believe I am prefering this over the proposal below. > or [package require] would need to iterate over all the case > variations and call the [package unknown] handler again and again > until at least something satisfying the requirement appeared, or > possibly until all cases were covered. Eh ... n characters, two cases => 2^n possibilities. No. Not liking this at all. Changing the contract ... The standard unknown handler needs no changes, as it inserts everything it finds into the database. The TM handler on the other hand will need modifications, as glob is case-sensitive. Well, maybe not on Windows. -- So long, Andreas Kupries <aku...@sh...> <http://www.purl.org/NET/akupries/> Developer @ <http://www.activestate.com/> ------------------------------------------------------------------------------- |