K. Wittrock kwittr...@web.de writes:
The subordinate modules are of no use when stand
alone. So there is no use showing them in CPAN. Of course they must
remain included in the tarball that is downloaded by a user.
You can enter filenames/directoryname in the META.yaml that you do not
want
Gabor Szabo ga...@szabgab.com writes:
I am sure you saw that some search results on Google have little avatars
next to them showing the face of the author.
It is done by a little configuration both on the web site of the search result
and on Google+.
Yet another attempt to seduce people into
David Cantrell da...@cantrell.org.uk writes:
I'd love to know what those edge cases are, because I can't think of
any.
My guess is this applies to distributions that contain a number of
modules, some (most) of them not relevant to the end user since they're
internal to the distribution. If you
David Cantrell da...@cantrell.org.uk writes:
I would say that it's actually *useful* to index them all. That way
your dist will show up if people search for 'FLAC' (to pick just one
example), which is probably a Good Thing.
That would be the purpose of keywords. Not indexes by package name.
[BTW, I'm wondering if this thread should be moved to advocacy]
Nicholas Clark n...@ccl4.org writes:
On Sun, Nov 28, 2010 at 08:03:54PM -0800, Jarrod Overson wrote:
Once a full rewrite is on the table it's hard for a team and/or company to
not at least question whether or not perl is the
Ask Bjørn Hansen a...@develooper.com writes:
On 11/24/10 1:23, Nicholas Clark wrote:
The symlink tree is built by scripts, isn't it? Are they available?
So inadvertently we got to test if anyone cared. The answer is no. :-)
I can't say I'm not anyone, but apparently one of very few :( .
--
Aristotle Pagaltzis pagalt...@gmx.de writes:
You don’t want to reach inside an object just
because it happens to be hash-based.
Interesting. For Getopt::Long (that can take an optional hashref as its
first argument) I got explicit requests from users to allow hash based
objects as well.
--
Nadim Khemir na...@khemir.net writes:
- too many apps are not under App::
- too many apps are not on CPAN
That's because CPAN is module-centric and despite the heroic attempts of
me and some others it has been proven impossible to get a concensus on
how to write Perl applications (Real
Eric Wilhelm enoba...@gmail.com writes:
So, say the first half of the innards of foo() are being refactored to
bar(), which will also take the original parameters in the same form:
sub foo {
my $self = shift;
my %bar = $self-bar(@_);
Don't forget SUPER:
sub foo {
my
David Cantrell da...@cantrell.org.uk writes:
Tie::Hash::Vivify is useful for detecting this:
my $hashref = Tie::Hash::Vivify-new(sub {
confess(No auto-vivifying (did you mis-spell
something?)\n.Dumper(\...@_))
});
What's wrong with lock_keys from Hash::Util?
-- Johan
[Quoting Ken Williams, on February 22 2009, 06:55, in Re: autoabbrev algor]
You should have a look at R (http://www.r-project.org/) and its
calling conventions. Named parameters to functions can typically
(though not always) be abbreviated.
How does it handle ambiguousness introduced by
[Quoting Bill Ward, on February 12 2009, 16:15, in autoabbrev algorithm]
Do you know of any Perl module that provides the algorithm used in
Getopt::Long to implement the automatic abbreviation feature? I'd like to
have that feature available for not just command-line arguments, but
subroutine
Hi,
When I try:
$ perl -MCPAN -e install qw(EekBoek)
I get the message Cannot install EekBoek, don't know what it is.
No doubt I screwed up the META.yml, but what?
Any help is appreciated.
-- Johan
[Quoting David Golden, on November 13 2008, 06:33, in Re: CPAN cannot find]
I don't think it has anything to do with META.yml. It doesn't seem to
be indexed into the 02packages file. I would suggest going to PAUSE
and force re-indexing.
Done.
(Then watch the daemon logfile tail for
Burak Gürsoy [EMAIL PROTECTED] writes:
Well... You should either rename this thing or advertise more :)
And reduce the number of prerequisites, if possible.
-- Johan
I just did a
% perl -MCPAN -e shell
cpan install Bundle::CPAN
My config is to install in ~/lib/perl5. So now I have:
lib/perl5/i386-linux-thread-multi/auto/Cwd/Cwd.so
lib/perl5/i386-linux-thread-multi/auto/Digest/SHA/SHA.so
... etc ...
I share my home between different Fedora
Michael G Schwern [EMAIL PROTECTED] writes:
Module::Install is the greatest threat to CPAN stability.
So why not get rid of it?
If it does not provide any relevant functionality that EU::MM and M::B
also provide, it should be possible to convince the author to withdraw
it.
-- Johan
Hi,
I have a dist with a plethora of modules (in directory lib) that are
specific to the application and therefore need not be indexed.
Actually, it is undesired to have them indexed.
I tried to put
provides:
MyApp:
file: lib/MyApp.pm
version: 1.04
no_index:
directory:
-
We all love the CPAN testers and the results publised at
http://testers.cpan.org.
But recently I suddenly saw a big load of failures in one of my
packages. All these failures were for 5.11.0.
Now, 5.11.0 is a development version, and a moving target. A test
failure with blead reveals often more
Jim Schneider [EMAIL PROTECTED] writes:
This should be handled by your release building tool (a feature that
seems an obvious no-brainer, once it's been pointed out that it's
missing).
Yes, and no.
In general, a package has a version associated. For this version
number the release building
The CPAN indexer requires perl modules (and sub-modules) to have a
non-descending VERSION number. RCS/CVS $Revision$ has been invaluable
for that.
Now more and more development is migrating towards VCS that do not
have such a feature (git, svn, hg, ...).
What are the alternatives?
Manually
[Quoting Ivan Wills, on June 16 2008, 09:54, in Re: Template oriente]
As for App::CLI it could do with some
documentation to describe what it does and how to use it.
That would be a most welcome contribution.
-- Johan
Jonathan Rockway [EMAIL PROTECTED] writes:
There are plenty of things that install and run apps on the CPAN.
App::Ack comes to mind. It Just Works, there is nothing special you
need to do.
App::Ack (and all the other scripts that 'just work') require
everything to be installed in the standard
Guy Hulbert [EMAIL PROTECTED] writes:
What about Module::Install ?
I've had several discussions on whether to use EU::MM, M::B or M::I.
It was made very clear to me that M::I is too limited and crippled to
be useful for anything but trivial installs (that are more robustly
dealt with by the
Hi,
I have some modules that depend on external tools, like ghostscript,
mplayer, and mencoder.
Alien seems to be developed to handle dependencies on external
libraries. Could Alien be used for depending on external tools as
well? Or is there a better alternative?
-- Johan
Jonathan Rockway [EMAIL PROTECTED] writes:
Module::Install has a requires_external_bin keyword for this.
Interesting...
-- Johan
Eric Wilhelm [EMAIL PROTECTED] writes:
my $date = today + 3*years + 3*months + 3*days;
Careful, that may not be the same as 'today + 3*days + 3*months +
3*years'.
Yikes!
The caveat may apply if today is any day = 28 -- if we run
out of days in the destination month, we stop at the
Bill Ward [EMAIL PROTECTED] writes:
What worries me is someone's gonna submit an otherwise useful module
to CPAN that uses this feature.
Unfortunately, that is inherent to the nature of CPAN.
Personally, I have to reject many potential useful CPAN modules
because they use a plethora of other
Eric Wilhelm [EMAIL PROTECTED] writes:
IMO, shortcuts for typing long things will lead us to Eclipse.
And precisely, what's wrong with that?
ducks
-- Johan
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] writes:
unless I read it wrong, it doesn't provide the feature relative.pm
was written for in the first place, that is loading modules using
names relative to the current one.
If I understand correctly, that would be
use import __PACKAGE__;
--
Eric Wilhelm [EMAIL PROTECTED] writes:
Cute, but doesn't it break programs that already use non-ascii (e.g.,
Latin1)?
How?
Because it's no different from the utf8 pragma:
$ cat t.pl
my $x = ë;
$ perl -w t.pl
$ perl -Mutf8 -w t.pl
Malformed UTF-8 character (unexpected continuation
Mattia Barbon [EMAIL PROTECTED] writes:
I sent them an email to their cpan.org
addresses more than a week ago and got no answer,
A week is a rather short term, especially in the holiday season.
-- Johan
D. Huggins [EMAIL PROTECTED] writes:
I have created a module that will allow you to create neatly
formatted, text based reports that contain any number of tables of
various dimensions replete with configurable optional titles, column
headings, decorations, sorting, column alignment and more.
Andy Lester [EMAIL PROTECTED] writes:
I'm trying hard to get people to stop saying script when referring
to their Perl programs. I'd prefer that we not use it anywhere at all.
Back to 'applications' then.
-- Johan
Eric Wilhelm [EMAIL PROTECTED] writes:
[...] that things which will be installed in a directory named
bin/ should have a namespace named bin::?
I want to clearly separate a CPAN location and a namespace. Small
applications usually do not have (nor need) a private namespace.
'helloworld' is an
Eric Wilhelm [EMAIL PROTECTED] writes:
I've found that it is much easier to test and refactor programs which
are not written against the left margin in package main.
You are free to do it like this.
Here's an example of the skeleton which I currently use.
Yes, I have several of those as
Dominique Quatravaux [EMAIL PROTECTED] writes:
Application:: is nearly pristine right now and that's why I proposed
it in the first place, but I understand that it's a bit of a mouthful
(or typeful?).
I think Application (or Applications) is a good idea. Its length does
not really matter
Andy Lester [EMAIL PROTECTED] writes:
I don't see how Application:: is any better than App::. It seems
like change for the sake of it.
A. It is not Application:: (in the sense of a Modules namespace). It
is a place (destination) to put applications.
B. App:: is already in use as a
Eric Wilhelm [EMAIL PROTECTED] writes:
+1 what Andreas said. If you have a big application, take a TLNS.
Although this implies sharing all your application specific modules to
the whole world. This may not always be desirable.
(Think of the recent mess created in core Perl by adding all
Eric Wilhelm [EMAIL PROTECTED] writes:
Perl informally reserves lowercase module names for 'pragma' modules
like integer and strict. Other modules normally begin with a capital
letter and use mixed case with no underscores (need to be short and
portable).
1. that's an informal
Jonathan Rockway [EMAIL PROTECTED] writes:
Why don't y'all just use Module::Install?
Because it doesn't perform a mere install, as the name suggests. It
builds, meaning it requires (and uses) a build environment -- and
scares away customers that do not want to have a build environment on
Greg Matheson [EMAIL PROTECTED] writes:
It seems there is no good solution.
Yes, there is, but unfortunately not always easy: use the platform
package manager. If, e.g., you create an RPM or DEB for your module +
script, package management will take care of the rest.
-- Johan
Hi,
Often I get questions like 'can I get access to XXX internal property
of Getopt::Long' or 'can I get a list of all options' and things like
that. So I will try to open the Getopt::Long internals via an API.
Currently, you can associate an anonymous sub (code reference) to an
option, so that
Gabor Szabo [EMAIL PROTECTED] writes:
The change that might be the most important for most of the module authors is
that from now you can subscirbe to e-mail alerts to any module based
on your PAUSEID. That includes any future modules as well.
Good job!
In addition there is an RSS feed for
Ken Williams [EMAIL PROTECTED] writes:
The fact that they made their contribution in the first place, and
people found it useful, seems like it should be honored rather than
vilified.
I agree fully.
That said, there ought to be a way for the community to move forward
without having the
Paul LeoNerd Evans [EMAIL PROTECTED] writes:
Any suggestions on who I should ask about this?
According to the PAUSE administration, everything is set up as it
should.
I sent you a test mail and have not (yet) seen a bounce.
Did you get it?
-- Johan
Ovid [EMAIL PROTECTED] writes:
isn't the responsible thing to find a way to get those bug fixes out
there?
First of all, one needs to know that there are bugs. Currently, only
bugs that get reported via RT are automatically transmitted to the
author. That's good. But failed CPAN tests are not
A. Pagaltzis [EMAIL PROTECTED] writes:
That seems wrong. Every module you install contains lists of
dependencies, one list for runtime, one for build-time.
The CPAN shell won’t ask questions about missing dependencies,
that is true. But why does that matter? You have the dependency
lists
Ken Williams [EMAIL PROTECTED] writes:
My intention when I added 'build_requires' to Module::Build was not
to let people avoid downloading building those dependencies, but
rather to indicate that there was no runtime dependency, ...
For this to function properly, the 'build_requires' modules
Adrian Howard [EMAIL PROTECTED] writes:
On 4 Aug 2006, at 14:04, Johan Vromans wrote:
For this to function properly, the 'build_requires' modules (and their
respecitve dependencies!) should all be downloaded and installed in a
temporary location (e.g., blib) and not be installed permanently
no_index/dir 13
no_index/directory 1397
private/directory40
As for dir, I'm three of the 13,
I'm another three of the 13, and I'll switch to 'directory' as of the
next upload.
-- Johan
Eric Wilhelm [EMAIL PROTECTED] writes:
That happens in bin/ as well though, so I think those clashes are
necessary.
Yes, but they're relatively harmless. If App::FooBar and App:BarBlech
both prove an app superapp, then I can choose which one to install.
Okay, I cannot install both apps
Eric Wilhelm [EMAIL PROTECTED] writes:
Should these two classes of modules (those which support applications
and those which are applications) be mixed together like this?
It could be done this way. There is no real convention for
applications, and the scripts archive is a failure.
The only
The uploaded file
Getopt-Long-2.35_01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/J/JV/JV/Getopt-Long-2.35_01.tar.gz
size: 38590 bytes
md5: f63f951c5c7496163ddb83620dc16d82
Changes in version 2.36
---
WARNING -- EXPERIMENTAL CODE AHEAD
[Quoting Paul Johnson, on March 16 2006, 12:22, in Re: RFC: GetoptionsF]
my $result = GetOptions(@opts);
wantarray ? ($result, @ARGV) : $result
wantarray ? ($result, @ARGV)
: @ARGV ? die(...) : $result;
-- Johan
Kurt Starsinic [EMAIL PROTECTED] writes:
The module is clever, but it's not clear to me that it's
practically useful.
I think it could be useful if the new 'can' would only succeed on
public methods (note: not private ones, and also not on non-methods).
This would require a way to tag
Ask Bjørn Hansen [EMAIL PROTECTED] writes:
No, not normal. :-)
I recently found this[1] site. Interesting?
-- Johan
[1] http://www.cs.uu.nl/stats/mirmon/cpan.html
As I've said before, if GetOptions() could be a few-lines wrapper
around the $opt = Getopt::Long-new()... $opt-get([EMAIL PROTECTED]) dance,
this allows the author (of what will most likely be a module if they
want to parse something besides ARGV) to design their own entry
point if need be.
[EMAIL PROTECTED] (Johan Vromans) writes:
[Quoting Sam Vilain, on June 27 2005, 22:56, in Re: Getopt::Long wis]
If passing an array ref first doesn't interfere with the calling
convention, then imho you don't need to change the function name.
Interfere? No, but elegant?
Currently
[Quoting Sam Vilain, on June 27 2005, 11:35, in Re: Getopt::Long wis]
Johan Vromans wrote:
You mean, you are going to pass things like STDOUT, STDERR, ENV and so
on, to every function that may use them? [1]
Global things are intended to be global, I'd say.
This is why code using CGI.pm
[Quoting Orton, Yves, on June 27 2005, 10:17, in RE: Getopt::Long wis]
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
GetOptionsFromArray?
-- Johan
[Quoting Sam Vilain, on June 27 2005, 22:56, in Re: Getopt::Long wis]
If passing an array ref first doesn't interfere with the calling
convention, then imho you don't need to change the function name.
Interfere? No, but elegant?
Currently, GetOptions allows an array ref as the first argument
Martyn J. Pearce [EMAIL PROTECTED] writes:
It does, and it works, and it is a stylistic thing perhaps, but although
global variables can be made to work, the modern phenomenon of function
arguments are very popular.
You mean, you are going to pass things like STDOUT, STDERR, ENV and so
on, to
A. Pagaltzis [EMAIL PROTECTED] writes:
Something like ++ instead of --.
I think thats ugly. Id suggest simply addding another dash [...]
I find it very interesting to note that although we're talking about
quite different semantics, everyone seems to be wanting to stick to
the ancient syntax
A. Pagaltzis [EMAIL PROTECTED] writes:
I dont think it requires sub-modules (and extra files cause
extra slowdown, too), just judicious use of eval STRING to
defer compilation of as much code as possible until its actually
needed.
Are you sure that deferred compilation will actually help? If
A. Pagaltzis [EMAIL PROTECTED] writes:
The other option I can think of is kind of wild: do the
option specification parsing/processing that has to be done on
every invocation, regardless of the user input, just once, and
then cache the results somewhere possibly as Perl code in the
__DATA__
Eric Wilhelm [EMAIL PROTECTED] writes:
Ok. Then my previous argument stands. If the --no- means unset any
hard-coded or config-file defaults, then it shouldn't be evaluated in
command-line order.
Good deduction, but the premise does not hold. --no- does not mean
unset any [...] defaults,
Eric Wilhelm [EMAIL PROTECTED] writes:
Independent of percentages, why disallow --foo --no-foo provided
there's a clear definition of the semantics?
I never suggested that it should be disallowed. Only that it should be
equivalent to '--no-foo --foo'.
That's part of the clearly defined
On Thu, 2005-06-16 at 20:12 -0700, Eric Wilhelm wrote:
The purpose of a negated option is (in all of the usages that I have
seen) to reset any hard-coded or config-file variable.
This is not the purpose, see my other posting.
-- Johan
Eric Wilhelm [EMAIL PROTECTED] writes:
What I'm trying to do with Getopt::Modern here is to establish some
conventions which allow this to happen internally. This saves the
author some code and gives the user a guaranteed consistent experience
with multiple programs.
The debate on the
A. Pagaltzis [EMAIL PROTECTED] writes:
* Johan Vromans [EMAIL PROTECTED] [2005-06-17 17:20]:
I can make this information available, if users would be
interested.
Access to structured data is always nicer than implementing and
re-implemeting a parser for its serialized form.
Would
A. Pagaltzis [EMAIL PROTECTED] writes:
Since were at this: the one thing I still fall back to
Getopt::Std for is small scripts. I love Getopt::Long, but it
incurs a pretty high startup cost. Is there any chance you can
play some deferred compilation cards to make it go faster?
This is one of
Eric Wilhelm [EMAIL PROTECTED] writes:
Because I had originally built that as a wrapper around Getopt::Long, I
had a laundry-list of what didn't work.
This would have been interesting for me to know.
In fact, as I mentioned I would be happy for G::L to have this
functionality, but I doubt
imacat [EMAIL PROTECTED] writes:
[...] But, then, is this whole thread that meaningless?
I don't think so. Many good ideas and suggestions have come by, and
though not all ideas are equally viable, many people spend energy
on communicating ideas -- which is fundamental to open source
software.
Eric Wilhelm [EMAIL PROTECTED] writes:
Maybe we'll even manage to hammer it into a standard.
That would really be nice!
-- Johan
Orton, Yves [EMAIL PROTECTED] writes:
I currently have two projects that address this issue: Getopt::Toolkit
(which is based on Getopt::Long) and Getopt::Long version 3 (which is
a complete redesign, a.k.a. Getopt::Long on steroids). Merging the two
projects into a single new Getopt::Long
A. Pagaltzis [EMAIL PROTECTED] writes:
The most problematic scripts I have is a set thats launched by
GUI events, sometimes in rapid succession.
For purposes like this, I'd write dedicated scripts (e.g., no option
parsing at all), or something simple like a first argument that can be
checked
Eric Wilhelm [EMAIL PROTECTED] writes:
You wouldn't say
--foo --no-foo
if you just meant
--no-foo
Would you?
I think the basic question is, what do you expect from a certain
combination of options and arguments. For example,
--foo arg1 --no-foo arg2
This can be interpreted as:
Eric Wilhelm [EMAIL PROTECTED] writes:
Do you mean to say that 99% of the time (when --foo and --no-foo are
both present) that it is because somebody has an alias with a --foo
flag written into it?
Independent of percentages, why disallow --foo --no-foo provided
there's a clear definition
Eric Wilhelm [EMAIL PROTECTED] writes:
Ok, and maybe I showing my age here, but is *this* where the
negated-options thing comes from? I.E. is this the historic (and
entire) reason for having the 'foo!' syntax in Getopt::Long?
No, it's because of a) defaults. Sometimes a flag is enabled by
Eric Wilhelm [EMAIL PROTECTED] writes:
Please see this essay
http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt
Nice piece of writing, but it contains several flaws. For example:
If your spouse tells you to get tuna and halibut, but not any
other
Linda W [EMAIL PROTECTED] writes:
But from what I hear, I'm on my own --
Not completely.
The cpancd[1] package has the functionality in it to find out the latest
version of a series of versions. Although the package is obsolete
(CPAN won't fit on a CD anymore), this function could be
Graham Barr [EMAIL PROTECTED] writes:
Right. And a grand job he has been doing.
I second this. For a while I've tried to do something sensible with
the registry requests, but failed due to lack of response in times
where feedback was needed (i.e., with ambigous or dubious requests).
So _I_
Eric Wilhelm [EMAIL PROTECTED] writes:
I'm not super happy with the array-reference interface (it assumes a
lot and lines tend to need a lot of re-wrapping), but it gets
everything into one place rather than scattered about and allows the
variables to tell the user their default values (even
my $rounding = 0.01;
GetOptions(
'round=f' = \$rounding,
'help' = sub {usage()},
);
sub usage {
print usage: $0 filename\n;
print options: --round float (default $rounding)\n;
}
END
This will have a nasty side effect, as shown below:
$
[Quoting Pearce, Martyn, on April 8 2004, 09:11, in RE: New module: Scri]
getopt(@getopt_args)
This just calls Getopt::Long::GetOptions (see
Getopt::Long for
details). It automatically adds to the arguments
you give it
some
standard command line
Tim Harsch [EMAIL PROTECTED] writes:
To clarify some offline questions: DRM = Distributed Resource
Manager.
Alas. In a short time from now, it will only be known as Digital
Restrictions Management...
-- Johan
Tim Bunce [EMAIL PROTECTED] writes:
For those modules that are not on the Module List, (i.e., not in
http://www.cpan.org/modules/03modlist.data.gz) and which have a
'significant' existing user base, develop a Fast Track process to
get them added to the Module List.
Good idea, but don't we
Elizabeth Mattijsen [EMAIL PROTECTED] writes:
- Is Devel::Required still a good name then?
No.
And I'd very much like to execute it explictly, instead of implicitly.
E.g.
perl Makefile.PL- generates Makefile
perl -MDevel::Panacea Makefile.PL - updates modules,
Christopher Hicks [EMAIL PROTECTED] writes:
On Mon, 4 Aug 2003, Nicholas Clark wrote:
How much do you hate mailman for all those here is a reminder of your
mailing list memberships messages?
They're only slightly irritating and I get a dozen of them every month.
If they wouldn't show
Iain 'Spoon' Truskett [EMAIL PROTECTED] writes:
Ask the author to update or delete. Or offer to take over maintenance.
Your problems begin when you can't *find* the author.
Maybe a periodic 'ping' to module maintainers (e.g., once every two or
three months) and mark maintainers (and their
Adekunle Olonoh [EMAIL PROTECTED] writes:
I don't mean to be negative, but there are a *LOT* of config-related
modules on CPAN right now and IMHO, the differences you've shown don't
seem to warrant another yet another config module.
With that reasoning, you can purge 80% of CPAN.
Have you
92 matches
Mail list logo
