Re: What is the "best" code on the CPAN?
Dist::Zilla is also something you might want to actually /use/ :D -Mike On 12-02-07 09:34 PM, David Golden wrote: > On Tue, Feb 7, 2012 at 9:29 PM, Jeffrey Thalhammer > wrote: >> So in your opinion, which distribution on the CPAN best demonstrates these >> qualities? > > Dist::Zilla > > Leaving aside the fact that I don't think your full wishlist actually > exists in any single thing on CPAN, I would nevertheless point you to > that as a good example of almost all the things on your list. > > -- David
Re: Revert use_ok() change to allow lexical effects?
On 12-04-10 05:20 PM, Paul Johnson wrote: > On Tue, Apr 10, 2012 at 12:20:20PM -0700, Michael G Schwern wrote: >> 2. Should use_ok() be discouraged in the documentation? > > I'm very much in favour of this. I don't see any discouragement in the documentation... and what's wrong with use_ok to begin with? -Mike
Re: Revert use_ok() change to allow lexical effects?
On 12-04-10 05:59 PM, Leon Timmermans wrote: > On Tue, Apr 10, 2012 at 11:52 PM, Mike Doherty wrote: >> I don't see any discouragement in the documentation... and what's wrong >> with use_ok to begin with? > > If it fails, the module may not be loaded, or partially loaded. In > such circumstances, testing the rest of the code can give very > confusing results. It doesn't make sense to continue testing usually. I typically use_ok(...) or BAIL_OUT. If that's the only way to use use_ok safely, then maybe it should do that for you automatically. -Mike
Re: interest in converting LWP / Mech hierarchy to roles?
On 13-02-28 09:07 AM, Yanick Champoux wrote: On 13-02-27 11:04 AM, Mark Stosberg wrote: Perhaps if some of these get converted to extend-by-roles instead of extend-by-inheritance, some others will follow along, and we'll end up with a more useful of collection of Perl-based browser extensions. I don't have a lot to add to the conversation at the moment, but I just wanted to '++' the idea Same here. I've had two separate projects at university that both would have been easier had the LWP stuff been done as roles. As it seems everyone thinks this is probably a good idea, the real question becomes "Who is going to do the work?" -- as usual :) -Mike
Re: Conflicts in the meta spec
On 13-04-15 01:56 PM, Michael G. Schwern wrote: Why we need this, why you can't do it with "requires" is because this is for modules which you do not depend on. Often they depend on you. MooseX::Blah depends on Moose, so Moose declares conflict with versions of MooseX::Blah it breaks. This requires Moose maintainers to know about all the things their releases break. Have you considered reversing the directionality so MooseX::Blah knows about the things which break it? That seems like a more likely scenario to me, and lets the right maintainer control the "conflicts" relationship. -Mike
Re: Unicode output with Test::More
IIRC, Test::More::UTF8 does the right thing. -Mike On 14-02-15 11:22 AM, Olivier Mengué wrote: > Hi, > > I would like to use non-ASCII, non-Latin-1 characters in test script output. > > So far I've written the following: > > > use Test::More; > use Term::Encoding 'term_encoding'; > my $enc = term_encoding(); > note $enc; # Ensure that builder->output is opened > > > binmode($_, ":encoding($enc)") > for Test::More->builder->output; > > > > Is there a better way (cleaner, or more portable)? > Does something already exists on CPAN? > > Thanks for you help, > > PS: for my full use case, see > https://github.com/dolmen/angel-PS1/blob/85912c6fe5d2f9507cb1831c689fe66db4ec7bcc/t/52-Gauges.t > > > Olivier Mengué (DOLMEN)
Re: HTTPS, CPAN, and dist integrity
Doesn't cpan know how to use curl or wget if the system has it installed? Probably easier to bootstrap TLS support in perl that way. -Mike On Feb 3, 2015 2:26 PM, "Michiel Beijen" wrote: > Hi, > > This Saturday at FOSDEM in the hallway I had some discussions with > leont, Tux and later also with .. oh I guess that was RJBS? I did not > introduce myself, very bad. Hi! > > Basically I think the whole CPAN setup with 200+ mirrors sounded great > back in the 1990s and it is still widely touted as a feature of CPAN. > But I'm a bit concerned about package integrity. Most Linux > distributions (where the packages and ISOs are typically LOTS bigger) > who use mirrors have a system in place where they verify their > packages with GPG keys. If you do that then having many mirrors > outside of your control using plain HTTP is not a problem, but Perl > does not *really* have something like that. Yeah of course there is > the signatures list, which is GPG signed, but this signature is not > checked 'out of the box' as far as I know. > > So assuming you can't really verify the integrity of a module on a > mirror from the client, I think it would be best not to use any > mirrors. > As far as I know, with StrawberryPerl or a client like cpanm, you only > use one mirror anyway. Maybe the parties involved can share how much > bandwith it takes them to see if it would be feasible to switch to > *one* source for CPAN with possibly a CDN underneath. The metacpan > seems to have a decent CDN now, has SSL certificates and a complete > index. I think they should be able to handle the additional data, but > this is just based on my gut feeling of scale of the thing, average > dist size, and such and not on actual facts. > > The other problem is how to securely connect to the mirror. There is > no support for SSL in core perl. But I think in many cases, it would > be an acceptable solution to install IO::Socket::SSL from your linux > distro's distribution, and then have the CPAN client 'auto-select' the > https version of the cpan mirror. If desired the CPAN client could > complain about not having SSL when IO::Socket::SSL is not installed. > > Please let me know if this would be feasible and what your concerns would > be. > > I'd be willing to contribute patches to the cpanpm client to use HTTPS > if available, and to rip out the mirrorlist stuff. > -- > Michiel >
