>>>>> Mike Miller <mtmil...@ieee.org> writes:
>>>>> On Wed, Oct 16, 2013 at 18:56:33 +0000, Ivan Shmakov wrote:
>> The conventional namespace for application-specific Perl modules is
>> App::⟨package name⟩::⟨module name…⟩.
> Can you give some examples or references?
Perhaps I was a bit mistaken on this one, as CPAN seem to
generally mix module (as in: Local::Example) and distribution
(Local-Example) naming conventions. Still, consider, e. g.:
⋯ ✂ ⋯ https://pause.perl.org/pause/query?ACTION=pause_namingmodules#App ⋯ ✂ ⋯
App
You can distribute applications as Perl distributions. Typically,
those sorts of distributions go under the App namespace, like
App::Ack, App::Cpan, and App::Prove. The namespace implies that
its a ready-to-use program rather than a module.
⋯ ✂ ⋯ https://pause.perl.org/pause/query?ACTION=pause_namingmodules#App ⋯ ✂ ⋯
> I see a few but not enough that I'd call it a convention. As opposed
> to simply $PACKAGE::$MODULE...
I’d expect the latter convention to be followed in the case of
bigger “library-first” projects (like DBD::*, for instance.)
I wouldn’t deem it appropriate to grab a top-level namespace for
less than a handful of modules. (And the Pause’s page quoted
above seem to agree on that.)
[…]
>> Therefore, my suggestion would be to move RlwrapFilter.pm from
>> /usr/share/rlwrap to /usr/share/perl5/App/Rlwrap/Filter.pm, and edit
>> its ‘package’ line (as well as the filters’ ‘use’ lines)
>> respectively. (In order to preserve compatibility, a “redirecting”
>> .pm may be installed at the former location.)
>> This will bring the module in line with the other Perl modules in
>> Debian, and will allow for a Perl filter to be started with simple
>> ‘use App::Rlwrap::Filter;’ instead of the current form, which
>> explicitly the Perl module search path (as shown below.)
> Do you have any other reasons for wanting to make this change, some
> added functionality or benefit that would come from doing this
> reorganization?
Being unfamiliar with rlwrap(1), I’ve implemented a crude but
seemingly useful work-alike in Perl. While I’m not planning to
release it anytime soon (now that I’ve learned that rlwrap(1)
fits my needs more than I’ve initially thought), it’s possible
that it will borrow the rlwrap’s protocol, and thus filters
based on RlwrapFilter.pm will no longer be specific to rlwrap.
Other than that, I’m somewhat concerned with the “hiding” of the
Perl modules done by Debian packages. My guess is that some of
them could very well find certain uses unanticipated by their
respective authors.
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
