Idea Delivered

This will be available with the XPP 9.4 version release.

xyPerl: fix lookup for shared perl functions (modules), should be 1. current job, 2. style library, 3.syslib, 4. xpp perl folder

The lookup for CSS imported modules (the @import things) is the normal style lookup sequence 1. current job, 2. style library, 3.syslib.
And that allows you to 'share' common CSS settings among similar style bundles in a nice and convenient way.
(which is by the way a big plus when working with CSS compared to working with IF stylesheets).

It would be nice to have xyPerl work in the same way.
In similar styles you probably want to share 'perl functions' in the same way as you do with CSS settings.
Or even have perl functions (e.g. frills processing loops) that can be used by any of the styles you have.
(and yes this could be done by putting your perl module in the xpp perl folder, but that folder is not accessible from the pathfinder interface, so not a convenient place)

'Sharing' common things in a perl environment is done through using perl modules.
Modules are called in into the main xyPer program using a 'use' statement.
Perl will lookup a module based on the paths in the @INC array.
It would be nice if XPP could add the current job, the style library and the Lsyslib to the @INC for us.

Currently we can more or less do this ourselves but we need to hard code the style library name in the main xyPerl as inside composition we do not know what is the style library for a particular job.

Things would work a lot better if XPP can manipulate the @INC for us.

REMARK:
it would also be nice if there would be a possibility to force XPP to reload the perl modules you use in your main xyPerl.
Currently you need to store/exit and reopen the division in order to make this happen.
and that is very uncool while you are developing your shared functions.

Bart Terryn
Parents

  • Tinkering a bit further on the question from Paul regarding the @INC ...

    So Paul found that @INC contained: 
    D:\XPP\xz/perl
    ..
    D:\XPP\sd_liz\Lbills
    D:\XPP\sd_liz\Lsyslib
    D:/XPP/xz/perl/site/lib
    D:/XPP/xz/perl/vendor/lib
    D:/XPP/xz/perl/lib

    I do not know what is the exact reason to put the xz/perl folder as the first.
    It does mean that we can not override any of the modules that are delivered in that folder.
    But maybe that was exactly the intention of engineering in order to protect us from shooting in our own foot?
    Maybe Jonathan or Steve want to comment?

Comment

  • Tinkering a bit further on the question from Paul regarding the @INC ...

    So Paul found that @INC contained: 
    D:\XPP\xz/perl
    ..
    D:\XPP\sd_liz\Lbills
    D:\XPP\sd_liz\Lsyslib
    D:/XPP/xz/perl/site/lib
    D:/XPP/xz/perl/vendor/lib
    D:/XPP/xz/perl/lib

    I do not know what is the exact reason to put the xz/perl folder as the first.
    It does mean that we can not override any of the modules that are delivered in that folder.
    But maybe that was exactly the intention of engineering in order to protect us from shooting in our own foot?
    Maybe Jonathan or Steve want to comment?

Children
  • in reply to Bart Terryn

    Hmm ... I think that's a valid question.

    It does seem somewhat inconsistent in how the lookup rules differ between lookup of (main) Perl scripts, versus the lookup rules for Perl modules.

    For (main) Perl scripts (.pl) it's:
    JOB
    Style Lib
    System Lib
    xz/perl

    But as you've noted for Perl modules (.pm) it's:
    xz/perl
    JOB
    Style Lib
    System Lib
    (more locations)

    Of course, there are other differences since Perl script (.pl) lookup is done directly by XPP and does not use @INC, and Perl module lookup does use @INC - which also has the "standard" Perl module paths after the ones XPP adds (and I thought "." was supposed to also be added by XPP with newer version of Perl at the very end of @INC to mimic the behavior of older versions of Perl).

    It's possible it was done this way for Perl module lookup for the reason you stated, but that does mean that (customer) Perl modules that were previously placed in xz/perl (because it was the only XPP location available at the time) will not (or cannot) be overridden by a same named module placed in the JOB or Lib locations - unless the module is removed from the xz/perl location which then doesn't let that location be a "fallback" location for that (customer) Perl module.

    That could be considered user-unfriendly by some, although it could be said that there are "contending" considerations.  Slight smile

    Steve Piercey, any thoughts on this?

  • in reply to Jonathan Dagresta

    I will just open a ticket on this and mark it as a 'bug'.
    I see no reason why the lookup sequence for .pl files would be different than for .pm files.
    It just adds confusion.

    (still engineering could have a very good reason for this...)

    PS: I did not get an email that you (Jonathan) had answered my latest comment. The email notifications do not seem to work all the time....