Bug #124794 for Tk: WidgetDemo.pm indexed but not in @INC

Fri Mar 16 22:20:30 2018 KENTNL [...] cpan.org - Ticket created

Subject:

WidgetDemo.pm indexed but not in @INC

https://metacpan.org/permission/distribution/Tk

Show quoted text

WidgetDemo TKML NI-S SREZIC
This however installs to $INC[...]/demos/widget_lib/ , which is not in any standard @INC

The demo in https://metacpan.org/source/DUNNIGANJ/Tk-CursorControl-0.4/demos/cursor.pl uses this library, but its not arranged to actually work as it doesn't do any @INC fiddling to make it possible, but it clearly has some sort of weak-dependency on the one in Tk.

Not sure where the right place for this to get fixed is.

Its also worth pointing out that as a vendor packager, I'd typically nuke Tk/demos/* from installing to @INC at all, and make them install in our vendor directory for those sorts of things, besides where we store documentation and soforth.

In such a scenario, promoting WidgetDemo to a real @INC library would be helpful, given the horse has kind of bolted on it being indexed.

--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )

Fri Mar 16 22:30:48 2018 KENTNL [...] cpan.org - Correspondence added

mm, I see how it works now, but its still of zero use beyond install-time, which really makes all the effort to stash the script in question in @INC kinda useless:

https://metacpan.org/source/DUNNIGANJ/Tk-CursorControl-0.4/Makefile.PL#L34-35

If you can't realy run the program without the makefile around, why install the program?

--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )

Sat Mar 17 06:44:07 2018 SREZIC [...] cpan.org - Correspondence added

On 2018-03-16 22:30:48, KENTNL wrote: Show quoted text

> mm, I see how it works now, but its still of zero use beyond install- > time, > which really makes all the effort to stash the script in question in > @INC kinda > useless: > > https://metacpan.org/source/DUNNIGANJ/Tk-CursorControl- > 0.4/Makefile.PL#L34-35 > > If you can't realy run the program without the makefile around, why > install the > program?

WidgetDemo is used by the "widget" demonstration program, which is normally installed together with Tk. 3rd party modules may add their own demonstrations to this program. This is explained in "widget" itself (under "User Contributed Demonstrations" > "1. Learn how to write your own widget demonstration."). And Tk::CursorControl's own demo is visible as "CursorControl, Manipulate the cursor programmatically." after full installation. -- Slaven

Sat Mar 17 06:44:09 2018 The RT System itself - Status changed from 'new' to 'open'

Sun Mar 18 03:35:29 2018 KENTNL [...] cpan.org - Correspondence added

On 2018-03-17 23:44:07, SREZIC wrote:
> WidgetDemo is used by the "widget" demonstration program, which is
> normally installed together with Tk. 3rd party modules may add their
> own demonstrations to this program. This is explained in "widget"
> itself (under "User Contributed Demonstrations" > "1. Learn how to
> write your own widget demonstration."). And Tk::CursorControl's own
> demo is visible as "CursorControl, Manipulate the cursor
> programmatically." after full installation.
>
> -- Slaven

Ah. I see, that changes things. I'll have to muse over this to work out how to best please our users requirements.

Do you have any opinion on this demo system not being available conditionally?

Because we're source based, I *could* provide a toggle switch that defaults "off", which when "off" would strip the demo system, that way only users who actively want the demos would turn it on, and users who simply install pTk as a dependency save a few bytes.

I get the impression also that a different location might be "nice" if we're trying to organise things more along linux standards, instead of being restricted to the sorts of paths available to the CPAN installer toolkit, .... but doing so would probably be more work for me than its worth.

Part of this motivation is to avoid package collisions, because our package manager system forbids two packages from overwriting each others files, but:

Tk-CursorControl installs "widtrib/cursor.pl", which Tk also installs. ( This is presently resolved by renaming to cursor_control.pl during install )

Tk-TableMatrix attempts to install an auto/Tk/pTK/extralibs.ld file, which is also in Tk as well ( a blank file ), and we currently work around this by nuking it from the Tk-TableMatrix preinstall image.

I get the impression some sort of libexec-like location would normally be in order, and it might be helpful to organise demo files by their providing package name in a sort of layout that the widgetdemo program can make sense of, eg:

libexec/TkWidgetDemo/Tk / <current contents of Tk/demos>
libexec/TkWidgetDemo/Tk-CursorControl/ .....
libexec/TkWidgetDemo/Tk-TableMatrix/ ....

I'm probably overthinking a lot of this, but something I've said might be a starting point for a good idea.

--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )

Sun Mar 18 13:16:23 2018 SREZIC [...] cpan.org - Correspondence added

On 2018-03-18 03:35:29, KENTNL wrote: Show quoted text

> On 2018-03-17 23:44:07, SREZIC wrote:

> > WidgetDemo is used by the "widget" demonstration program, which is > > normally installed together with Tk. 3rd party modules may add their > > own demonstrations to this program. This is explained in "widget" > > itself (under "User Contributed Demonstrations" > "1. Learn how to > > write your own widget demonstration."). And Tk::CursorControl's own > > demo is visible as "CursorControl, Manipulate the cursor > > programmatically." after full installation. > > > > -- Slaven

> > Ah. I see, that changes things. I'll have to muse over this to work > out how to > best please our users requirements. > > Do you have any opinion on this demo system not being available > conditionally? > > Because we're source based, I *could* provide a toggle switch that > defaults > "off", which when "off" would strip the demo system, that way only > users who > actively want the demos would turn it on, and users who simply install > pTk as a > dependency save a few bytes. > > I get the impression also that a different location might be "nice" if > we're > trying to organise things more along linux standards, instead of being > restricted to the sorts of paths available to the CPAN installer > toolkit, .... > but doing so would probably be more work for me than its worth. > > Part of this motivation is to avoid package collisions, because our > package > manager system forbids two packages from overwriting each others > files, but: > > Tk-CursorControl installs "widtrib/cursor.pl", which Tk also installs. > ( This > is presently resolved by renaming to cursor_control.pl during install > )

Tk introduced cursor.pl in 2006, while Tk-CursorControl did it much earlier. So I think I should rename Tk's version to something else (predefined-cursors.pl or so). Also, it's probably a good idea to recommend that CPAN module authors should name their demo file in an unambiguous way, e.g. by prepending the distribution name as a prefix or so (Tk-Getopt's demonstration file is named tk-getopt.pl, which is probably safe from collisions). I'll put this also on my TODO list. Probably it's a little bit overkill to add a hierarchical structure here, and probably it's also a little bit late, as there's currently not much work on Tk modules these days. Show quoted text

> Tk-TableMatrix attempts to install an auto/Tk/pTK/extralibs.ld file, > which is > also in Tk as well ( a blank file ), and we currently work around this > by > nuking it from the Tk-TableMatrix preinstall image. > > I get the impression some sort of libexec-like location would normally > be in > order, and it might be helpful to organise demo files by their > providing > package name in a sort of layout that the widgetdemo program can make > sense of, > eg: > > libexec/TkWidgetDemo/Tk / <current contents of Tk/demos> > libexec/TkWidgetDemo/Tk-CursorControl/ ..... > libexec/TkWidgetDemo/Tk-TableMatrix/ .... > > I'm probably overthinking a lot of this, but something I've said might > be a > starting point for a good idea. > > > -- > - CPAN kentnl@cpan.org > - Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )