Re: perlbrew switch perl-5.18.2 opening subshell

On 23 March 2014 04:31, James E Keenan jk...@verizon.net wrote: And I have added: 'source ~/perl5/perlbrew/etc/bashrc' to the end of my ~/.bash_profile file. (AAMOF, it's the only entry yet in that file.) This might be the cause, I have that stanza in ~/.bashrc instead And this seems to

RFC Consensus on Network testing ENV?

If you grep CPAN you'll find a lot of ad-hoc ways of asking usespace if network testing is permitted. http://grep.cpan.me/?q=%28if|unless%29\s.%2BENV.*NET It seems wide spread enough that we may as well establish a common way of doing it, document it, and then enhance the available tooling to

Re: RFC Consensus on Network testing ENV?

On 12 June 2014 05:58, Jens Rehsack rehs...@gmail.com wrote: You never know whether a test fails because of failure or insufficient capabilities. So a restricting envvar isn't worse at all. I think he was more saying that he'd prefer: set NO_NETWORK_TESTING=1 over set

Re: wrt File::ShareDir

On 10 December 2014 at 20:48, Jens Rehsack rehs...@gmail.com wrote: Hi Kent, thanks for coming back on perl5-utils/File-ShareDir/pull/3. I really forgot that it's still open. While I discussed related things on cpan-workers@ and prove on File::ConfigDir + File::ConfigDir::Install how

On Not Merging new and old behavior ( was Re: Test-Stream + MongoDB scalar refcount issue )

On 3 May 2015 at 02:32, Aristotle Pagaltzis pagalt...@gmx.de wrote: That feels like “this is the point in our programme where we rethink the approach” to me; like a strong hint that the journey went down the wrong turn somewhere quite a ways back. I am in agreement, and a few of us are now

Re: On Not Merging new and old behavior ( was Re: Test-Stream + MongoDB scalar refcount issue )

On 3 May 2015 at 07:03, Stefan Seifert n...@detonation.org wrote: What would that mean from a user perspective? Would one be able to mix Test::More and Test::More2 (and higher level modules based on them) in the same test file? I initially thought this was desirable, but am now against that

Re: On Not Merging new and old behavior ( was Re: Test-Stream + MongoDB scalar refcount issue )

On 3 May 2015 at 08:24, Chad Granum exodi...@gmail.com wrote: I like the Test2 Idea, mind if I upload a module real quick to first-come the namespace? or are you going to claim it? +1 =) -- Kent *KENTNL* - https://metacpan.org/author/KENTNL

Re: On Not Merging new and old behavior ( was Re: Test-Stream + MongoDB scalar refcount issue )

On 3 May 2015 at 08:37, Chad Granum exodi...@gmail.com wrote: Looks like Test2 is already taken, which is odd considering a permission check on pasue did not show it, but when I tried to upload something it failed.

Re: On Not Merging new and old behavior ( was Re: Test-Stream + MongoDB scalar refcount issue )

On 3 May 2015 at 10:49, Chad Granum exodi...@gmail.com wrote: Test-Stream and Test-Builder effectively adds 1 dep, that is not burdensome. And before anyone suggests the total test time will be larger, the total test time will be the same as it is now because the layout is divided such that

Re: On Not Merging new and old behavior ( was Re: Test-Stream + MongoDB scalar refcount issue )

On 3 May 2015 at 07:49, Stefan Seifert n...@detonation.org wrote: To me this future sound like an even larger burden for downstream. The burden of extra namespace maintenance is annoying. Sure. But the price of the namespace itself is basically free. And a burdensome system as pertaining to

Re: File::ShareDir - Outstanding modernization

On 6 May 2015 at 12:33, breno oainikus...@gmail.com wrote: That said, I would rather see it in a new module than have it in File::ShareDir itself. Kinda like how nowadays I prefer Path::Tiny over File::Spec + Cwd (or even Path::Class). There is still a need for a simple mechanism for hooking

Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD

On 6 May 2015 at 19:26, Peter Rabbitson ribasu...@cpan.org wrote: Sorry for the sidetrack I was actually hoping for naming feedback :) The names suggested seem amenable to me. The only real problem I still have to resolve is what name we put non-article-oriented things like The Lancaster

Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD

On 7 May 2015 at 09:31, Neil Bowers neil.bow...@cogendo.com wrote: Please please please, let’s not put this on CPAN. There are enough abuses of CPAN already. It’s a comprehensive archive of Perl, not everything in any way related to Perl. Plus I wouldn’t want to constrain this sort of

Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD

On 7 May 2015 at 02:46, H.Merijn Brand h.m.br...@xs4all.nl wrote: How much I admire this effort (+1000 as you say from me as well), I think a structured HTML doc that people can download and read or PDF with index will reach a wider audience. Generally, with HTML, if I want to read HTML, I

Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD

On 7 May 2015 at 02:28, David Golden x...@xdg.me wrote: This is like the xkcd standards problem (https://xkcd.com/927/). I was literally waiting with baited breath for that to be referenced as I wrote the original email :D Before charging off down the path of using CPAN as a CDN because it's

Re: Measuring water quality of the CPAN river

On 11 May 2015 at 12:37, Neil Bowers neil.bow...@cogendo.com wrote: These are pretty simple, and have some problems, so I’m hoping someone might come up with something more useful. Random thought while reading: backflow could be a thing to check for. Some dists don't have tests, and still

Re: Measuring water quality of the CPAN river

On 11 May 2015 at 19:20, Neil Bowers neil.bow...@cogendo.com wrote: look at 2 or more CPAN Testers fails where the only difference is an upriver version number. my point didn't pertain to upriver versions changing, but the observation that upriver modules can have buggy code that is only

Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD

On 9 May 2015 at 09:54, Philippe Bruhat (BooK) philippe.bru...@free.fr wrote: Simple template with basic HTML around. For now, only markdown format is supported, but I intend to support additional formats as needed. I think some of this question I was looking for information as to how the

Re: Dependency List Approval / Problems for ExtUtils::Manifest

On 23 June 2015 at 10:24, David Golden x...@xdg.me wrote: I think the early toolchain list is in write_buildcustomize.pl: http://perl5.git.perl.org/perl.git/blob/HEAD:/write_buildcustomize.pl#l19 AFAICT, that makes the perl files in those lib directories available to miniperl directly in

Dependency List Approval / Problems for ExtUtils::Manifest

TL;DR^WABSTRACT: - Is it safe to bundle Test::TempDir::Tiny or similar in EUMs t/tlib? - I would really like it and it would make such testing cleanly much better, wow. --- I'm just going to scratch this together here since the varied discussions on IRC probably haven't seen the right people and

Re: democratizing some of my dists

On 14 November 2015 at 12:50, James E Keenan wrote: > doesn't that mean that its ownership is already democratized? Not fully until he gives somebody else publish bits. Software::License,RJBS,f Software::License::AGPL_3,RJBS,f Software::License::AGPL_3::or_later,VDB,f

Re: Should Test2 maintain $! and $@?

On 12 January 2016 at 13:53, Chad Granum wrote: > $! and $@ are altered by many many things, adding { local ... } around all > of them is a pain As much as I agree, and as much as this is a "thing in all perl, so we should expect this problem from every module" If I was to

Re: Should Test2 maintain $! and $@?

On 12 January 2016 at 16:14, Chad Granum wrote: > That said, it just occured to me that this can possibly be accomplished by > having a context store $! And $@ when it is obtained, then restore them when > it is released, which would avoid needing to use local everywhere, and

Re: Should Test2 maintain $! and $@?

On 13 January 2016 at 10:48, Sawyer X wrote: > > If so, I think you should probably clarify what Test2 *does* do. It > doesn't provide the functions - alright. What *does* it provide then? Oh, and thought: It may help to consider what testing /testing tools/ looks like here,

Re: Should Test2 maintain $! and $@?

On 14 January 2016 at 07:39, Chad Granum wrote: > Right now the version I have up on cpan just stores them on creation, and > restores them on final release. Nothing happens for nested calls to > context()/release(), all my downstream testing shows no breakages (not a > full

Re: Should Test2 maintain $! and $@?

On 18 January 2016 at 18:53, Chad Granum wrote: > Then again, if you /really/ want the mechanism in $ctx, I can add > $ctx->release_preserving (naming is hard, give me a better one) which does > have the behavior... but at that point, which behavior do you want, preserve >

Re: Last call for review of Test-Builder using Test2 (Formerly Test-Stream)

On 6 February 2016 at 08:14, Chad Granum wrote: > If there is anything in these > distributions (Test2 in particular) that makes you uncomfortable, you > need to speak now. Mentioning here for visibility: As with Test-Stream where the apparent silence lead to a premature

Re: addressing kwalitee and other quality issues at the head of the CPAN River

On 29 January 2016 at 13:01, Neil Bowers wrote: > - use warnings This can be a regression sometimes, adding warnings where there are none in novice code is good. But people who know what they're doing may omit warnings on purpose. So this is not so much a "Quality"

Re: addressing kwalitee and other quality issues at the head of the CPAN River

On 29 January 2016 at 13:01, Neil Bowers wrote: > adding min perl version I'd be particularly careful with that one. People who don't know what they're doing are predisposed to set a bar at a premature location. For instance, if somebody has a motto of /attempting/ 5.6

Re: Why do we keep using META.json for stuff that has nothing to do with installation

On 28 February 2016 at 00:06, Peter Rabbitson wrote: > perhaps rethinking "Meta for end-user install purposes" and > "Meta for meta" would solve most of the recent repeated breakages by "oh > downstream doesn't like this new thingymagic" +1 I've been frustrated by this

Re: Renaming the "QA Hackathon"?

On 10 April 2016 at 03:45, David Golden wrote: > Perl Toolchain Summit Because "Toolchain" is not really a word that necessarily makes sense outside Perl, you can use "Infrastructure" or even "Critical Infrastructure" in its stead. ( I personally like Critical, its a

Re: Renaming the "QA Hackathon"?

On 10 April 2016 at 04:49, Sawyer X wrote: > Perl Annual Critical Infrastructure Summit. Perl Infrastructural Engineering Summit. PIES. :D Summit of Perl Infrastructural Critical Engineering. SPICE. Hth. -- Kent KENTNL - https://metacpan.org/author/KENTNL

Re: Thoughts on Kik and NPM and implications for CPAN

That scenario doesn't seem right. A mere deletion of a .pm file in a future release aught to be the tripwire for such a warning. An explicit namespace clearance is much more dire. On 25/03/2016 11:51, "Neil Bowers" wrote: > I wonder what the volume in one case vs the

Re: Open source archives hosting malicious software packages

On 22 September 2017 at 00:11, David Cantrell wrote: > But is anyone paying attention? I assume you're talking about > #cpantesters, which I'm on, but I hardly ever look at it, and when I do > look I certainly don't look at scrollback, let alone looking at > scrollback

Re: Open source archives hosting malicious software packages

On 21 September 2017 at 20:24, Neil Bowers wrote: > I’ll tweak my script to not worry about packages in the same distribution > (eg Acme::Flat::GV and Acme::Flat::HV). Then I just need to get a list of > new packages each day, and I’m just about there :-) I'd probably

Re: Making www.cpan.org TLS-only

> downloading CPAN content roughly to: > internet connection to not muck with the code you receive. > > Obviously the real fix here is that clients need to request via TLS (since I > doubt any clients other than regular browsers support HSTS). I was under the impression that any "code" ( eg:

Re: Making www.cpan.org TLS-only

On 1 September 2017 at 13:10, Ask Bjørn Hansen wrote: > Hi everyone, > > We’re considering how/how-much we can make www.cpan.org TLS-only. > http://log.perl.org/2017/08/tls-only-for-wwwcpanorg.html > > I expect that we can’t make the whole site TLS-only without breaking some >

Re: Confirming PAUSE operating model safe harbor for Alt::* distributions

On 31 October 2017 at 15:54, David Golden wrote: > On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis > wrote: >> >> >- Per the "explicit user confirmation", I think an explicit opt-in >> > must be present, not merely checking for overwriting via