Re: linux packaging for Alien::XXX modules
# from Jonathan Yu on Sunday 19 January 2014: >It would be nice if we had a better solution (one that did not require >the cost of a "dummy" Alien module, which results in a pretty >empty-looking package on distributions with binary-only packages, such >as Debian). But, again, this seems to have been the usual approach we >followed historically. Hi Jonathan, If the dependency is in prereqs->build->requires, that shouldn't translate into a binary prereq. So, a distro should be able to skip packaging the alien modules, no? --Eric
Re: please help me name a module
# from Bill Ward on Thursday 12 September 2013: >On Thu, Sep 12, 2013 at 8:56 PM, Greg Lindahl wrote: >> Vehicle:: doesn't generalize very well to toasters, refrigerators, >> etc. If a new top-level name is a good idea, I'd suggest an >> Internet-of-Things top-level, Thing:: or IoT:: or IOT:: >> ... >Thing::Vehicle::Tesla::ModelS? A::Vehicle::Tesla::ModelS I don't think it's strictly necessary to generalize the top-level namespace. Would one be unable to locate the refrigerator interface module without it being filed under "things"? It might be better as Car::Tesla::ModelS or Tesla::ModelS. --Eric -- --- http://scratchcomputing.com ---
Re: Request co-maintainer for Alien
# from Chris Marshall on Friday 30 August 2013: >I've made two email attempts to the module author >and tried to reach him by phone without luck. Hi Chris, I hope you are not using that fotango.com address -- that company is closed. Maybe Artur's @cpan.org address is not updated? Did you try via fastly.com, github.com/crucially, or twitter.com/crucially ? --Eric -- --- http://scratchcomputing.com ---
Re: pod stuff... pod using variables?
# from Linda W on Saturday 16 March 2013: >With the discussion I read at the link above, they were more concerned >about changing the version number in one place for multiple >files. Related issue, but >likely different. Certainly we could all play games with specialized >perl scripts that search for the version in a common location >and patches one or more source files in one or more locations/source >file, but >it that seems a bit inelegant. Though if it bothered me >enough...inelegance is >fine... ;-) You might want to look at Pod::Weaver and/or Dist::Zilla. There is a way to get the pod parser and the perl parser to see the same bytes as both pod and code, but it's not pretty, probably not supported, and might make some people angry if I mentioned it here. --Eric -- --- http://scratchcomputing.com ---
Re: stop shipping MYMETA to CPAN
# from Gabor Szabo on Friday 01 March 2013: >I don't maintain my MANIFEST file manually, but have a MANIFEST.SKIP >file and run "make manifest" before the releases. >As the MYMETA files are new, they were not matched by any of the rules >in the MANFEST.SKIP file. Oh, that's why I didn't see this. If you have a MANIFEST.SKIP file, `make manifest` will just use that instead of its defaults (which now contain MYMETA.yml/json.) If you do `./Build manifest`, you should see: File 'MANIFEST.SKIP' does not include 'MYMETA.json'. Adding it now. Sounds like ExtUtils::MakeMaker and Module::Install should maybe do something similar. Not sure how to explain DDUMONT, but it looks like Module::Build has otherwise done well. https://www.google.com/search?q=mymeta.json+site:metacpan.org+inurl:source+"generated_by: +Module::Build" Thanks, Eric -- --- http://scratchcomputing.com ---
Re: stop shipping MYMETA to CPAN
# from Aaron Trevena on Friday 01 March 2013: >A quick google search shows it in one of my modules blush and github >shows I added it manually and deliberately like an idjit. Thanks for the input. I tend to `>MANIFEST; ./Build manifest` and have a check for that in my publish script. I'm curious whether there are some automated tools doing it wrong or just a lack of compelling enough automated tools. Thanks, Eric -- --- http://scratchcomputing.com ---
Re: in running test on a module -- where is the module ?
# from Linda W on Friday 01 March 2013: >They worked when I ran them in the 't' directory. >... >When I ran it in 't' , the mod was in "../lib"... but not under the >test harness? Hi Linda, Probably chdir .. and try the tests as t/foo.t -- this will be more like what you'll see from `./Build test` because most author tools are going to assume that the root of your dist is the working directory and add blib/lib and blib/arch to your path (or `prove -rl t/ xt/` is going to add lib to your module path and run everything in t and xt.) --Eric -- --- http://scratchcomputing.com ---
Re: stop shipping MYMETA to CPAN
# from Gabor Szabo on Thursday 28 February 2013: >/me is releasing new version of Test::Strict to fix this issue and >going over the >other modules as well. Hi Gabor, How did they get into your MANIFEST in this case? Is there a tool which is tending to do this, or are people adding them manually? Thanks, Eric -- --- http://scratchcomputing.com ---
Re: CPAN testers: failure installing dependencies
# from David Cantrell on Tuesday 06 November 2012: >> So how would I fix the dependency problem if I don't even know about >> it? > >By testing your code before releasing it? ... For the few of my dists >that I care most about,I re-test them every so often to make sure that >CPAN didn't break them. The problem comes after you have released your code and its installability gets broken by a dependency's new bug/failure. In theory, you shouldn't have to retest your code to catch this (and I agree that reporting as a failure against your code is also incorrect.) That said, I would probably opt-in to some e-mail that tells me when a dep revision introduced a failure such that one of my dists became uninstallable, but I could also probably find a way to make that into a cron job using currently available data/APIs. --Eric -- --- http://scratchcomputing.com ---
Re: Module naming and a couple other questions
Hi Josh, # from Joshua Megerman on Friday 14 September 2012: >My initial inclination was to just call the >module WMIClient, but I'm starting to think that WMI::Client or some >other name would be better. The only 2 modules I currently see on >CPAN that provide similar functionality are DBD::WMI and Win32::WMIC, I would say Win32::WMIClient if it only run on windows. If this is a wire protocol, you might consider NET:: (sorry it does not google well for me -- but your libasync_wmi_lib.so mention seems to point away from Win32::.) >2. Said module currently has 1 function, wmiclient, which I was >planning on exporting by default. I see that it's generally >recommended not to do that, In the case of providing one function, it might make more sense to export it by default. One can always disable the import with a `use ... ()`, so nobody is trapped by your decision. But, it is good practice to import functions explicitly or call them with an absolute name because it provides a better answer to "how did this function get into my namespace?" >Can I do that, or do I need to distribute the entire module as GPL... I [am not a lawyer] think you can use copyright law to grant anyone whatever license you like _on the code you wrote_. The GPL will apply to the usage of everything together once they are linked/executed, so your license has to allow for that. >...Is this a problem for distribution via CPAN? No. (I was trying to track down the reference for this and I'm not sure if there's more written on this topic. Basically: as long as your license doesn't prevent it from being freely and widely mirrored and you are not abusing the generosity of the mirrors, it can be on the CPAN.) http://www.cpan.org/misc/cpan-faq.html#Does_CPAN_allow_shareware >4. In order to successfully build this module, you need to have the >WMI library installed and specify the location of the WMI source code >as a parameter to 'perl Makefile.PL' so it can find the necessary >headers (which I'd rather not have to package with the module >source). I have specified this in the README and Makefile.PL, but I >don't know how to handle that requirement via CPAN. A parameter to Makefile.PL is not going to work well with a CPAN client. If you want to make it really smooth for users, take a look at some of the Alien:: modules -- you could perhaps automate the installation with an Alien::WMI package. Alternatively, you could prompt() in your Makefile.PL. >5. I'm only starting to look into testing now, but one of the >requirements for testing this thoroughly will be that information be >passed regarding username/password and machine to test >against. If you must have a live test, maybe use prompt() -- but be aware that you would be storing that password as plaintext as a side-effect of how the makefile/make process works. You might be able to work something into the test action -- prompt just before running the tests and put the password in an environment variable. (I [am biased] would use Module::Build for that level of customization rather than MakeMaker.) --Eric -- --- http://scratchcomputing.com ---
Re: RFC: the Author:: namespace
# from Pedro Melo on Friday 07 September 2012: >... personal modules that don't fit into any other namespace, for >public experimental modules, and for author metadata. >... >You can skip indexing them on search/metacpan, or index them and not >include them on general search results. Make that opt-in. > >You can more aggressively remove old versions. You can delete old >versions to Backpan. Or even send skip sending them at all to Backpan. > >And you can skip them when you create your local CPAN mirror, pulling >only your own namespace. It sounds like you're mostly talking about experimental modules (or experimental forks of existing ones) -- which is not what I would call "personal", so I think that's the wrong term for this discussion (and somewhat loaded/possessive.) I think the notion of using your PAUSE ID as a sub-namespace is pretty well-established for BeLike &c (for better or worse.) As for the plan of having somewhere to put experiments or forks, Author::EWILHELM doesn't seem right, and it's also too long, and what if I wrote it, but at some point in the future, someone else is going to maintain/co-maintain it? This problem of "what to name a fork" is partly an artifact of not having namespace/authority support in require(), no? Why not name the first fork of Foo, X1::Foo and if someone wants to fork it again, X2::Foo, etc? The same could work for experiments like x201209090002.pm If you're tempted to prefix a distribution with your name, why is that? What if we just had a tmp:: namespace and deleted anything in there older than 2 years? I think there's some way to control indexing with meta.ymlson, though one would probably want to go read the mldistwatch code and see. As for what's in a backpan: that's an rsync cron job running on many servers (some of which may have been drywalled-over by now) and not likely to change much unless disk space gets much more expensive. --Eric -- --- http://scratchcomputing.com ---
Re: The CPAN Covenant
# from Linda W # on Monday 28 November 2011 10:07: > In that case, such modules on CPAN are worse than DEAD WEIGHT, they > don't just take up space. People, like you say, come to CPAN for > 'modules that install in a straight forward manner'. If the module > fails in that regard, then the module has no place on CPAN. It might not be pretty, but this is no reason to say that it has no place on the CPAN. The CPAN is just a bunch of files. > The person who I responded clearly stated that unless I was > willing to pay to make it his highest priority, then my patches would > be given lowest priority. I believe you may have misunderstood David in that regard. It sounds to me like he was saying that nobody has a right to demand anything from a volunteer and I whole-heartedly agree with that. I will answer many demands for a fee, but none for free. That is not to say that I am not often helpful by volunteering my time and code, but acting entitled to my services makes me far less inclined to help. > Personally, I don't like that attitude nor > do I believe it belongs on CPAN which is supposed to be about you > **giving** to the community (not charging them for it!) The CPAN is just a bunch of files. I don't think it holds as much meaning as it does bytes. I seem to recall that the only requirement of the CPAN is that you cannot charge a fee for the code -- which seems to be more of a functional matter than an expression of any sort of ideal (in that a toll filesystem is impractical and harder to maintain than a free one.) If one were to extend that line of thought, one might conclude that a heavily policied CPAN is less practical and harder to maintain than "just a bunch of files." There are many tools (such as cpan/+/m) and collections of data built on top of and around the CPAN (e.g. ratings, testers data). You are free to contribute to those or make your own, and thus everyone is free of long discussions about what should or should not be, because the CPAN is just a bunch of files. --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management --- http://scratchcomputing.com ---
Re: How to break apart a large distribution?
# from Leon Timmermans # on Tuesday 18 October 2011 00:37: >I've been pondering the same. For parts of the codebase that don't use >much dynamic module loading it may be possible to automatize this >using Perl::PrereqScanner. I think we could actually use some >clustering algorithm after that (irony points for reusing biology >knowledge there). If you have some tests, you may want to try running them through my Devel::TraceDeps and getting a full runtime report of everything that gets used. It might be useful before or after breaking the dist apart: maybe you can determine your best groupings based on the tests. The output file contains enough info to map the hierarchy of require()s in the 'trace' data, though I'm not sure if I've tried to put it into a tree form. Also see the pdt-depcheck tool in the Devel-TraceDeps dist to verify that your tests' dependencies match your Build.PL. --Eric -- Chicken farmer's observation: Clunk is the past tense of cluck. --- http://scratchcomputing.com ---
Re: Math::BigInt inheritance problems
# from Paul Bennett # on Sunday 09 October 2011 07:27: >I'm convinced I'm doing something obviously and stupidly wrong, but I > can't for the life of me see the forest for the trees. See also > https://rt.cpan.org/Public/Bug/Display.html?id=67204 It looks like you are getting failures from "not of expected type" errors in both Pari and GMP. It looks like both of them are not respecting inheritance and are using e.g. 'ref($x) eq ...' rather than isa(). You should probably put together a minimal test case and run it with -MCarp=verbose to get a full backtrace and find out where the error is being thrown by which backend. I see at least the following two errors coming from your t/10-ip-address.t and both are going to need a deeper backtrace. 1. "incorrect type in comparison. at .../Math/BigInt/Pari.pm line 206. 2. "not of type Math::BigInt::GMP at .../Math/BigInt.pm line 833. If you can't replicate the errors on your system, you can usually ask the tester who reported it to get you a backtrace. --Eric -- To a database person, every nail looks like a thumb. --Jamie Zawinski --- http://scratchcomputing.com ---
Re: Module::Build::Tiny / dynamic_config=0
# from David Golden # on Monday 29 August 2011 08:07: >Eric raises the question "why bother" and I think for module authors, >at least right now, there is no burning platform to switch. I think you misunderstand my point. Given dynamic_config support, there is no need for a $builder_or_maker.PL for the simple case. > I was trying to write a new, minimalist replacement sufficient for > most things on CPAN that didn't require any changes to > CPAN/CPANPLUS/cpanminus. As for a demonstration of implementing the Build.PL interface: yes. But I think the CPAN clients should eliminate it by supporting dynamic_config. I haven't experimented to see what the current state of this is, but CPAN.pm has dynamic_config support in the prereqs (not sure about test+install.) I think the most complicated part is supporting whatever builder+installer assumptions people have encoded into their configurations -- maybe the client could read buildrc? --Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --- http://scratchcomputing.com ---
Re: Module::Build::Tiny
# from Aristotle Pagaltzis # on Sunday 28 August 2011 22:50: >In my understanding, the complexity of Module::Build piled up >because the same tool tries to cover both installation and >authoring use cases. I've often had that thought, though I would say that M::B definitely suffers from being a mature codebase largely lacking its original author and large amounts of test coverage where small changes could break the CPAN -- so, that tends to stifle innovation (in my personal experience.) The compat code (involving various forms of Makefile.PL workarounds) is also a burden, as is coding to be compatible with anything older than 5.8. But I don't think there are really enough authoring features for that to be a major source of complexity. The "subclassing as customization" design leaves a lot to be desired and makes it difficult to ever change or refactor the internals API without breaking someone's distribution. There is also almost a decade of transition coded into it (e.g. TAP::Harness vs Test::Harness) and a lot of code just to guard against being used in ridiculously old installations. Plus, strange things that happen when you mess with PERL5LIB / -I / 'use lib', etc and expect that to propagate throughout your tests across processes regardless of whether you're running red hat or not. We'll see if MBT has to run the same guantlet. >I believe the Dist::Zilla approach is a better way to take care >of authoring... So Dist::Zilla plus the *idea* of Module::Build::Tiny >seem to fulfil the original concept of Module::Build better than that >module itself ever has. If you're using Dist::Zilla, you *should* not need anything besides META.json to install a simple module if you just set dynamic_config=0. (This "should" is, of course, largely unimplemented.) Also, I think that M::B is better as a customizable deployable build tool than as an author tool. I think it was even conceived as just that and only years of feature creep have added a lot of author tools. >But is the implementation up to par? >... >(I’d also be interested in whether any omissions mentioned in the >POD are design choices or the idea is to add them in the future, >and which if so.) There might be some trouble being compatible with some of the more obscure features of buildrc and the env (which somebody always seems to have setup in a way which you have never thought necessary or logical.) It does seem to have factored-out many functions which M::B had as (maybe misplaced) methods. Overall, it looks interesting, but I would hope that it at least adds some runtime support if not also C/XS. Without the ability to have dynamic prereqs or build C/XS, why do you need a Build.PL at all? You have to assume that the client supports 'configure_requires' or the user has already installed MBT for this to work. If the Build.PL is a compatibility workaround, that seems like a weird niche to me because needing 'configure_requires' means you need a client from the last few years and 'dynamic_config' has been around longer. Sadly, cpanm seems to not support dynamic_config. I'm not sure whether one of the other two clients can "satisfy prereqs from META, run `prove -lr t`, and install the files from lib/" yet. --Eric -- "Insert random misquote here" --- http://scratchcomputing.com ---
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
# from sawyer x # on Sunday 28 August 2011 12:03: >a discussion of the effectiveness and CPU costs of SSL encryption I didn't think it was a question of CPU speed anytime in the past decade. How does a proxy cache encrypted data? Atwood's Law of Computer Latency: Processor cycles, storage density, and network bandwidth are increasing, faster than the speed of light is getting faster. --Eric -- "Insert random misquote here" --- http://scratchcomputing.com ---
Re: MetaCPAN redirects all http:// requests to https:// . Very annoying.
# from sawyer x # on Friday 29 July 2011 06:39: >I also personally see a case for "security by default". OK, please set your client accordingly. It's bad design to force this at the server for all traffic. Of course, it looks like the reasoning is "encourage users to be logged in at all times" -- a flawed goal IMO. https://github.com/CPAN-API/metacpan-web/issues/157 --Eric -- "Everything goes wrong all at once." --Quantized Revision of Murphy's Law --- http://scratchcomputing.com ---
Re: How do I indicated modules used by Makefile.PL (or Build.PL) ?
# from Gabor Szabo # on Tuesday 09 August 2011 00:11: >So I tried > > configure_requires 'File::Copy::Recursive' => 0; > require File::Copy::Recursive; > >but that still blows up when I run Makefile.PL That is to be expected. Something outside of Makefile.PL (i.e. the cpan client) needs to have read META.yml and resolved this beforehand. >I wonder if this will work once it is packaged and when the META.yml > has the configure_requires field already or if I need another way to > make sure File::Copy::Recursive is installed before Makefile.PL is > executed? Yes, if configure_requires is in the META.yml (and the client understands it), then those dependencies will be installed before Makefile.PL is ever run. You may elect to use eval and error-out with a nicer message for the sake of users running the .PL manually or with an obsolete client. But configure_requires is the way to make sure that an external dependency is available before the Makefile.PL/Build.PL runs. --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management --- http://scratchcomputing.com ---
Re: Quick and dirty guide to running Perl on Windows (was Re: Making sure your module works on other OS-es as well)
# from David Golden # on Saturday 02 July 2011 03:51: >On Fri, Jul 1, 2011 at 9:23 AM, David Cantrell wrote: >> ... the complete lack of a reasonable set of >> tools* on Windows, which just makes me angry whenever I have to >> touch the blasted thing, made me stop. >> >> * starting with a useable shell and editor, documentation, and >> remote text-based access. ... > >Definitely the lack of remote text based access makes it harder. But >for anyone willing to run Windows in a virtual machine, it's not >terribly hard anymore. Personally, I use VirtualBox on Ubuntu with a >Windows 7 guest. I suggest WinXP if you have old licenses kicking >around, as it's a little less annoying about validation and such. With a VM install, you still have to wade through the boggy experience of mousing-around in a completely foreign environment while swearing at the shell for being completely unreasonable about everything. But none of this has anything to do with whether your code works on Windows, only whether you can work within it. IMO, it would be much better to not be actually using windows (or mac for that matter) if that's not your preferred environment and you just need to debug some compatibility issue. Not to mention the general case of a CPAN author, where you can't assume that they could be bothered to *obtain* a windows/mac OS, let alone boot it. Some open and deployable environment / test kit would go much further than anything involving a VM and proprietary license. I think the utter lack of convenience in testing for and fixing cross-OS bugs is the big barrier to getting better cross-OS support. Nobody likes coding in the dark with a hours-long latency to see if their fix works. I had no luck getting things to build under wine (IIRC, the trouble came with XS modules), but it's been a few years and I haven't messed with it lately. If it did work well, I'm not sure how much it would gloss over issues of command-not-found and backslashed-path errors. It seems like you could construct a pretty thoroughly windowsish environment by hiding all useful commands (e.g. rename /bin,/usr/bin) and unsetting $PATH, then make some working/temp directories with spaces in the names. That would catch most of the common problems. Not sure if you could emulate the brokenness of the backslashes on a *nix though. --Eric -- Peer's Law: The solution to the problem changes the problem. --- http://scratchcomputing.com ---
Re: Discussion question: what is the best syntax for documenting a coderef parameter?
# from David Nicol
# on Tuesday 07 December 2010 14:12:
>on_connect => $cb->($handle, $host, $port, $retry->())
This is confusing. If you're going to illustrate how it is called, take
it out of the context of how it is declared.
on_connect => sub {
my ($handle, $host, $port, $retry) = @;
...
}
As for illustrating "I will pass you a subref here", I would say:
$on_connect->($handle, $host, $port, sub {...})
or:
$on_connect->($handle, $host, $port, \&retry);
or even just:
$on_connect->($handle, $host, $port, $retry_hook);
But in this particular case, something like a "connection" object with
handle(), host(), and port() methods seems more appropriate, which then
would allow one to do something like '$c->retry until $c->connected'
(assuming appropriate error handling semantics.)
Alternatively, perhaps the last parameter should be an object where one
would say 'return $knob->retry' and this would result in the on_connect
hook being called again after the next connection was established.
If you can, avoid the need to document "I will pass a callback to your
callback".
--Eric
--
Entia non sunt multiplicanda praeter necessitatem.
--Occam's Razor
---
http://scratchcomputing.com
---
Re: What hurts you the most in Perl?
# from Shlomi Fish # on Thursday 02 December 2010 04:30: >It means typing two extra braces, which is more > >> noise on a line, and "the interpreter checks my hash for pairs" is >> silly. > >Which I happen to like and do and am not going to change my ways > (though I tolarate and use APIs which do it the other way around.). But *why* do you "like and do" it? --Eric -- Cult: A small, unpopular religion. Religion: A large, popular cult. -- Unknown --- http://scratchcomputing.com ---
Re: What hurts you the most in Perl?
# from Gabor Szabo # on Wednesday 01 December 2010 13:46: >Many modules on CPAN also need improvements. >But even what we have today we could achieve much better results if >the perception of people was better. > >With my original question I wanted to know what technological and >perception related issues people see. We already got some material but >I'd be happy to see more comments. Especially from those who work with >people who are not involved in the Perl community. How do your peers >and your bosses see Perl? We have all heard the "conventional wisdom" that "perl is dead". But, anything related to perception which cannot be solved by writing modules is probably off-topic for this list. Technological issues with the CPAN and its modules abound. We have 20+ years worth of code and archives to maintain and we're running short on maintainers. Maybe this was mentioned in the rest of this thread and I just missed it, but I would say the one thing module-authors could do to improve Perl is to write better APIs. Replacing some of the old modules with cleaner APIs would be a huge improvement. How many core modules are dripping with C-style error handling, numeric constants as switches, etc? Of course, if better versions existed, would anyone use them? Maybe there will be some progress in removing core modules soon. If CPAN is Perl's greatest strength, core modules are its greatest weakness. While the documentation usually refuses to take a prescriptive approach, the inclusion of some modules makes them seem "recommended", and it always makes me sad to hear people jumping through hoops and reinventing code just to get something to run with only core modules. But if you only let me pick one thing to fix, I would stop this tendency to use one hashref as a single method argument instead of a taking a named parameter list. It means typing two extra braces, which is more noise on a line, and "the interpreter checks my hash for pairs" is silly. --Eric -- "It is impossible to make anything foolproof because fools are so ingenious." --Murphy's Second Corollary --- http://scratchcomputing.com ---
Re: to upload or not to upload...
# from Ricardo Signes # on Wednesday 10 November 2010 05:34: >Isn't this what Net::IP does? > > http://search.cpan.org/dist/Net-IP/IP.pm#looping > >Its interface is a bit gross, but it does exist and work. That could also be said as "It does exist and work, except its interface is a bit gross." After all, "interface" is a big chunk of "API" (and the "A" is supposed to mean something?) --Eric -- [...proprietary software is better than gpl because...] "There is value in having somebody you can write checks to, and they fix bugs." --Mike McNamara (president of a commercial software company) --- http://scratchcomputing.com ---
Re: Name needed for a module to check whether a binary is GNU
# from David Cantrell # on Thursday 09 September 2010 23:32: >> `$binary --version` =~ /(gnu|free software foundation)/i >> >> I'm thinking something like ExtUtils::CheckForGNUbinary. > >Scrap that. It should be more along the lines of checking for >capabilities rather than merely for GNU-ness, with GNU-ness being just >one of many capabilities. For example, GNU tar may *or may not* > support the -j flag, depending on whether bzip2 support is available. Nobody expects Devel::BinaryInquisition --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --- http://scratchcomputing.com ---
Re: my $self = shift
# from Ovid
# on Thursday 09 September 2010 23:15:
> sub foo {
> my $self = shift;
> my ($name) = @_;
>...
>I know this formatting is common, but what practical benefit does it
> gain? ... I'm
> unsure what "value" this provides other than conforming to a
> particular coding preference (and it's more ops, but that's probably
> not enough for it to be a performance win to avoid it).
It's adds clarity (yes, at the cost of an op) and makes the method stand
out as such, since we're lacking a 'method' keyword. Though I guess
you could say:
sub foo {
my ($self,
$name, $thing, $deal) = @_;
...
and get the "stand out" effect without the op cost.
But then the parentheses will likely become troublesome. As in:
sub foo {
my $self = shift;
croak("odd number of arguments") if @_ % 2;
my %args = @_;
...
So, starting a method with 'my $self = shift;' gets it out of the way on
one line, and anything involving the parameter list is separate, which
makes it easier to change the code regarding the parameter list
without having to restructure around the invocant being nested in one
long 'my ($self, $name, ...) = @_' statement. That is, when I'm
working with code which doesn't use the 'my $self = shift;' idiom to
start a method, I find that I have to do some character editing there
when something changes. Whereas with the idiom, this sort of thing
tends to involve linewise editing (shovel vs bulldozer.)
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(@_);
...
Had that been 'sub foo { my ($self, ...) = @_', you might started with:
sub foo {
my %bar = shift->bar(@_);
...
# but we need $self here
And now you have to go back and write it as 'my $self = shift' anyway.
Or I could have said something about keeping yourself from accidentally
overwriting $_[0].
--Eric
--
The only thing that could save UNIX at this late date would be a new $30
shareware version that runs on an unexpanded Commodore 64.
--Don Lancaster (1991)
---
http://scratchcomputing.com
---
Re: "-TRIAL" dists (was: Frozen Bubble 2.2.1)
# from David Golden # on Thursday 05 August 2010 08:55: >Though maybe I should just implement a feature to add '-TRIAL', since >I'll need that anyway for CPAN Meta 2 support. (Dist::Zilla already >supports -TRIAL). Does search.cpan.org understand "-TRIAL" now? Last I looked, it was properly handled (i.e. not indexed) by PAUSE, but would leak through in a few other places where it appears that an assumption was being made without checking the index. It also looked like '-TRIAL' was intended to be used as a pre-release without bumping any version numbers, so you could have -TRIAL1, -TRIAL2, etc all with the version e.g. 5.6.2. Am I understanding that right? --Eric -- "It works better if you plug it in!" --Sattinger's Law --- http://scratchcomputing.com ---
Re: Frozen Bubble 2.2.1
# from Guillaume Cottenceau # on Wednesday 04 August 2010 13:12: >but I don't see >the big problem for machines and I don't know how to say "hey this is >beta" only with numbers; especially if "5.005_03 is equivalent to >5.5.30", I don't see how this could be considered to mark it beta/dev The first problem for machines is that $VERSION is a scalar and has no guaranteed structure to it, so you could put any string or whatever you want in it. Now when you try to compare that to something, you have to compare it as a number, so fun ensues because overloading involves objects and ... The second problem for machines is when you try to use packaging tools that expected a simple number in $VERSION or might try to complain about something that doesn't parse as a number. If you don't mind angering the machines, put whatever you want in there. But, why are humans seeing the raw value of $yourmodule->VERSION anyway? If it's an application, present / format it differently. You can still store whatever you want in it because it's mostly just a scalar. Might be a good idea to find some way to do it with a version.pm object just for maintainability. Now, for marking releases as Beta on the CPAN, well... --Eric -- The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. --George Bernard Shaw --- http://scratchcomputing.com ---
Re: 'applications' mailing list? (was: Killer applications)
# from Gabor Szabo # on Thursday 29 July 2010 05:11: >On Thu, Jul 29, 2010 at 9:16 AM, Johan Vromans wrote: >> Much to my dislike I think we need yet another perl mailing list. I >> didn't find anything suitable in the database of over 210 Perl >> related mailing lists. Two lists come close: module-authors and >> scripts. However, since Perl killer apps require a distinct mindset >> than modules and scripts I'd rather not use any of these. >> >> Shall we go for 'killer-apps' or, more modestly, 'applications'? > >I am not sure what would you like to achieve on such mailing list. >Would web/desktop/mobile/comman line/etc application all in one place? > >I think there are several applications already on CPAN packaged as >modules, for eacmple ack, Padre to be extreme on the sizes. > >Personally I'd use the module-authors list. Is module-authors an appropriate list for discussions about tools and creating/packaging/deployment of applications? Is there a community of application builders lurking here? If so, will new app developers find us here? Are the technologies too specific / different to be lumped into one list vs e.g. wx, qt, catalyst, par, &c existing lists? Just because we currently package several applications as modules does not mean that this is the best way to deploy them to a wider audience. Tools like ack and padre are, after all, developer tools. In my experience, getting end-users to successfully install from the CPAN can be very difficult. It's also possible that a thriving Perl application developer community does not necessarily publish their code on the CPAN, or that the code is even published / open. It seems like the module-authors list may not be a good fit for that. Then again, maybe (and ironically) the solution to "building / deploying something besides a module is difficult" would best be implemented as some modules. ;-) What Johan was saying earlier on the pm_groups list: >>we have thousands of modules but very, very few non-trivial >>applications. >> >>You also see this in the lack of application framework support, only >>recently some App:: modules have addressed this. >> >>Installation support is absent. All tools ... are focused on >> installing modules. This includes installing all modules in the >> global Perl hierarchy ... >> >>No support for application-specific data. TIMTOWTDI is not the right >>answer to every question. No standard way to deal with XML -- this is >>why may people run towards Python and Java. Also, no support for >> local data, no support for user data. Again, until recently. >> >>Relying on CPAN modules is asking for headaches. The modules may be >> not present, wrong version, manually clobbered. ... >> >>Application building: The Perl compiler never did take off. Until >>recently PAR was non-functional. >> >>GUI integration. ... >> >>The end result is that if you want to build a non-trivial application >>and try to use Perl, you have to do a lot of things yourself. --Eric -- Speak softly and carry a big carrot. --- http://scratchcomputing.com ---
Re: Roles on the CPAN
# from Smylers # on Tuesday 27 July 2010 01:28: >> with 'Does::AutoPilot'; > >Yes. Appending ::Role works better in terms of reading the whole thing >as English. > > with 'AutoPilot::Role'; > with 'Serialize::YAML::Role'; > >That also happens to address the concern expressed that such modules >should be in their relevant topic's namespace. I tend to see roles more as an alternate root namespace, so appending "::Role" is the opposite of that. I think #moose should make an executive decision about this and e.g. with '::AutoPilot'; # loads Moose::es::Roles::AutoPilot or whatever --Eric -- Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it. --Paul Graham --- http://scratchcomputing.com ---
Re: Which Build Module?
# from James E Keenan # on Monday 12 July 2010 16:08: >Agreed. In research I did on CPAN modules that contain XS, >ExtUtils::MakeMaker was still used 10 times as often as Module::Build. It seems like authors lean toward EU::MM for XS because they've got so many examples like that. Also, M::B's documentation about xs_files handling was not always clear (and keeping them in lib/ must somehow seem non-obvious since that difference has caught a lot of people.) --Eric -- You can't whack a chisel without a big wooden mallet. --- http://scratchcomputing.com ---
Re: Which Build Module?
# from David Cantrell # on Monday 05 July 2010 06:31: >consider Module::Build, but be aware that for a great many >users it will introduce an extra dependency, as it was not in core > until 5.10.0. First, the "great many" is shrinking quickly, at least if Debian's "oldstable" is any indicator of what is "old" (etch includes 5.10 and will likely become "oldstable" this year.) At that point, I would consider 5.8.8 as "obsolete" and anything older as "ridiculously obsolete". Second, 'configure_requires' takes care of the dependency automatically (given a non-obsolete CPAN client.) IMO, preferring core modules is like using the same size bolt for *every* part of a car (from dashboard to engine mounts) simply because (despite having a full complement of welding, cutting, and forming tools), the drill press just happened to ship with that one size of bit. I suppose the mechanics will love only needing one wrench, but it will be a lumbering beast to drive. --Eric -- ... unsustainable. And that word means something -- it doesn't just mean "we don't like it". --Michael Pollan --- http://scratchcomputing.com ---
Re: Which Build Module?
# from Dave Cardwell # on Saturday 03 July 2010 04:59: >Please could you advise what the “preferred” build module(s) are >nowadays, when releasing to CPAN? > >I don’t have any particular requirements as it’s a simple module, but >I’m unsure which of Module::Install, Module::Build, >ExtUtils::MakeMaker, etc. I should be using. I prefer Module::Build, since it is a pure-perl solution and tends to do a good job of generating modern meta-data and generally doing the right thing without a lot of effort from the author. Plus, if you need to do something special in your build process (which happens even with simple modules), it is cleanly extensible. The argument against it is issues of compatibility with obsolete software (for which free upgrades are available.) ExtUtils::MakeMaker will work fine for simple modules, but tends to get less frequent updates so your meta-data support will lag behind. Module::Install bundles itself in your tarball, which assumes that nothing will ever change in a way that breaks it. --Eric -- "Everything should be made as simple as possible, but no simpler." --Albert Einstein --- http://scratchcomputing.com ---
Re: Module Namespace for External API Wrappers
# from Dave Cardwell # on Saturday 03 July 2010 05:09: >I’ve written a module that wraps the notifo.com API ... > >I’m leaning towards WebService::Notifo, but would appreciate your >advice if you would suggest otherwise. WWW::Notifo::API or (Assuming that it's a REST API) maybe REST::Notifo::API? --Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --- http://scratchcomputing.com ---
Re: Conditional dependencies
# from David Golden # on Tuesday 29 June 2010 13:17: >>... and each appender can be individually toggled on or off ... >> ... whether I want the issue detected at compile time or run time I >> suppose, but is generally frowned upon to put imports down inside >> class methods? > >I tend to think about it like this: > >(a) Mandatory for operation? Load it at compile time. >(b) Optional and almost always loaded in normal operation? Load it at > compile time. >(c) Optional and only needed some of the time? Load it at runtime > if/when needed. (d) Significant chunks of code enabled? Package each one separately with its tests, and compile-time dependencies declared in each dist. So, you have an X, which can use the X::screen, X::email, X::foo plugins / modes / polymorphic functors (or whatever you want to call them.) Installing X by itself either does "nothing interesting" or just some very basic functionality beyond loading the PFs, then each X-foo dist requires X and the 'foo::whatever' modules. Then, just `require X::email` whenever needed by the config / usage. This will ensure that you've got test coverage on your ::foo. Otherwise, if 'foo::whatever' happens to get installed after X and enabled at runtime, you're in a situation where your tests have never run through that code and the user is going to find any bugs or API incompatibilities the hard way. --Eric -- "But as to modern architecture, let us drop it and let us take modernistic out and shoot it at sunrise." --F.L. Wright --- http://scratchcomputing.com ---
Re: How am I wrongly using Math::BigInt?
# from Paul Bennett # on Sunday 13 June 2010 14:36: >As you'll be able to tell (with some digging), the tests that are > failing are one or more of the tests named > /01-try-.*/. These tests are all sanity-checks put in > place to test the underlying modules and/or libraries that my module > itself actually relies on. Those tests don't even use my > module -- they run directly on the underlying modules. What do the underlying modules do in their tests? Are they lacking coverage on the points you're testing there, or are their tests also failing in the same places? Does it fail when your module code causes the dependencies to hit these code paths? If your distribution has tests for dependency code, either they are redundant or should be part of the dependency's distribution. --Eric -- Issues of control, repair, improvement, cost, or just plain understandability all come down strongly in favor of open source solutions to complex problems of any sort. --Robert G. Brown --- http://scratchcomputing.com ---
Re: Why are you releasing modules to CPAN?
# from Gabor Szabo # on Thursday 27 May 2010 04:33: > why do all these people spend their free time on writing modules and >uploading them to CPAN? This doesn't explain the 'why', but: it's not free time. Sometimes it is my time, but that doesn't make it free. >Then we - the CPAN authors and other contributors - have these >discussions on various mailing lists and blog posts on how much we are >supposed to care about the "user experience": writing docs, not > breaking backward compatibility, fixing bugs... etc. We contributors have these discussions because we are also the users. Some non-contributors may also have opinions, which they are welcome to have and hold. >Is it for the fun of writing code? ... >Is it to participate in the community? >Is it to get a virtual pat on the shoulder... >Is it to make other people happy by letting them do their job easier? >Is it because you feel obligated as you are using other peoples code >free of charge? Because if you don't publish your work, you aren't doing science? The proprietary model works by putting the smallest saleable innovation in an opaque box by itself and collecting rent. If there were a viable model somewhere between that and "completely free", software would be much better off and we wouldn't need to be asked about all of these warm and fuzzy reasons for showing our work. Why are open systems more maintainable, scalable, secure, and performant than closed systems? If you can't see and understand the fundamental pieces of a complex system, how are you going to understand the whole? Software without source code is just a parlor trick. Of course, a collection of reusable modules has more value being open and transparent than in a bunch of black boxes. Even if you haven't yet looked at the source, would you use Perl if you couldn't get the source code for the interpreter? --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --- http://scratchcomputing.com ---
Re: returning lists vs references
# from Lutz Gehlen # on Wednesday 12 May 2010 14:19: >On Wed, May 12, 2010 at 11:32:59AM -0700, Eric Wilhelm wrote: >> That might be simple, but no builtins do this, which seems to say >> something. If you're still working with lists, you expect them to >> behave like lists, and not try to package themselves in a reference > >The following comment has admittedly not much to do with wantarray >any more, but I would still like to point out that returning array >references can make sense sometimes,... if this behaviour is well >documented the gain in CPU and memory efficiency might be worth the >loss of encapsulation. It may make sense to make the tradeoff between the API making sense and inefficiencies of the current interpreter implementation. But, don't confuse this with making sense. ;-) --Eric -- Atavism n: The recurrence of any peculiarity or disease of an ancestor in a subsequent generation, usually due to genetic recombination. --- http://scratchcomputing.com ---
Re: Usage of wantarray
# from Hans Dieter Pearcey # on Wednesday 12 May 2010 08:49: >...just because it's not how arrays work anywhere else in Perl, This is not about how arrays work, but how functions work. See localtime(), caller(), each(), glob(), readline(), etc. But then see sort() and split(). There are reasonable cases for context sensitivity, with some reasons better than others. It's easy to wrongly think you've found a good use for it, and maybe even easier to get angry when it is used well but catches you off guard. >but even the relatively simple "return an array in list context, or an >arrayref in scalar context" ... That might be simple, but no builtins do this, which seems to say something. If you're still working with lists, you expect them to behave like lists, and not try to package themselves in a reference with postage to Cairo. The only case where wantarray ? (@x) : [...@x] even has utility is in e.g. perl5i trying to allow method chaining on list objects without needing an explicit ->flatten, but that is just a horrible hack workaround to the lack of a "method" context IMO. It might be worth the caveats, but that just makes it "good enough", not a "good idea". >or because I have to remember > that even though I got an arrayref when I wrote '$foo = function()', > I'll get a list back when I write 'bar(x => 1, y => function(), z => > 3)'. perlfunc: "In general, they do what you want, unless you want consistency." --Eric -- Cult: A small, unpopular religion. Religion: A large, popular cult. -- Unknown --- http://scratchcomputing.com ---
Re: Goodbye Perl6::Say
# from David Precious # on Thursday 15 April 2010 11:32: >On Thursday 15 April 2010 17:04:44 Ovid wrote: >> Never, never run the risk of breaking someone else's production code >> if you can foresee this happening :) > >100% agreed, that's why I think removing Perl6::Say from CPAN is a Bad > Idea. Never run the risk of breaking your paying customer's production code without having an upgrade plan in place? Anybody who is paying James for 5.8.x support should feel entitled to complain about the quality of his 5.8.x support. All's fair in love, war, and freely downloadable open source software. Honestly, if you're setting up a blank machine next week with less than 5.10, not finding Perl6::Say in the index is going to be the least of your problems anyway. But you should be able to purchase some complaint tokens if you really need them. --Eric -- You can't whack a chisel without a big wooden mallet. --- http://scratchcomputing.com ---
Re: Testing problem (32 bit numeric constants?)
# from cr...@animalhead.com # on Sunday 11 April 2010 12:07: >My CPAN module ... Which is mostly made of XS? >is ($ipw->getcc(1), '**', "getcc(1) should return **"); > >These tests assume that Perl stores the constants 0, 999, 1000, , > and 1 as strings. Why do they assume that? Of course, if you're treating them as strings, the numbers will stringify. You could get rid of assumptions by using quoted strings here. >They pass on all CPAN testers' systems except one (so far). > On that system all of the above tests return '??' ?? --Eric -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --- http://scratchcomputing.com ---
Re: Tidy up your PAUSE directories
# from David Golden # on Friday 02 April 2010 06:01: >> On Mar 31, 2:51 am, tim.bu...@pobox.com (Tim Bunce) wrote: >>> It would be handy if there was a way for authors to indicate that >>> new maintainers are sought. Perhaps via the META.yaml/(.json) file. >> ... >It's not in the CPAN META spec ... > >To me, PAUSE would seem to be the right place to do it, as it doesn't >require authors to re-release a distribution just to indicate a change >in status. That was my first thought. If you've had life happen to you, what are the chances that you'll have the time to repackage 20-odd distributions just to add a line to the META.yml (and further, what are the chances that your trunk hasn't changed since the last release)? --Eric -- ... unsustainable. And that word means something -- it doesn't just mean "we don't like it". --Michael Pollan --- http://scratchcomputing.com ---
Re: Trimming the CPAN - "Automatic Purging"
# from Andreas J. Koenig # on Saturday 27 March 2010 21:02: >If you want to study the CPAN "checkpointed logs" solution running on >the very CPAN for exactly one year now: File::Rsync::Mirror::Recent > >What needs to be done is really extremely trivial: rewrite it in C and >convince the rsync people to incoude it in rsync code base. Just that. Or even write an rsync daemon (or proxy perhaps) in Perl. So, when the client asks for a file, you can answer without checking the disk. Can something like that work with an unmodified client, or does the amount of data needed to answer a naive client overwhelm any potential gain? Unfortunately the protocol is not formally documented and the perl code I've seen (File::RsyncP) seems to be lagging: http://lists.samba.org/archive/rsync/2008-October/021912.html If it's possible for a mirror operator to install something that will immediately save them a ton of disk I/O without any changes upstream or downstream, then the person who makes the decision (and does the work) gets the benefit. Scenarios where authors or downstream mirrors must do something special are a tougher sell. --Eric -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --- http://scratchcomputing.com ---
Re: Trimming the CPAN - "Automatic Purging"
# from Arthur Corliss # on Saturday 27 March 2010 12:52: >...should it appear that we have some kind of elitist cabal that will >make their decision in isolation. More likely there will not be some decision made because there will be no action taken. >If that's going to be the case then this should have never been raised >on an open forum like the module author's list. I'll agree, but not for that reason. # from Shlomi Fish on Tuesday 23 March 2010 02:14: So I've been thinking that maybe we should trim the CPAN and remove older versions like that so it will contain much less cruft. What do you think? I think I am not going to take the trouble to delete anything and don't want anybody doing it on my behalf. Thanks for asking. Though the list has, as usual, moved on from that question to something which is off-topic for module authors. >Quite frankly, at times some discussions on this list fail the concept > of a technical meritocracy, and tend towards an established > aristocracy. And you should win stuff for reading it! --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --- http://scratchcomputing.com ---
Re: Q about prerequisites
# from cr...@animalhead.com # on Thursday 25 March 2010 16:39: >CPAN on the smokebox was 1.9402, which can presumably act on the >CONFIG_REQUIRES in META.yml. Otherwise there would seem to be a >semantic knot wherein the 6.42 EU:MM doesn't know how to process >the new CONFIG_REQUIRES so it can replace itself! If the client understands configure_requires, it gets that from META.yml and the Makefile.PL won't be run until there's a new EU::MM => no knot. --Eric -- Speak softly and carry a big carrot. --- http://scratchcomputing.com ---
Re: configure_requires, build_requires, requires
# from Jeffrey
# on Saturday 20 March 2010 20:32:
reference: https://rt.cpan.org/Ticket/Display.html?id=55909
>I went back and
>added the Marpa module to *both* the 'require' and 'build_requires'
>for Marpa::HTML. Now all seems to work perfectly.
But it appears that you changed the rest of the Build.PL code at the
same time, which is actually what fixed the problem.
>An obstacle for me was that Module::Build's actual behavior seems to
>contradict the documentation in Module::Build::API,
What happens on the installation side is actually under the control and
responsibility of the cpan client.
We really need an informational pamphlet explaining the whole "Your cpan
client and Makefile.PL/Build.PL, META.yml, MYMETA.yml,
configure_requires, build_requires, requires" thing, but here's a short
version:
configure_requires: installed before running Build.PL
build_requires: available at ./Build, not required after install
requires: available at ./Build, permanently installed
The client:
1. checks META.yml
1a. satisfies 'configure_requires'
2. runs Build.PL
3. reads MYMETA.yml
3a. satisfies 'build_requires'
3b. satisfies 'requires'
4. runs ./Build && ./Build test && ./Build install
5. installs stuff from 'requires'
6. optionally installs stuff from 'build_requires'
7. optionally installs stuff from 'configure_requires'
Where 'satisfies' often means "download, build, test, and add to
$ENV{PERL5LIB} before continuing", which is where the "optionally" part
in #6 and #7 comes in.
If you're using a module in your Build.PL or build class, you have to
either:
enter it in 'configure_requires'
or
have it in 'build_requires' or 'requires'
and defer loading it until ./Build time.
--Eric
--
Like a lot of people, I was mathematically abused as a child.
--Paul Graham
---
http://scratchcomputing.com
---
Re: bundling Module::Build
# from Jonathan Yu # on Monday 22 March 2010 13:22: >Module::Build's new bundling feature provides the same advantages and >many of the same disadvantages involved with Module::Install. However, >I have not seen its usage really out "in the wild" as of yet. The bundling in Module::Build is fundamentally different from bundling Module::Install in that the installed Module::Build is used if it is newer than the bundled version. Therefore, the bundled stuff will only ever be used when you have a cpan client with no 'configure_requires' support. It is currently labeled 'experimental' mostly for lack of testing. I'm not aware of any modules on the CPAN using it. I guess someone could ship a purely dummy distro and just see what sort of results they get from cpantesters. --Eric -- [...proprietary software is better than gpl because...] "There is value in having somebody you can write checks to, and they fix bugs." --Mike McNamara (president of a commercial software company) --- http://scratchcomputing.com ---
Re: Prerequistie for Marpa::HTML
# from Jeffrey # on Saturday 20 March 2010 20:32: >An obstacle for me was that Module::Build's actual behavior seems to >contradict the documentation in Module::Build::API, which says of >'build_requires' that > >"Modules listed in this section are necessary to build and install the >given module, but are not necessary for regular usage of it." > >Read literally, that says that any module necessary for regular usage >should never be listed under 'build_requires'. Yes, they should be listed as 'requires'. What actually happens is that M::B writes the prerequisites into _build/prereqs (and MYMETA.yml), then prints some warnings about whichever ones are missing. After that, it's up to your cpan client. Modules listed in 'requires' will be present at build time. Modules in 'build_requires' *may* not be present after installation. I'm not aware of any reason why it would be useful to list them in both. Perhaps the meta spec is clearer about this? http://module-build.sourceforge.net/META-spec.html#build_requires We welcome documentation patches in the RT queue. Thanks, Eric -- software: a hypothetical exercise which happens to compile. --- http://scratchcomputing.com ---
Re: Help with naming a module
# from Tamir Lousky # on Friday 05 March 2010 01:16: >I liked the idea of putting in under the "Algorithm::Shape" namespace, > as it clarifies much better what it's for. There is also Math::Geometry::, though Algorithm might be a good fit if it is particularly algorithmic. >Shrubbery on the other hand is quite irresistible. Shrubbery++ --Eric -- "Matter will be damaged in direct proportion to its value." --Murphy's Constant --- http://scratchcomputing.com ---
Re: file spaces in MANIFEST
# from Rene Schickbauer
# on Wednesday 24 February 2010 01:44:
>Files with spaces are generally a BAD idea.
They can be inconvenient, especially in shell hackery.
>For example, every time you call an external program, you have quote
> the arguments. ... You can call `rm -f $fname`; right?
Which is why we don't use backticks to call system('rm', '-f', $fname),
but we also have unlink() for this. :-D
--Eric
--
I arise in the morning torn between a desire to improve the world and a
desire to enjoy the world. This makes it hard to plan the day.
--E.B. White
---
http://scratchcomputing.com
---
Re: file spaces in MANIFEST
# from Skriptke # on Wednesday 24 February 2010 00:54: >I have not managed to find documentation on whether it is possible to > include in MANIFEST files with spaces in names. From ExtUtils::Manifest "Anything between white space and an end of line within a MANIFEST file is considered to be a comment. Beginning with ExtUtils::Manifest 1.52, a filename may contain whitespace characters if it is enclosed in single quotes; single quotes or backslashes in that filename must be backslash-escaped." (Heh, the second sentence there was news to me!) So, if you have a space in the filenames, you'll need to make sure that anywhere you deploy your code has 1.52 or better ExtUtils::Manifest. --Eric -- Peer's Law: The solution to the problem changes the problem. --- http://scratchcomputing.com ---
Re: Excluding files from search.cpan.org diff
# from cr...@animalhead.com # on Friday 19 February 2010 09:15: >The [search.cpan.org] code is written in perl, right? Nobody knows. Nobody has ever seen it. It doesn't exist. Did you try using gitpan? --Eric -- You can't whack a chisel without a big wooden mallet. --- http://scratchcomputing.com ---
Re: Excluding files from CPAN diff
# from cr...@animalhead.com # on Thursday 18 February 2010 10:53: >I like to use this tool to confirm what I've changed from one >distribution to the next. >My latest one added two big data files, and 'diff' says its results >are too big to show. >Also the data files will change in future releases, and they're >binary files. When the pink unicorn goes away, you might try: http://github.com/gitpan --Eric -- "If you dig it, it's yours." --An old village poet (via Al Pacino) --- http://scratchcomputing.com ---
Re: how to mv files on PAUSE
# from Bill Weinman # on Monday 15 February 2010 11:50: >I've resolved it for now; as it happens I've updated the library and >bumped the version number - but it would still be nice to know how to > do this -- and how to delete a file more immediately. That's basically how it is done: Bump the version number, ./Build dist, and upload the new tarball. Your options for changing, renaming, and generally doing anything except adding to the Archive Network are limited, which keeps things simple. --Eric -- ... unsustainable. And that word means something -- it doesn't just mean "we don't like it". --Michael Pollan --- http://scratchcomputing.com ---
Re: 2 Qs about Module::Build
# from cr...@animalhead.com # on Sunday 07 February 2010 23:25: > I can >add the optimization I want to the extra_compiler_flags parameter, >but the optimization from the Perl build is included in the cc >command also. I feel sorry for the compiler which is told to >optimize two different ways... Passing options to ExtUtils::CBuilder from the Build.PL needs some work. I'm sure there are about a dozen hacked-up build classes on the CPAN which are trying to work with this in one way or another. Module::Build needs some way to give authors a lot more rope, but in a way that will allows it and EU::CBuilder to change. Test cases and patches are most welcomed. --Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --- http://scratchcomputing.com ---
Re: Namespace discussion - VMware::LM
# from Aditya Ivaturi # on Thursday 04 February 2010 01:39: >WWW::... since it is actually going to use HTTP. It doesn't talk to a single public service hosted on the World Wide Web, so WWW is counter-descriptive. >This way, we don't end up with a new root namespace. New root namespaces are not necessarily a bad thing. Individual modules with top-level names are discouraged, but e.g. VMware::LabManager would be just fine. --Eric -- "Insert random misquote here" --- http://scratchcomputing.com ---
Re: avoid running CPAN as root
# from Austin Schutz # on Tuesday 12 January 2010 10:08: >Seems like it would be nice if the build system understood appropriate >behavior for the root user and acted accordingly. That is: given >superuser access privileges should be lowered by default during the >build process, but elevated for install. s/build system/CPAN client/ If the build system gets too smart, it interferes with the cpan client and anyway: someone always thinks that whatever decision was the wrong one (which it usually is because given two wrong choices...) --Eric -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --- http://scratchcomputing.com ---
Re: avoid running CPAN as root
# from Shawn H Corey
# on Sunday 10 January 2010 08:11:
>$ sudo cpan
This exposes your system to any bugs in the test suite (an accidental
`rm -rf /` has happened before) with root privileges. With a modern
CPAN client, you can set it to use sudo only at install time with the
make_install_make_command and mbuild_install_build_command knobs.
http://learnperl.scratchcomputing.com/tutorials/configuration/
--Eric
--
perl -e 'srand; print join(" ",sort({rand() < 0.5}
qw(sometimes it is important to be consistent)));'
---
http://scratchcomputing.com
---
Re: satiating cpantesters
# from David Cantrell
# on Saturday 09 January 2010 07:44:
>Fine, but if you *don't* claim to have succeeded, then you have to
>expect that software that looks for failures will spot the failure and
>report it.
As the author's fault? Right.
--Eric
--
perl -e 'srand; print join(" ",sort({rand() < 0.5}
qw(sometimes it is important to be consistent)));'
---
http://scratchcomputing.com
---
Re: satiating cpantesters
# from David Cantrell # on Wednesday 06 January 2010 03:48: >Exiting with a 0 status would seem to be the least clunky solution. >exit(0) means "Stop now and claim to have succeeded" But you didn't succeed because something's wrong and thus on the way out you must mention to the poor user what that might be. I suppose if we had a leave() function, you could get something like 'warn "can't install without ..."; exit 0' from 'leave "can't install without ..."', but we don't because a successful program doesn't have anything to say because there's nothing wrong. --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --- http://scratchcomputing.com ---
Re: satiating cpantesters
# from David Cantrell # on Wednesday 16 December 2009: >>Makes me wonder why fatal m/^Unsupported configuration: .*/ >> errors couldn't be made NA. > >Mmmm, more special cases. From a user's (ie, a module author's) point >of view, isn't it easier to remember "exit(0)" than to remember > exactly what message to spit out? Easier to remember, maybe. But the challenge isn't memory (we usually just look things up, right?), it's education. If you have to educate about the unnatural exit(0) *and* that makes the code clunky, it would seem like a better idea to educate about something that isn't so creaky. --Eric -- "Ignorance more frequently begets confidence than does knowledge." -- Charles Darwin --- http://scratchcomputing.com ---
Re: satiating cpantesters
# from Burak Gürsoy # on Monday 14 December 2009 12:20: >Well... Either die "OS unsupported\n" is an exception (since I get NA > for that) Yeah. Makes me wonder why fatal m/^Unsupported configuration: .*/ errors couldn't be made NA. --Eric -- Issues of control, repair, improvement, cost, or just plain understandability all come down strongly in favor of open source solutions to complex problems of any sort. --Robert G. Brown --- http://scratchcomputing.com ---
Re: Writing tests
# from Elliot Shank
# on Sunday 13 December 2009 12:58:
>You don't fail the {Makefile|Build}.PL, you just don't emit the
> resulting file and exit with 0. This way the standard build chain
> treats it as a NA and not a FAIL.
This only has to do with cpantesters and *not* the "standard build
chain". IMO, cpantesters needs to learn to deal with die() in Build.PL
because using it is far more natural than:
unless($condition) {
warn "you don't have the $condition -- Cannot continue.";
exit 0; # silly cpantesters requirement
}
--Eric
--
Introducing change is like pulling off a bandage: the pain is a memory
almost as soon as you feel it.
--Paul Graham
---
http://scratchcomputing.com
---
Re: Name Proposal for new Module (HTML::EditableTable)
# from Andrew Espenscheid # on Tuesday 01 December 2009 06:39: >I propose the following names for the modules > >HTML::EditableTable >HTML::EditableTable::Horizontal >HTML::EditableTable::Vertical Hi Andrew, The 'tableTable' part of the name is a bit of a mouthful. What about "TableEditor"? But, what aspect of the API makes the table editable? Perhaps something like TableMaker or TableBuilder would be a more apt description? Or even Tabulator. --Eric -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --- http://scratchcomputing.com ---
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
# from Jonathan Rockway # on Thursday 19 November 2009 07:06: >The real reason for the lack of another Perl VM is that Perl > programmers are very, very lazy. ;) In this case, you mean 'perl' programmers. :-D I seem to recall that we have a pressing need for another perl5 VM to deliver on the promise of being able to run your perl5 code in perl6 programs. --Eric -- software: a hypothetical exercise which happens to compile. --- http://scratchcomputing.com ---
Re: naming advice required
# from Ryan Voots # on Monday 09 November 2009 06:17: >> Why not just Github::? > >I Thought the typical convention was to try to find some other root > namespace to put things in rather than making yet another one? No, but that's a common misunderstanding. The recommendation is roughly: Claiming "Github.pm" for yourself is somewhat anti-social, where as breaking the ice on Github:: is liberating to anyone else who might come later (because it gives them a beaten path to follow.) But, if Github.pm and a tree under it already existed as a coherent object system/application, you should use GithubX:: for extensions (or whatever the Github.pm author's request is.) --Eric -- "Insert random misquote here" --- http://scratchcomputing.com ---
Re: Reliability of timing in smoke tests
# from Paul LeoNerd Evans # on Monday 19 October 2009 02:45: >Before I think about this though; does anyone have any better >suggestions? Are there other modules around with timing-sensitive > tests? How do they cope with variable load on the test boxes? You might be able to do something with Time::Mock. E.g. slow down the clock or adjust it at critical points. If your timings are related to sleep(), alarm(), or such that might work. --Eric -- "It is a mistake to allow any mechanical object to realize that you are in a hurry." --Ralph's Observation --- http://scratchcomputing.com ---
Re: How can I tell MakeMaker to insert "recommended" modules into META.yml?
# from Hans Dieter Pearcey # on Saturday 17 October 2009 04:46: >There are a number of problems with this, but the biggest is that > nothing really does anything with 'recommends' in META.yml Module::Build's 'installdeps' action will prompt you to install them. Yeah, it's not CPAN.pm, but also not nothing. --Eric -- Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it. --Paul Graham --- http://scratchcomputing.com ---
Re: metadata and MooseX::Declare (was Fwd: Failed: PAUSE indexer report LETO/Net-Topsy-0.02.tar.gz)
# from Jonathan Leto # on Monday 21 September 2009 12:15: >It looks like the toolchain does not like the fact that I am using >MooseX::Declare in my Net::Topsy module [0]. It also had a hard time >figuring out my version number, until I hard-coded it in Build.PL . That's Module::Build::ModuleInfo. It doesn't know about this 'class' keyword and therefore doesn't see a package or version for Net::Topsy. >Currently, META.yml does not show any modules that are written in >MooseX::Declare. Yeah. You'll want some 'provides' data in META.yml for PAUSE. Or else you'll get this stuff: >Nothing in this distro has been > indexed, because according to META.yml this > package does not provide any modules. Hard to say what you should do about it. M::B::ModuleInfo is a very basic static parser (and has to run on the install target -- not just the developer machine, so e.g. PPI isn't an easy option.) You could write your 'provides' data (like you do your version) manually in the Build.PL (I *think* that works -- maybe involving meta_merge). Or maybe write me that moose compiler I want, then you can use it to do some introspection and save-out some bit of data which gets slurped into the M::B->new() call. --Eric -- "I've often gotten the feeling that the only people who have learned from computer assisted instruction are the authors." --Ben Schneiderman --- http://scratchcomputing.com ---
Re: how to set $VERSION throughout distribution
# from Jonathan Swartz # on Friday 11 September 2009 18:08: >1) Don't bother putting $VERSION anywhere except the main module This might get you '-1 set by base.pm' or other fun surprises from Server::Control::Apache->VERSION. >2) Put a different $VERSION in each module, depending on when that >module itself changes That seems to make sense, but in reality you won't (if you're me) ever remember to update it and that info is in the version control and Changes files anyway. >3) Put the same $VERSION in each module, matching the distribution and > the main module This is a good way to do it because you'll have a way to easily diagnose whether you've somehow ended up with a mismatched set of modules from a distribution and more easily find the right Changes file given any of the modules from the dist. And you can do it automatically with perl-reversion (cpan Perl::Version) --Eric -- "It works better if you plug it in!" --Sattinger's Law --- http://scratchcomputing.com ---
Re: gentle nudgings about upgrading your tools
# from David Cantrell # on Friday 28 August 2009 04:10: >> I guess maybe. It still seems arbitrary, and my point was that it >> is a workaround to the fact that it's currently difficult for a >> module to do "the right thing" to even compare its version against >> the index. > >I'd restrict it to only those modules that are needed to install > stuff: > > CPAN.pm > ExtUtils::MakeMaker > Module::Build > CPANPLUS We've already solved the 'install-side' need with configure_requires. I was talking about the `./Build dist` (author) side of things (from the observation that the OP had run into a bug which would have been avoided by upgrading M::B before rolling a dist.) Authors using an old Module::Build won't be releasing dists with M::B in configure_requires until they upgrade. That might happen automatically if they install some new code from the CPAN which has M::B in its configure_requires, but that's a combination of happy accidents. And, if we were to pretend that M::B author tools were split off into a separate distribution, having CPAN.pm warn you about a new M::B wouldn't do any good, plus people would be confused when their `./Build dist` suddenly started complaining about needing to install something extra (which brings me back to the bit about users setting a preference about which CPAN client to use.) --Eric -- "...the bourgeoisie were hated from both ends: by the proles, because they had all the money, and by the intelligentsia, because of their tendency to spend it on lawn ornaments." --Neal Stephenson --- http://scratchcomputing.com ---
Re: gentle nudgings about upgrading your tools
# from David Golden # on Thursday 27 August 2009 19:12: >> Except then it also needs to tell you that there's a new >> Module::Starter and Dist::Zilla and App::Builder and Tool::Belt and >> ... > >I'd limit it to toolchain modules that are dual-life CPAN and Perl >core. So M::B, EU::MM, EU::Install, etc. Not the rest of the >toolbelt. I guess maybe. It still seems arbitrary, and my point was that it is a workaround to the fact that it's currently difficult for a module to do "the right thing" to even compare its version against the index. So, e.g. Dist::Zilla would have to simply set an expiration date of ~1year if it wanted to give the user a friendly nudge before they released their dist. But of course, expiration dates are troublesome if for some reason there's been no need for a release in that year other than to allow the user to silence the warning. Or we can all compare timestamps of the CPAN vs CPANPLUS indices or maybe try to fetch a fresh one or whatever because there's no way for a user to indicate their preference. --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --- http://scratchcomputing.com ---
Re: XML::Rules new versions not seen by CPAN shell
# from David Cantrell # on Thursday 27 August 2009 07:33: > WARNING: there are new versions of Module::Build and Module::Install > available, it is strongly recommended that you upgrade them > >CPAN.pm already tells you if a new CPAN.pm is available, ... Except then it also needs to tell you that there's a new Module::Starter and Dist::Zilla and App::Builder and Tool::Belt and ... But if you leave it out of CPAN|CPANPLUS, the trouble for each module is to detect whether they've been superseeded when that they don't know which index is up-to-date or which client the user prefers. There's more than one way to do it and we can't tell which the user wants. Of course, M::B could just set a best-if-used-by date in its code and complain about that at `./Build dist` time. --Eric -- "But as to modern architecture, let us drop it and let us take modernistic out and shoot it at sunrise." --F.L. Wright --- http://scratchcomputing.com ---
Re: XML::Rules new versions not seen by CPAN shell
# from David Golden # on Tuesday 25 August 2009 17:46: >Install Archive::Tar. Upgrade Module::Build. That should fix it for >you. This makes me wonder how many authors are using a current version of Module::Build. Between this, configure_requires, and the Software::License support, there are a lot of improvements in the past year or so. --Eric -- "You can't win. You can't break even. You can't quit." --Ginsberg's Restatement of the Three Laws of Thermodynamics --- http://scratchcomputing.com ---
Re: Getting ready for CPAN
# from Shawn H. Corey # on Sunday 02 August 2009 07:56: >On https://pause.perl.org/pause/authenquery?ACTION=pause_04about it > states: > >"There's only one thing you need to know as soon as possible: > > Please, make sure the filename you choose contains a version > number." > >OK, does that mean every file needs a version number or just the > tarball? The important point there is: "For security reasons you will never be able to upload a file with identical name again." But the only "file" you ever upload is the tarball. (You can upload other files, but a "distribution" (which is what matters) is a tarball.) So, you upload Foo-v0.0.1.tar.gz instead of Foo.tar.gz, then you can supersede it with Foo-v0.0.2.tar.gz, etc. as the code changes. --Eric -- Human beings are relatively simple. You just reward them for something and they will do it. --William Cohan --- http://scratchcomputing.com ---
Re: versions as v-strings
# from David Golden # on Tuesday 28 July 2009 14:54: >> Aside: I just do: >> >> our $VERSION = v1.2.3; > >But you shouldn't. :-) Unless you require Perl 5.10. For some definitions of "shouldn't" perhaps depending on how much value you place on which ends of the trade-offs. For everyday usage it's fine back to 5.6.2 at least. $ perlv5.6.2 -e 'use File::Fu v0.0.9' File::Fu v0.0.9 required--this is only v0.0.6 at -e line 1. BEGIN failed--compilation aborted at -e line 1. Of course, if you're on pre-5.10 AND you want to print File::Fu->VERSION, you need to load version.pm first. To me, that's fair (aka: "you want features? upgrade!") and it saves me from code clutter. It's not ideal, but it weighs less than the other non-ideal options for multi-dotted versions. --Eric -- Speak softly and carry a big carrot. --- http://scratchcomputing.com ---
Re: Test Failures - XS, "does not match bootstrap parameter" and version objects
# from Jonathan Yu
# on Tuesday 28 July 2009 09:37:
>In at least one report, the version seems to be recent, so I'm not
>sure if it's a new issue: version 0 0.76_06
It appears that you're using the deprecated (or soon-to-be-deprecated
(or maybe not deprecated depending on how you quote it?)) multi-dotted
version number without the leading v. This might be a bug in the new
version.pm (or a bug in the deprecation), but note that the docs
recommend that you have the leading 'v' for multi-dotted versions:
> use version; our $VERSION = qv('1.0.6');
use version 0.77; our $VERSION = qv("v1.2.3");
I think 0.77 was supposed to be just a docs cleanup, but maybe something
got changed slightly. Anyway, the docs were historically somewhat
distracting and tended to recommend the least-best ways to do stuff.
Aside: I just do:
our $VERSION = v1.2.3;
--Eric
--
Hot dogs: just another condiment.
--Heart-attack Man
---
http://scratchcomputing.com
---
Re: DateTime::Duration::W3C?
# from Ovid
# on Friday 03 July 2009 06:40:
> I can't find a proper parser for it and it turns out to have some
> tricky bits. Basically, I want to do this:
>
> my $duration = DateTime::Duration::W3C->new("P1Y2MT2H");
Are the tricky bits in the parsing or the calendar math necessary to get
to the end datetime? The math should be nicely handled by Date::Piece
up to the hours, where you then take at() of the start time and add to
that Time::Piece object.
If you want to do the parser and duration object, I'll happily take a
Date::Piece patch to support it.
--Eric
--
hobgoblin n 1: (folklore) a small grotesque supernatural creature that
makes trouble for human beings
---
http://scratchcomputing.com
---
Re: Getopt::Auto improvements
# from Geoffrey Leach # on Monday 29 June 2009 12:34: >The key difference between Auto and Euclid is that Simon wanted to >subject the POD writer to minimal inconvienence. I should have >mentioned that option processing results in a call to main::foo, which >would permit the user to do whatever checking was needed. I have not looked at Getopt::Auto lately, but my Getopt::AsDocumented does some of what you're wanting to accomplish. I would say that Getopt::Auto could be implemented on top of AsDocumented (the main difference would be the calling of main::foo(), but also the options object), but I won't guarantee compatibility between Getopt::Base and Getopt::Long (and have no plans to do so.) My approach to what the pod contains was based on showing the user the information, so just: =item --foo FOO (number) Getopt::Base has been designed to do some mild validation, but does not actually do it yet (everything is a string at the moment.) See also Getopt::Abridged, which is like a gateway drug to Getopt::AsDocumented. --Eric -- [...proprietary software is better than gpl because...] "There is value in having somebody you can write checks to, and they fix bugs." --Mike McNamara (president of a commercial software company) --- http://scratchcomputing.com ---
Re: lexical warnings question
# from Bill Ward # on Tuesday 16 June 2009 15:08: >I know we're doing all kinds of crazy stuff to __DIE__ and I'm not >sure about __WARN__ but I suspect we may be. You might like to try this as a way to assert that thou shalt not. http://search.cpan.org/dist/Devel-NoGlobalSig This assumes that the crazy stuff is done without local(), which is indeed crazy. perl -MDevel::NoGlobalSig=warn t/whatever.t --Eric -- [...proprietary software is better than gpl because...] "There is value in having somebody you can write checks to, and they fix bugs." --Mike McNamara (president of a commercial software company) --- http://scratchcomputing.com ---
Re: Best way to abandon usable code?
# from Peter Pentchev # on Wednesday 27 May 2009: > to me the simple fact that >you sent this message instead of just letting the module lie there on >CPAN means that you care about it at least a little bit Unless I missed it, it doesn't sound like the OP has put it on the CPAN yet. IMO, posting your code on the CPAN and walking away is better than just walking away. At least then users will be able to easily find and install it -- and maintainers are always users first. --Eric -- Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it. --Paul Graham --- http://scratchcomputing.com ---
Re: Process for Removing Qt Module from CPAN
Hi Chris, # from Chris Burel # on Tuesday 26 May 2009: >One thing I thought of doing was calling the module Qt4, but that would >populate the Qt namespace. That is going to cause you headaches with the PAUSE indexer. It finds all of your package statements and will flag your dist as unauthorized if you use an existing package. But actually, this sort of thing is rather clunky and unusual for Perl code: use Qt4; my $app = Qt4::Application(\...@argv); That is, if you're worried about the repetitive typing, I think the :: is a bigger source of tedium. If Application() is going to be a constructor function -- as opposed to the more typical new() -- it may as well be exported as QApplication(). And really, what's wrong with Qt4::Application->new()? --Eric -- "It works better if you plug it in!" --Sattinger's Law --- http://scratchcomputing.com ---
Re: Process for Removing Qt Module from CPAN
# from Jonathan Yu # on Monday 25 May 2009: >I'd like to remove the Qt module from CPAN, or be able to take it > over. Hi Jonathan, That's a good question in general, but for Qt4, I'm inclined to say that a better approach would be to use the 'Qt4::' namespace. >I'm working with someone else on perlqt4 bindings for my Google Summer >of Code project, and the currently available version of Qt is from >1997 and of little use to anybody. (See: code.google.com/p/perlqt4) > >We'd like to be able to push the module through CPAN once we're done. >In order to do that, we need to remove the existing version and >register the namespace to one of us. > >I think the top-level namespace is appropriate since that's exactly >what other packages (ie, Wx) do. From my tinkering with it thus-far, it appears that Qt3 and Qt4 are quite different APIs. That is, current Perl code written for Qt (3) won't "just work", right? If it breaks existing code (even if it's a few years old), it's rather severe to replace a distribution. Thus, if it's technically feasible (and doesn't make the API horrid), adding a '4' to the package name seems reasonable. I will be glad to help with this as time allows. --Eric -- Like a lot of people, I was mathematically abused as a child. --Paul Graham --- http://scratchcomputing.com ---
Re: RFC: aliased::factory
# from Eric Wilhelm # on Sunday 24 May 2009: >I >want something which aliases an entire class hierarchy and loads >modules from it on demand. > > use aliased::factory YAPI => 'Yahoo::Marketing'; > > # this does: require Yahoo::Marketing::KeywordResearchService > # and calls Yahoo::Marketing::KeywordResearchService->new(...) > my $ybis = YAPI::KeywordResearchService(...); With advice from hdp^Wconfound on irc, I went with a method-call interface where the object is a factory. When you call new() you get the thing, when you call anything else, you get the subpackage corresponding to that method name. This removes the one-level limitation without too much added typing. Sorry if you're have a new.pm! my $ybis = YAPI->KewordResearchService->new(...); It's on the way to the CPAN now. --Eric -- As an old bass player friend of mine used to say: throw money, don't clap. --Tony Parisi --- http://scratchcomputing.com ---
RFC: aliased::factory
Hi all, I'm looking for something like aliased.pm, but with a more specific functionality. Where aliased.pm only renames (and loads) one class, I want something which aliases an entire class hierarchy and loads modules from it on demand. use aliased::factory YAPI => 'Yahoo::Marketing'; # this does: require Yahoo::Marketing::KeywordResearchService # and calls Yahoo::Marketing::KeywordResearchService->new(...) my $ybis = YAPI::KeywordResearchService(...); my $res = $ybis->getRelatedKeywords( relatedKeywordRequest => YAPI::RelatedKeywordRequestType(...) ); Both Yahoo::Marketing and Google::Adwords have a very long list of objects under their namespace and frequently need various objects to be passed into their methods (this is largely due to their SOAP APIs and that the Perl code exactly mirrors that.) It seems like this might have useful applications elsewhere. As for implementation: import() would install a YAPI::AUTOLOAD(), which does the require($thing) and $thing->new(...) bit. Of course, this means that the hierarchy is only one level below the aliased namespace. This seems like enough (though I have considered making YAPI::Foo() install a YAPI::Foo::AUTOLOAD().) Thoughts? Thanks, Eric -- "Because understanding simplicity is complicated." --Eric Raymond --- http://scratchcomputing.com ---
Re: Module::Build + automatic README / LICENSE
# from Hans Dieter Pearcey # on Tuesday 12 May 2009: >On Tue, May 12, 2009 at 10:31:48AM +0100, Paul LeoNerd Evans wrote: >> > use Software::License. >> >> Hmm.. I don't see how this interacts with Module::Build. Do you >> suggest I'd just have it as a separate part of the build process? > >Yes. Well, rather, I was suggesting it as the starting point for > whatever integration you want to write. Isn't that what Ken did some time ago? Ah... 0.31 added the "create_license => 1" option, but I guess it didn't get documented. --Eric -- "It ain't those parts of the Bible that I can't understand that bother me, it's the parts that I do understand." --Mark Twain --- http://scratchcomputing.com ---
Re: ShipIt or Module::Release or Dist::Zilla or ..
# from Thomas Klausner # on Sunday 19 April 2009 12:28: >So. It seems there's nothing off the shelf that fits my needs. I >wouldn't mind contributing to one of the above projects (or to another >one..). But to which? I've been using this for over a year now, but don't have time to document it. It does svn, but I would be interested in some input about the git side of things. http://svn.scratchcomputing.com/CPDK/trunk/ If that doesn't interest you, I suggest you look harder at Dist::Zilla. Aside: many authors have their own way of doing this, some of us have published it, some of us have tried to make it generic and configurable, some of us have written documentation. What we all have in common is lots to do and very little time :-D --Eric -- hobgoblin n 1: (folklore) a small grotesque supernatural creature that makes trouble for human beings --- http://scratchcomputing.com ---
Re: managing your perl
# from Joshua ben Jore # on Sunday 12 April 2009 20:06: >> http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices > >It may be a best practice to maintain your own perl but having just >done this at work, it's a massive time sink. Our new platform at work >is an Ubuntu mod_perl system with 208 CPAN modules. We produced a .deb >for perl+modules and another for mod_perl Only *one* .deb for perl and all of the modules? >but it took us several weeks >to do it and we had to learn a bunch about how to author for Debian. >It was painful and I don't recommend it for most people. You don't have to do it as Debian packages. Simply installing from source and then building a full set of modules has never taken me more than a few hours. --Eric -- If the collapse of the Berlin Wall had taught us anything, it was that socialism alone was not a sustainable economic model. --Robert Young --- http://scratchcomputing.com ---
Re: "a lot of controversy" about Module::Build
# from David Fleck # on Sunday 12 April 2009 05:18: >On Thu, 9 Apr 2009, Eric Wilhelm wrote: >> If you're installing today's code from the CPAN directly on outdated >> production machines, you're doing it wrong. > >So, what *should* you install on outdated production machines? Because >where I work, we've got a lot of them. There are plenty of options for doing it haphazardly, including simply installing a working cpan client. But, if you're actively changing code on these machines, you really should have some sort of test/staging/deployment process to avoid surprise downtime and be able to rollback to the previous state. This implies that you need some knowledge of how the sausage is made (or how to hire a consultant) and you'll probably also need to upgrade to a new ExtUtils::MakeMaker. By the time you get all of those details sorted out, Module::Build is not a problem. --Eric -- Minimum wage help gives you minimum service. --David Schomer --- http://scratchcomputing.com ---
Re: managing your perl
# from Curtis Jewell # on Thursday 09 April 2009 14:43: >On Thu, 09 Apr 2009 14:20 -0700, Eric Wilhelm wrote: >>If everyone can get past the idea that something non-core is somehow >>unusable, a fine document already exists >> http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices > >Ok. Now we need to find someplace appropriate that we can convince >something in core to link to it. Joking, right? There's no need for "something in core" and it is already "someplace appropriate". The important attributes for this sort of information are that it is current, correct, and findable. http://www.google.com/search?q=perl+administration+best+practice --Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --- http://scratchcomputing.com ---
Re: managing your perl
# from Jonathan Rockway # on Thursday 09 April 2009 13:30: >* On Thu, Apr 09 2009, Bill Ward wrote: >> How about you write a "how to manage Perl on your system" doc and >> get it into the core as a new perlxyz perldoc file then. > >That is a very good idea. > >Of course, the people that will update to a version of perl that >includes this doc probably won't need it ;) If everyone can get past the idea that something non-core is somehow unusable, a fine document already exists http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices --Eric -- [...proprietary software is better than gpl because...] "There is value in having somebody you can write checks to, and they fix bugs." --Mike McNamara (president of a commercial software company) --- http://scratchcomputing.com ---
Re: "a lot of controversy" about Module::Build
# from David Cantrell # on Thursday 09 April 2009 10:01: >> The recommendations we make to new programmers are met with limited >> patience. Do you recommend that they use EU::MM on account of >> M::B "not working" on a system which hasn't been upgraded in 10 >> years? > >No. But what about a system where the toolchain's not been touched > for three years? ... fairly common upgrade cycle in business I still would not recommend EU::MM to a new user on this account. If you're installing today's code from the CPAN directly on outdated production machines, you're doing it wrong. That's not a problem with M::B, and it is not a new user's immediate concern. Sure, you'll need to brief a new hire on your deployment mechanism and its caveats, but that's true at any business. --Eric -- Entia non sunt multiplicanda praeter necessitatem. --Occam's Razor --- http://scratchcomputing.com ---
Re: "a lot of controversy" about Module::Build
# from David Cantrell
# on Thursday 09 April 2009 05:10:
>>>But, anyway, is it a problem we really need to be inflicting on new
>>> Perl users? Do they have to care if "somebody might be running
>>> 5.8.8 somewhere"? With 5.10.0 out for well over a year now?
>I care because ...
You don't exactly qualify as a "new user", though :-)
>A common plaint I hear about perl code *from people outside the
>community* is that we have too many dependencies and our code is too
>hard to install. ... If on top of that you want
> them to *upgrade perl* they're going to think you're mad.
Ruby didn't seem to have a problem getting installed.
>And we should care about people outside the community, because they
>vastly outnumber those of us *in* the community. They and their
>opinions are important because they do things like influence which
>technologies their employers use, and consequently how many jobs there
>are for us.
I've never heard "we don't use Perl because it's hard to install", I've
only heard "we can't find programmers".
The recommendations we make to new programmers are met with limited
patience. Do you recommend that they use EU::MM on account of
M::B "not working" on a system which hasn't been upgraded in 10 years?
IMO, that's getting off on the wrong foot for reasons which aren't
worth it. By the time you need to explain how to do something special
with EU::MM, you could easily explain the compatibility issues of M::B
and the boring history lesson (and if you've gotten that far, we've
passed "newbie".)
And for those who would recommend M::I, would you also explain the
pitfalls of that, or simply leave it as "what you don't know yet won't
hurt you yet"?
--Eric
--
perl -e 'srand; print join(" ",sort({rand() < 0.5}
qw(sometimes it is important to be consistent)));'
---
http://scratchcomputing.com
---
Re: "a lot of controversy" about Module::Build
# from Dave Rolsky # on Wednesday 08 April 2009 17:58: >I, as a module author providing you a free product, don't have to give > a damn. Realistically, authors give some amount of damn, but maybe > not a full "I'll support Perl 5.004 for the poor slobs using ancient > Red Hat boxes". Exactly. If you treat Perl like a legacy language, there won't be any new users and you won't have any problems of some new code not being compatible with your old code because there won't be any new code. --Eric -- ... unsustainable. And that word means something -- it doesn't just mean "we don't like it". --Michael Pollan --- http://scratchcomputing.com ---
Re: "a lot of controversy" about Module::Build
# from David Cantrell # on Wednesday 08 April 2009 16:17: >> Dissenters are certainly free to hold their opinions without reason, >> but I would rather they not inflict those irrationalities on others >> as advice. > >What you would rather has no bearing on what *is*. > >And your belief that those who disagree with you are irrational is >both offensive and demonstrates that you've not actually bothered to >read those opinions. Please don't get offended or think that I've called you irrational. I'm simply pointing out that opinions stated without reasons are unreasonable, not calling you unreasonable. >> Please elaborate on why one should *not* use Module::Build. > >That depends on who one is. If you're writing specifically for people >who keep their toolchain and perl religiously up-to-date, There's nothing religious about it. You upgrade, it works better. >then by all means use Module::Build. But if you're not, then using >Module::Build is silly because it hasn't been in core for very long. That's not exactly a problem with Module::Build (not that I haven't put energy into solving it.) But, anyway, is it a problem we really need to be inflicting on new Perl users? Do they have to care if "somebody might be running 5.8.8 somewhere"? With 5.10.0 out for well over a year now? And anyway, if the trouble with using something is that it's "not core", the fix is not to get it into the core. Rather, we should try to make "coreness" not matter. Thanks, Eric -- "Beware of bugs in the above code; I have only proved it correct, not tried it." --Donald Knuth --- http://scratchcomputing.com ---
Re: "a lot of controversy" about Module::Build
# from Hans Dieter Pearcey # on Wednesday 08 April 2009 12:35: >On Wed, Apr 08, 2009 at 12:26:17PM -0700, Eric Wilhelm wrote: >> You're saying there is a debate about whether stagnation is a good >> idea? > >I'm missing the connection between "stagnation" and "Module::Install", > here. Or were you talking only about EUMM? The PBP review says "maybe" on M::B, but nothing about M::I. If you're going to recommend that new users use M::I instead of EU::MM or M::B, you really need to hang an even bigger maybe on that one. EU::MM will "just work" because it never (except re INSTALLDIRS) changes and predates all of the client tools. The drawback for authors is that it never changes and that functionality is limited. The drawbacks for users are some subtle interface nits related to the fact that it uses make (and shells out to perl for every file manipulation.) There's a less visible "lack of new features" - because it never changes. M::B will "just work" as soon as all of the client tools are updated. The drawback for authors is getting bug reports from users who don't have updated client tools. The drawback for users is also in the client tools. M::I will "just work" until something goes wrong with the bundled version, at which point the author using it *must* release a new version to fix it. It is also susceptible to EU::MM *ever* changing. Now that we have configure_requires, EU::MM might start changing, which would completely break M::I. > and it doesn't matter > (to that subject) that you say very forcefully that there is no > reason not to use Module::Build, and call people who do not want to > use it "irrational", because that all is *part* of the "controversy", The pain of making it possible to have more than one build tool, or to have our build tools ever change (without bundling the world into each dist) has a long history. I can understand that from the standpoint of people not having time to mess with it, but how much of the pain is just a result of the momentum of the pain? --Eric -- Speak softly and carry a big carrot. --- http://scratchcomputing.com ---
Re: "a lot of controversy" about Module::Build
# from David Golden # on Wednesday 08 April 2009 12:21: >On Wed, Apr 8, 2009 at 2:34 PM, Eric Wilhelm wrote: >> If there has been any controversy, it's been about the fact that >> M::B was the first tool to break from "how we used to do it". This >> exposed > >I'll add just my 2 cents to say that a good deal of the controversy >was hung up on getting good support for Module::Build into CPAN.pm and >CPANPLUS. Between the recent work on CPANPLUS::Dist::Build and the >support for configure_requires in both CPAN.pm and CPANPLUS targeted >for 5.10.1, I think the controversy will be largely resolved. I would call that "a good deal of pain", rather than controversy. And yes, thanks to your efforts (and to everyone else involved), that pain is finally getting out of the way of progress. Thanks, Eric -- Chicken farmer's observation: Clunk is the past tense of cluck. --- http://scratchcomputing.com ---
Re: "a lot of controversy" about Module::Build
# from Andy Lester # on Wednesday 08 April 2009 12:27: >> Please elaborate on why one should *not* use Module::Build. > >Because the cost of learning it is non-zero. Fine. But for *new* users? Would you say EU::MM is easier to learn? --Eric -- "Everything goes wrong all at once." --Quantized Revision of Murphy's Law --- http://scratchcomputing.com ---
Re: "a lot of controversy" about Module::Build
# from David Cantrell # on Wednesday 08 April 2009 12:06: > As I've said before, this is silly. It's a tool, so either it works > or > >> it doesn't. We can't really have "controversy" about whether it >> works or how it works. > >Despite your saying that we can't, we do. There is disagreement about >whether it's a good idea to use Module::Build, and merely denying that >the disagreement exists is ... well, it's silly. You're saying there is a debate about whether stagnation is a good idea? Dissenters are certainly free to hold their opinions without reason, but I would rather they not inflict those irrationalities on others as advice. Please elaborate on why one should *not* use Module::Build. Thanks, Eric -- Peer's Law: The solution to the problem changes the problem. --- http://scratchcomputing.com ---
Re: "a lot of controversy" about Module::Build
# from Hans Dieter Pearcey # on Wednesday 08 April 2009 09:20: >In particular, saying "maybe" for Module::Build seems pretty > reasonable to me, since M::B vs. M::I is the emacs vs. vi of > distribution installers, and the summary "there is controversy, but > it's definitely better than EUMM" is certainly true. As I've said before, this is silly. It's a tool, so either it works or it doesn't. We can't really have "controversy" about whether it works or how it works. I can understand if one prefers the syntax of Module::Install and has no qualms about the questionable workarounds on top of EU::MM or has chosen the predictability of bundling in light of the risks of staleness. But at this point, it is very possible to build all of that on top of Module::Build without all of the subtle and lingering gotchas. It's a long, long ways from "emacs vs vi". Feel free to make "rpm vs deb" analogies (with actual pros/cons.) But, when sending someone a file, "edited in emacs or vi" doesn't matter. If there has been any controversy, it's been about the fact that M::B was the first tool to break from "how we used to do it". This exposed some flawed assumptions in the rest of the ecosystem which were not of M::B's making. I hope we're past that (and I'm looking forward to the seamless addition of multiple alternative builders - perhaps even a less eye-bleedy way to do Inline:: modules.) Analysis of real problems with M::B are welcomed in the bug tracker (or as code.) This will help much more than snide "if only it worked" comments scattered around the interwebs and avoid making new users thing there's something wrong with M::B on account of it "not working in 1999". Thanks, Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --- http://scratchcomputing.com ---
