I would like to (and forgive me if this has been beaten to death already)
propose that going forward a site_lib directory be included in the library
search path, where user contributions can be put.
I have a patch for 2.0.13 to add this directory.
I think it is only logical as there is the local directory for the web ui in
which we are encouraged to place our customizations, so I think that it
is only natural to by default provide a place for user modules that is safe
from upgrades.
If any are interested in the patch (not that it was that hard to make) let me
know.
I bring this up now because the new version of StockAnswers has a class module
that the UI uses to find the templates. As such I have put this in the
RT::AddOn namespace. I certainly don’t want to write my install process to
stick this module in the lib/RT directory, nor do I really want to put it in
the perl library directory. I would appreciate any input as could be
helpful. Any opinions are welcome. And if you just want to flame me,
well I guess I can’t stop you =]
Thanks for the feedback,
-Michael
Your perl site_lib exists for this sort of purpose. I’d recommend packaging
addon modules with h2xs…
3.0 will likely have a local/lib which corresponds to local/WebRT
-jOn Tue, Jun 11, 2002 at 08:54:28PM -0500, Michael Grubb wrote:
I would like to (and forgive me if this has been beaten to death already)
propose that going forward a site_lib directory be included in the library
search path, where user contributions can be put.
I have a patch for 2.0.13 to add this directory.
I think it is only logical as there is the local directory for the web ui in
which we are encouraged to place our customizations, so I think that it
is only natural to by default provide a place for user modules that is safe
from upgrades.
If any are interested in the patch (not that it was that hard to make) let me
know.
I bring this up now because the new version of StockAnswers has a class module
that the UI uses to find the templates. As such I have put this in the
RT::AddOn namespace. I certainly don’t want to write my install process to
stick this module in the lib/RT directory, nor do I really want to put it in
the perl library directory. I would appreciate any input as could be
helpful. Any opinions are welcome. And if you just want to flame me,
well I guess I can’t stop you =]
Thanks for the feedback,
-Michael
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
Your perl site_lib exists for this sort of purpose. I’d recommend packaging
addon modules with h2xs…
3.0 will likely have a local/lib which corresponds to local/WebRT
We keep thinking about implementing this here; as we considered it last,
we decided that it should be as easy as creating the directory and
adding a “use lib” statement to everything in the bin directory. (and
then we solve the problem some other way 
Is it not that simple?
Thanks!
–j
Jim Meyer, Geek At Large purp@wildbrain.com
Locally, yes. it’s somewhat more of a pain to build into the build system,
etc. Why are you opposed to using your site_perl?On Wed, Jun 12, 2002 at 09:53:28AM -0700, Jim Meyer wrote:
On Tue, 2002-06-11 at 18:58, Jesse Vincent wrote:
Your perl site_lib exists for this sort of purpose. I’d recommend packaging
addon modules with h2xs…
3.0 will likely have a local/lib which corresponds to local/WebRT
We keep thinking about implementing this here; as we considered it last,
we decided that it should be as easy as creating the directory and
adding a “use lib” statement to everything in the bin directory. (and
then we solve the problem some other way
Is it not that simple?
Thanks!
–j
Jim Meyer, Geek At Large purp@wildbrain.com
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
- Jim Meyer purp@wildbrain.com [2002-06-12 12:54]:> On Tue, 2002-06-11 at 18:58, Jesse Vincent wrote:
Your perl site_lib exists for this sort of purpose. I’d recommend packaging
addon modules with h2xs…
3.0 will likely have a local/lib which corresponds to local/WebRT
We keep thinking about implementing this here; as we considered it
last, we decided that it should be as easy as creating the directory
and adding a “use lib” statement to everything in the bin directory.
(and then we solve the problem some other way
Is it not that simple?
It is, more or less, as long as youo grok how Perl handles package
naming.
I’ve gotten in the habit of putting local modifications into the RTx::
namespace, and making standard perl-ish tarballs out of the stuff. The
path to RT is a Makefile.PL parameter:
$ perl Makefile.PL RT=/opt/rt2
$ make
make install
Makefile.PL then does:
my %ARGV = map { split /=/, $_, 2 } grep /=/, @ARGV;
unshift @INC, $ARGV{‘RT’};
I also add a use lib $ARGV{‘RT’} to the top of the RTx:: modules as well
(they get preprocessed during the install step, using the %ARGV).
(darren)
Which is it: is man one of God’s blunders, or is God one of man’s
blunders?
– Friedrich Nietzche
Forgive me I know this is off topic, if you like please reply off list.
As I am not a habitual perl contributor I’m not familiar with the
easiest/fastest way of generating a Makefile.PL file.
I would like to adopt this method as we will have to wait until 3.0
for a “standard” local lib directory.On Wednesday 12 June 2002 15:44, darren chamberlain wrote:
On Tue, 2002-06-11 at 18:58, Jesse Vincent wrote:
Your perl site_lib exists for this sort of purpose. I’d recommend
packaging addon modules with h2xs…
3.0 will likely have a local/lib which corresponds to local/WebRT
We keep thinking about implementing this here; as we considered it
last, we decided that it should be as easy as creating the directory
and adding a “use lib” statement to everything in the bin directory.
(and then we solve the problem some other way
Is it not that simple?
It is, more or less, as long as youo grok how Perl handles package
naming.
I’ve gotten in the habit of putting local modifications into the RTx::
namespace, and making standard perl-ish tarballs out of the stuff. The
path to RT is a Makefile.PL parameter:
$ perl Makefile.PL RT=/opt/rt2
$ make
make install
Makefile.PL then does:
my %ARGV = map { split /=/, $_, 2 } grep /=/, @ARGV;
unshift @INC, $ARGV{‘RT’};
I also add a use lib $ARGV{‘RT’} to the top of the RTx:: modules as well
(they get preprocessed during the install step, using the %ARGV).
(darren)
Forgive me I know this is off topic, if you like please reply off list.
As I am not a habitual perl contributor I’m not familiar with the
easiest/fastest way of generating a Makefile.PL file.
I would like to adopt this method as we will have to wait until 3.0
for a “standard” local lib directory.
The process for creating modules is kinda buried or at least it has been
until the last few years.
h2xs -AXn My::Module::Name
will create
My/Module/Name/Name.pm
My/Module/Name/Makefile.PL
My/Module/Name/test.pl
My/Module/Name/Changes
My/Module/Name/MANIFEST
Adjust Name.pm and test.pl as needed and use
perl Makefile.PL
make dist
to tar up the whole mess.
See ‘man h2xs’ for details; that’s the basic process for creating a skeleton
module and packaging it for distribution. I’ve been meaning to write up the
process of packaging legacy modules but I haven’t had the motivation lately…
– Bob
Howdy!On Wed, 2002-06-12 at 10:02, Jesse Vincent wrote:
Locally, yes. it’s somewhat more of a pain to build into the build system,
etc. Why are you opposed to using your site_perl?
Using a local/lib helps with encapsulation and clarity, both of which
contribute to ease of maintainence of the RT instance; it is also a bit
more convenient and secure than site_perl.
Specifically, using /path/to/rt/local/lib guarantees that anything
closely related to RT is in one place. It places it in a structure
parallel to the originally installed component, which is at once
familiar to a modestly experienced RT admin and simple to traverse for
code maintenance and comparison. It builds upon the Mason local
component root paradigm which is also familiar territory for your
average RT admin.
Finally, it’s an area which is not normally in root’s @INC; this means
that the convenience of allowing non-root users access to local/lib does
not expose the system to unnecessary security risks.
I’m interested enough in having this functionality earlier than 3.0 to
help work out the build issues; if that’s interesting, please feel free
to contact me privately or on the list and we can figure out where to
start.
Thanks!
–j
Jim Meyer, Geek At Large purp@wildbrain.com
These are my feelings exactly,
Well put Jim.
I also lend my talents as they may be in the aid of implementing said changes.On Thursday 13 June 2002 11:31, Jim Meyer wrote:
Howdy!
On Wed, 2002-06-12 at 10:02, Jesse Vincent wrote:
Locally, yes. it’s somewhat more of a pain to build into the build
system, etc. Why are you opposed to using your site_perl?
Using a local/lib helps with encapsulation and clarity, both of which
contribute to ease of maintainence of the RT instance; it is also a bit
more convenient and secure than site_perl.
Specifically, using /path/to/rt/local/lib guarantees that anything
closely related to RT is in one place. It places it in a structure
parallel to the originally installed component, which is at once
familiar to a modestly experienced RT admin and simple to traverse for
code maintenance and comparison. It builds upon the Mason local
component root paradigm which is also familiar territory for your
average RT admin.
Finally, it’s an area which is not normally in root’s @INC; this means
that the convenience of allowing non-root users access to local/lib does
not expose the system to unnecessary security risks.
I’m interested enough in having this functionality earlier than 3.0 to
help work out the build issues; if that’s interesting, please feel free
to contact me privately or on the list and we can figure out where to
start.
Thanks!
–j