From @perlpunk

Created by @perlpunk

If you do 'use Foo​::Bar' and get the message 'Can't locate Foo/Bar.pm
in @​INC' this message doesn't tell newbies what to do. They don't see
the connection from Foo​::Bar to Foo/Bar.pm (because they don't know how
modules are internally stored).
There are many questions in perl forums that ask about this issue.
Usually you can solve this by answering that that means Foo​::Bar
isn't installed and link to a site which explains how to install modules.

Could the message 'Can't locate Foo/Bar.pm'be extended to something like
'... (This means that Foo​::Bar probably isn't installed on this machine)'?
I was told in the perl5porters channel that at the point of the error message
the information of the module name might already be lost, but maybe there
is a way to get it.

(Note​: Also 'use diagnostics' doesn't help much here)

Flags:
    category=core
    severity=low

This perlbug was built using Perl v5.8.5 - Fri Oct  1 23:29:33 UTC 2004
It is being executed now by  Perl v5.8.5 - Fri Oct  1 23:24:00 UTC 2004.

Site configuration information for perl v5.8.5:

Configured by abuild at Fri Oct  1 23:24:00 UTC 2004.

Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
  Platform:
    osname=linux, osvers=2.6.8.1, archname=i586-linux-thread-multi
    uname='linux g168 2.6.8.1 #1 smp thu jul 1 15:23:45 utc 2004 i686 i686 i386 gnulinux '
    config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -Wall -pipe'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -Wall -pipe',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe'
    ccversion='', gccversion='3.3.4 (pre 3.3.5 20040809)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =''
    libpth=/lib /usr/lib /usr/local/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.3.3'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.5/i586-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared'

Locally applied patches:
    


@INC for perl v5.8.5:
    /usr/lib/perl5/5.8.5/i586-linux-thread-multi
    /usr/lib/perl5/5.8.5
    /usr/lib/perl5/site_perl/5.8.5/i586-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.5
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.5
    /usr/lib/perl5/vendor_perl
    .


Environment for perl v5.8.5:
    HOME=/home/tina
    LANG=de_DE@euro
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/tina/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/jvm/jre/bin
    PERLDOC=-i
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @Juerd

Tina skribis 2006-10-12 3​:06 (-0700)​:

If you do 'use Foo​::Bar' and get the message 'Can't locate Foo/Bar.pm
in @​INC' this message doesn't tell newbies what to do. They don't see
the connection from Foo​::Bar to Foo/Bar.pm (because they don't know how
modules are internally stored).

Many newbies do get part of the message, but they think it says​: copy a
Foo/Bar.pm into some directory of @​INC. And that's how many people
"install" modules, causing quite a lot of traffic on the diverse help
platforms when a module happens to use something other than pure Perl.

Could the message 'Can't locate Foo/Bar.pm'be extended to something like
'... (This means that Foo​::Bar probably isn't installed on this machine)'?
I was told in the perl5porters channel that at the point of the error message
the information of the module name might already be lost, but maybe there
is a way to get it.

Some heuristics would suffice, I think. For a path that has a slash in
it, translate to :​: notation and suggest the module. For all other
paths, just keep including the .pm.

(Note​: Also 'use diagnostics' doesn't help much here)

I'm afraid that most people don't know about "use diagnostics" and
"perldiag". The error message itself needs to be clear.

I actually think the module complaint should come *before* the path​:

  "Can't load module Foo​::Bar (no Foo/Bar.pm in @​INC)"

"Can't locate loadable object for module Foo​::Bar in @​INC" curiously
does have the :​: notation in it, and also has the user friendly text
first.
--
korajn salutojn,

  juerd waalboer​: perl hacker <juerd@​juerd.nl> <http​://juerd.nl/sig>
  convolution​: ict solutions and consultancy <sales@​convolution.nl>

Ik vertrouw stemcomputers niet.
Zie <http​://www.wijvertrouwenstemcomputersniet.nl/>.

The RT System itself - Status changed from 'new' to 'open'

From @demerphq

On 10/12/06, Juerd <juerd@​convolution.nl> wrote​:

Tina skribis 2006-10-12 3​:06 (-0700)​:

If you do 'use Foo​::Bar' and get the message 'Can't locate Foo/Bar.pm
in @​INC' this message doesn't tell newbies what to do. They don't see
the connection from Foo​::Bar to Foo/Bar.pm (because they don't know how
modules are internally stored).

Many newbies do get part of the message, but they think it says​: copy a
Foo/Bar.pm into some directory of @​INC. And that's how many people
"install" modules, causing quite a lot of traffic on the diverse help
platforms when a module happens to use something other than pure Perl.

Could the message 'Can't locate Foo/Bar.pm'be extended to something like
'... (This means that Foo​::Bar probably isn't installed on this machine)'?
I was told in the perl5porters channel that at the point of the error message
the information of the module name might already be lost, but maybe there
is a way to get it.

Some heuristics would suffice, I think. For a path that has a slash in
it, translate to :​: notation and suggest the module. For all other
paths, just keep including the .pm.

(Note​: Also 'use diagnostics' doesn't help much here)

I'm afraid that most people don't know about "use diagnostics" and
"perldiag". The error message itself needs to be clear.

I actually think the module complaint should come *before* the path​:

"Can't load module Foo​::Bar \(no Foo/Bar\.pm in @​INC\)"

"Can't locate loadable object for module Foo​::Bar in @​INC" curiously
does have the :​: notation in it, and also has the user friendly text
first.

Maybe use should localize a global temporarily to make the module name
available to require. So instead of use Foo​::Bar; being

BEGIN{
  require ....
  import ...
}

it becomes

BEGIN{
  local $^MODULE="Foo​::Bar";
  require ....
  import ....
}

Then extensions could use it themselves to override the message as
they felt appropriate before calling require.

This would also work around the problem that the original name is lost
by the time PP(require) is executed, which is the routine responsible
for this message.

I had a quick look into doing this but its not a part of the perl
internals im very familiar with.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

From @jrockway

Juerd wrote​:

Tina skribis 2006-10-12 3​:06 (-0700)​:

If you do 'use Foo​::Bar' and get the message 'Can't locate
Foo/Bar.pm in @​INC' this message doesn't tell newbies what to do.
They don't see the connection from Foo​::Bar to Foo/Bar.pm (because
they don't know how modules are internally stored).

Many newbies do get part of the message, but they think it says​: copy
a Foo/Bar.pm into some directory of @​INC. And that's how many people
"install" modules, causing quite a lot of traffic on the diverse help
platforms when a module happens to use something other than pure
Perl.

I disagree that "use diagnostics" doesn't help. I think the message is
pretty clear​:

(F) You said to do (or require, or use) a file that couldn't be
found. Perl looks for the file in all the locations mentioned in @​INC,
unless the file name included the full path to the file. Perhaps you
need to set the PERL5LIB or PERL5OPT environment variable to say where
the extra library is, or maybe the script needs to add the library name
to @​INC. Or maybe you just misspelled the name of the file. See
perlfunc/require and lib.

Perhaps mentioning CPAN (and cpan) would help? "You might also try
installing the module from CPAN by typing 'cpan Foo​::Bar'." This opens
up a can of worms, of course. The user might not have permission to
install modules. The user might be better served by using their
distribution's installation method. The user might not be able to
invoke cpan from the command line (Activestate?). The user might not
have make. The user might not have a C compiler. And so on :)

However, referring the user to some relevant documentation might be a
good idea. perlfunc and lib aren't helpful in this case -- cpan and
perlmodinstall would make more sense. My attitude is that if you want
to program, you need to know how to read and think and experiment.
Pointing the user to documentation, therefore, is an excellent idea.
Magically solving the problem for them is just going to lead to worse
problems down the line, like $foo = param('foo'); print `$foo bar`; :)

Regards,
Jonathan Rockway

--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;

From @jimc

Jonathan Rockway wrote​:

Juerd wrote​:

Tina skribis 2006-10-12 3​:06 (-0700)​:

If you do 'use Foo​::Bar' and get the message 'Can't locate
Foo/Bar.pm in @​INC' this message doesn't tell newbies what to do.
They don't see the connection from Foo​::Bar to Foo/Bar.pm (because
they don't know how modules are internally stored).

Many newbies do get part of the message, but they think it says​: copy
a Foo/Bar.pm into some directory of @​INC. And that's how many people
"install" modules, causing quite a lot of traffic on the diverse help
platforms when a module happens to use something other than pure
Perl.

I disagree that "use diagnostics" doesn't help. I think the message is
pretty clear​:

it doesnt help when they dont use it, which is common.

I wouldnt mind seeing the 1st 3 errors verbosified (with the rest left
as is, to not overwhelm)
or maybe -W should spew diagnostics too.

p5p@spam.wizbit.be - Status changed from 'open' to 'stalled'

From @cpansprout

This is now resolved by commit f7ee53b.

@cpansprout - Status changed from 'stalled' to 'resolved'