Re: CMSP 08. Extensibly Group Prereqs

[Adam Kennedy]

A quick comment on this one, before work begins on implementing it.

This proposal involves the creation of 8+ new dependency types, none
of which have been discussed in detail as far as I can tell.

Pending rigourous analysis of the implications of this proposal, I
think it's fluff. It sounds like a good idea, but it's really just
housecleaning without any specific goal in mind.

-1

Adam K

Re: CMSP 13. Add a post_depends set

[Adam Kennedy]

Opposed until someone can demonstrate working dependency algorithms
that take this into account.

-1

Adam K

Re: CMSP 33. Install Meta files and make them queryable

[Adam Kennedy]

I concur, this is better addressed in a packfile 2.0 process at a later date.

Adam K

On Sun, Nov 1, 2009 at 2:48 AM, David Golden xda...@gmail.com wrote:
 On Fri, Oct 9, 2009 at 7:56 AM, David Golden xda...@gmail.com wrote:
 33. Install Meta files and make them queryable

 Proposal: Using something like .packlist or File::ShareDir, the Meta file
 should be installed along with the distribution and Meta tools should allow
 easy querying of meta information for installed modules. (Dagolden)

 Comments:

 * Lots of meta information is unavailable in a structured way after a
  distribution is installed.  By installing the Meta file (e.g. in
  auto/meta/Foo-Bar/META.yml) we retain it after installation and can make
  it available for other tools.  (Dagolden)

 * Should the installed meta be identical to the Meta file in the
  distribution or should it be stored in a neutral format (e.g
  Data::Dumper)?  (Dagolden)

 * I'd be happy to just install the MYMETA.yml file as is. Perhaps it could
  be extended slightly to create a packlist 2.0 type file, it's been a
  long time since packlists have been reviewed. -- Adam K


 Having reflected further on this, it doesn't really change the spec,
 so I suggest dropping it from the 2.0 process and reconsidering after
 2.0 support is done in the toolchain.

 -- David

Re: CMSP 34. Formally reserve keys for private 'in-house' use

[Adam Kennedy]

I'd prefer we avoid pointless flexibility.

Recommend we pick one, and since underscore requires less quoting and
can be used as part of a method name, recommend we go with that.

Adam K

On Sun, Nov 1, 2009 at 7:07 AM, David Golden xda...@gmail.com wrote:
 On Mon, Oct 12, 2009 at 10:08 AM, David Golden xda...@gmail.com wrote:
 On Mon, Oct 12, 2009 at 5:33 AM, Zefram zef...@fysh.org wrote:
 David Golden wrote:
For this reason I'd like to formally define the acceptance of 'x-' prefixed
key names.

 Good concept, but I think x_ would be a better prefix than x-.
 We've already established usage of _ to separate words, making the
 top-level hash keys satisfy identifier syntax.  (Except for meta-spec,
 which is an ugly exception.)

 I don't have a strong feeling about x_ vs x-.  The former is more
 consistent with the naming pattern of the spec and the latter is more
 consistent with how extension fields are named in a lot of RFCs.

 Since no one has strong feeling about it, the new rule shall be qr{^x[_-]}i.

 Patch here:

 http://github.com/dagolden/cpan-meta-spec/tree/34-private-keys

 -- David

Re: CPAN Meta Spec Proposal discussion period has ended -- summary of results

[Adam Kennedy]

Which version of version.pm, it moves.

What happens if it changes slightly in the future.

Adam K

On Tue, Nov 3, 2009 at 12:35 PM, David Golden xda...@gmail.com wrote:
 On Mon, Nov 2, 2009 at 7:45 PM, Ricardo Signes
 perl.cpanw...@rjbs.manxome.org wrote:
 * Adam Kennedy a...@ali.as [2009-11-02T18:24:26]
 I'd like to propose that all changes to the META.yml be fully and
 completely defined, without resort to the behaviour of external code.

 That is to say, all cases where a value must be in some enum should
 describe the full list, instead of reaching for Any value that
 Some::Module allows.

 Agreed.  Do you know if there are any counterexamples in the current draft?

 I'll try to look a bit later.

 I agree as well.  I believe we've removed most if not all.

 The one place that external modules creep back in is version number
 parsing and comparison.  I don't think it's productive or perhaps even
 possible to specify anything other than the behavior of
 MM-parse_version and the Module::Build equivalent.  Likewise version
 comparison is only sane using version.pm because of how that logic is
 hard-coded into Perl 5.10+.  I have, however, tried to give very
 specific, exact examples for usage.

 -- David

Re: Perl 6 versus the CPAN

[Adam Kennedy]

It's been something of a long-standing (second-order) problem that
packages are just tarballs (or bzipball, or zips, etc).

The lack of a standard file extension means that we can't sanely
implement features like double-click to install on operating systems
and browsers with file extension association capability.

If we are looking at not only sharing user permissions between the two
languages, but also sharing the author directories directly, this
would seem like a highly opportune moment to switch to a new specific
extension for P6 distributions.

It would help the current indexer, because Andreas can just ignore
files with that extension, and it would make it trivial for the new
indexer to ignore Perl 5 and legacy files.

Adam K

On Mon, Jan 4, 2010 at 10:23 PM, Zefram zef...@fysh.org wrote:
 Ovid wrote:
 From the Rakudo test suite:

  use perl5:Text::Wrap 'wrap';

 That would seem to settle it, then: perl5:Config::INI does not conflict
 with perl6:Config::INI.  The absolutely next thing we need is naming
 convention for Perl 6 module distributions on CPAN: it could perhaps
 be p6-Config-INI-1.00.tar.gz, or Config-INI-1.00.tar.gz in a different
 directory from where the Perl 5 one lives.  The next thing we need after
 that is an index of Perl 6 modules on CPAN.

 -zefram

Re: Perl 6 versus the CPAN

[Adam Kennedy]

I'd rather like to avoid adding additional complexity to the current
index files.

Instead, what about switching to a native SQLite index for the new system.

This is working quite nicely in the JSAN now, and it greatly
simplifies things because you can download the index much more simply.

1. Pull gzip
2. Expand
3. Connect

If we wanted to fragment the index, we could just download the extra
parts of the index and then do an ATTACH DATABASE to load in the
additional fragment.

This would, of course, mean that SQLite and DBI support is needed in
the core for Perl 6.

But since (I gather) the P6 core will be even lighter than the Perl 5
one, and there will be a sort of Standard Library defined
independantly that includes the modules needed to install other
modules, this might not be too hard to overcome.

How hard would it be, in principle, to have SQLite and DBI support in
Perl 6? Can you do all the necessary C fu yet?

Failing this, a simple idea has been to produce a JSON structure which
has a similar logical structure to the database.

{
   author_table: 
...
}

Adam K

On Tue, Jan 5, 2010 at 9:15 AM, brian d foy brian.d@gmail.com wrote:
 In article 20100104154532.ge6...@bestpractical.com, Jesse Vincent
 je...@bestpractical.com wrote:


 This brings us to How do we get there from here?   Who are the folks
 working on the Perl6 CPAN client?

 Well, here's what I'm doing:

 I think the first step is very simple. My interest is porting the Perl
 6 module ideas into Perl 5. However, the code or implemention don't
 matter. Once we know the answer, it's easy to go from whatever I might
 do in Perl 5 to something in Perl 6.

 02packages is actually quite flexible. There's a line in the header
 that tells consumers what the columns are. Since we've used the same
 three columns, a lot of stuff has assumed that the order and meaning
 will always be the same. We fix the current stuff to pay attention to
 the headers. If we reorder the columns or stick in a new column,
 nothing breaks.

 After that, we produce additional indices that include more
 information, such as the author, a canonical flag perhaps, and other
 stuff. This isn't necessarily something that PAUSE would do. Alternate
 authorities can make indices. For the past year I've been working with
 a couple of paying clients to make custom CPAN repositories. I have
 most of the pieces in place. Think, for instance, about a market
 segment
 that wants to only use CPAN as it was on June 1, when their application
 went into code freeze. I can produce an index that replicates that.
 That's not the same thing as saving the PAUSE index since dists
 disappear arbitrarily.

 Once we have the index, we have a way to ask for what's available, say,
 for CGI.pm. That's easy, in the sense that you don't have to draw too
 much on a whiteboard, and not so bad in the pause and CPAN.pm code for
 those of us who have our noses in there constantly.

 Okay, all of that is step one and it's something I'm working on.

 Step two is figuring out how to decide which all of the things that are
 available are the most suitable. That's where a lot of people argue
 endlessy in mailing lists, then Andreas or Jarkko or somebody tells us
 the answer.

Re: CPAN vs Perl 6

[Adam Kennedy]

... or, like JSAN does, all of the above.

We make multiple different formats available, as many as people ask
for pretty much.

As long as they stay in sync, there's no real problems that happen
from encoding the index in N number of ways.

Adam K

On Wed, Jan 6, 2010 at 2:59 PM, Ask Bjørn Hansen a...@perl.org wrote:
 For other tools having a more complete data structure would be nice; but 
 there's no reason that PAUSE couldn't produce indexes in different formats.  
 If so then the optional fancy index could be any combination of SQLite, 
 JSON, buzzword-bingo-of-the-day that we like.

Re: CPAN and XDG directories

[Adam Kennedy]

(b) sounds like an interesting idea.

Adam K

On Fri, Feb 19, 2010 at 2:03 AM, David Golden xda...@gmail.com wrote:
 On Thu, Feb 18, 2010 at 9:12 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote:
 I of course ran `perl Makefile.PL ; make ; make testdistro ; make test` on 
 the
 source directory before committing and encountered no problems. Tests pass, 
 my
 configuration below `$HOME/.config` was not overwritten, and also no
 `$HOME/.cpan` directory appeared again once I earlier had deleted it for 
 good.
 So, »works on my machine«.

 Are you referring to the tests of the CPAN distro or something else?

 Anything *else* on CPAN that does this:

 (a) uses File::HomeDir-my_data

 (b) Overrides $ENV{HOME} to a temp directory for testing creation of
 config files (instead of, say, mocking File::HomeDir-my_data)

 This presumes that they don't care or don't realize that $ENV{HOME}
 doesn't affect my_data on Windows.

 Adam's suggestion is only a so-so answer because users might
 legitimately have reasons to set HOME and XDG_DATA_HOME differently.

 The handful of modules I spot check seem to either just use my_home()
 directly instead of my_data() or if they use my_data(), they mock it
 or have some other override that avoids File::HomeDir entirely.

 Here's my revised suggestion:  add something to the File::HomeDir
 module (or distribution) that is the official way to mock/override
 File::HomeDir for testing and then advertise the hell out of it.  (And
 possibly email every author that uses File::HomeDir on CPAN)

 That could be any of these:

 (a) Some global variable that takes precedence over HOME, HOMEDIR,
 XDG_*, whatever

 (b) A File::HomeDir::Mock module that creates a temporary directory
 and points every other call to a subdirectory of it.  E.g.

    /tmp/File-HomeDir-tmp498723487/
        my_home/
        my_data/
        my_documents/
        ...

 I think (b) is a safer bet.  Ideally, tests would just need to load it
 early, and then it would ensure that all subsequent use of
 File::HomeDir in that process is safely segregated from real user
 data.

 -- David

 P.S. Alias++ for the pun

Re: Trimming the CPAN - Automatic Purging

[Adam Kennedy]

What he said.

Most people don't mirror CPAN. They mirror many things.

This is the same reason we've struggled with statistics. How do you
ask someone mirroring three dozen different things to put in a special
log-munging tool just for us.

Adam K

On Fri, Mar 26, 2010 at 10:55 AM, Ask Bjørn Hansen a...@perl.org wrote:
 Most CPAN mirrors use rsync.  It's not realistic to make them change that 
 (Hello all mirror operators -- so that tool that you use for ALL YOUR 
 MIRRORS; well ... maybe you can use something else for us?).

Re: Distributing the CPAN

[Adam Kennedy]

On Fri, Apr 2, 2010 at 4:11 AM, Michael G Schwern schw...@pobox.com wrote:
 * The need for widespread mirroring is less significant than it was in
 years past. (Also using git as the inter-mirror transport of source files
 means there'll be much less traffic between mirrors. Effectively only
 the diffs between releases.)

 Not being a sysadmin, this is my gut feeling.  Relative to hard drive
 prices, CPAN (hell, BackPAN) has shrunk.  I'd imagine the same to be
 the case relative to network capacity.

I keep a year's worth of historical Apache logs for the
cpan.strawberryperl.com redirector, which I would imagine is one of
the more heavily used mirrors.

If anyone wanted access to these logs to get some idea of the how much
network traffic mirrors do, I can make them available.

Adam K

Re: How to have Perl 5 and Perl 6 cohabitate nicely on CPAN

[Adam Kennedy]

This has already existed for about a year or more.

See pip's .p5i file (which I think cpanminus also supports).

Adam K

On Fri, Apr 16, 2010 at 12:56 AM, Curtis Jewell
lists.perl.cpan-work...@csjewell.fastmail.us wrote:
 Why don't we make the .cpan/.c6pan file (.c6pan) a JSON file, generated
 by PAUSE once the tarball is uploaded, with whatever information is
 required (a reference to the tarball, what version of perl is required,
 etc.) in order, when that file is passed to a CPAN client, to download
 and install the tarball.

 I don't see why a double-clickable file (or what-have-you equivalent)
 necessarily has to be the distribution tarball?

 That way, the tarball can keep its extension... best of both worlds yet?

Re: How to have Perl 5 and Perl 6 cohabitate nicely on CPAN

[Adam Kennedy]

I'm pretty sure that's true for all such systems, including things
like .war files.

Even if we split, say, Strawberry from ActivePerl, what if you have
multiple installations of ActivePerl?

Adam K

On Fri, Apr 16, 2010 at 8:56 AM, Jan Dubois j...@activestate.com wrote:
 On Thu, 15 Apr 2010, Barbie wrote:
 On Thu, Apr 15, 2010 at 02:58:12PM -0700, Jan Dubois wrote:
  Yes, it certainly downloads prerequisites from the configured repositories.
  I was talking about downloading .ppmx files from some random website that
  you didn't configure first as a repository in the PPM client.  The double-
  clicked file is not able to download additional prerequisites from that
  random website it came from itself.  Think private/internal repository
  of a bunch of interdependent modules.

 Got it. However, I was thinking the initial file (ppmx) would essentially
 be a stand-alone download, the installer would then revert to the
 predefined repos to download the prerequisites.

 Yes, that's how it works.

 In PPM's case there are only a few repos that try to keep up with CPAN,
 so knowing where the original repo was may be significant.

 This is not important for modules on CPAN.  It is important for modules
 whose prerequisites are *not* on CPAN and only exist in the same location
 as the original ppmx file.

 The way around this is probably to implement a protocol handler like

    ppm://random.example.com/repo/my-random-module.ppmx

 That way the browser would invoke the protocol handler with the full URL

    ppm install ppm://random.example.com/repo/my-random-module.ppmx

 instead of downloading the tarball via HTTP itself and then just passing
 a local filename to the installer:

    ppm install /tmp/downloads/my-random-module.ppmx

 Implementing a protocol handler for the major operating systems is somewhat
 more involved than just setting up a file extension/MIME type mapping though.

 However, if we're downloading from CPAN, then it would be reasonable
 to try and grab prereqs from a predefined set of CPAN mirrors.

 This all is not an issue if the extension mechanism only has to work
 for CPAN and can ignore the DarkPAN.

 One other issue that has been ignored so far is that neither the file
 extension nor the protocol scheme will work particular well if you have
 multiple Perl installations on your machine. You cannot direct the
 automatic download/install to a particular instance.

 Cheers,
 -Jan

Re: Why are versions restricted to 999?

[Adam Kennedy]

 I was worried that was it.  That conversion should be considered,
 but not enshrined in the spec as a limit.

999 revisions ought to be enough to anyone

Re: so long, CPAN

[Adam Kennedy]

If we can get the MIRROR.yaml|json system I proposed finally deployed,
this rewrite would become trivially easy.

Adam K

On Sun, Sep 26, 2010 at 10:52 PM, Jarkko Hietaniemi j...@iki.fi wrote:
 On Sunday-201009-26 8:16, Ask Bjørn Hansen wrote:

 On Sep 26, 2010, at 4:49, Jarkko Hietaniemi wrote:

 It has become the time for me to admit to what has probably been pretty
 obvious for anyone else already for some time - I do not have the time
 to give CPAN the attention it deserves.  Time to pass the baton, etc.

 Thank you Jarkko -- had it not been for your early invention and work with
 CPAN I don't think many of us would be here or be as productive with Perl as
 we are.

 On a more urgent note: could you and Elaine coordinate on moving/copying
 stuff out of gargoyle where e.g. the mirrors.cpan.org runs?
 The webster.edu has given us a strong hint of moving out a.s.a.p.
 I think the first order of things would be just copying data out of
 gargoyle, we can worry about the services later.

 In the FUNET side things are not as critical to move out though their
 admins do worry about the insane rsync load.  Whatever the future
 system is, direct plain rsync connections should not be recommended:
 rsync is just too heavy.  I and Elaine do have accounts to FUNET
 and can move stuff in and out (more accounts though not impossible
 are unlikely).

 Regarding the maintenance scripts in FUNET: there isn't much that I
 would be, ahem, proud to share: they are mostly dead simple shell /
 very early Perl 5 scripts.  For 95% of that stuff I would recommend writing
 from scratch.  Perhaps the most important new thing needed
 would be some sort of CPAN mirror staleness alerting script, as input
 using Henk Pennings' mirror scan results.  I had over the years a few of
 those systems, all of them rotted eventually.  As an extension of just
 checking the timestamp of the magical timestamp file, it would be nice
 to have some sort of random sampling of mirrors: are they really valid
 uptodate mirrors?


  - ask

Re: Leo is skinning www.cpan.org

[Adam Kennedy]

On Mon, Sep 27, 2010 at 12:31 PM, Ask Bjørn Hansen a...@perl.org wrote:
 Related notes: would it make sense to sign the (timestamped) list of mirrors?

I added some heuristic anti-hijacking stuff to a previous version of
Mirror::JSON so it would at least provide a basic level of projection.

Basically, if it sees the master server change from the last version
it has stored (or the default one it is bundled with) it will try to
contact additional mirrors to confirm the master change.

That wouldn't fix a DNS hijack of course, but it would hopefully mean
you have to compromise several mirrors and not just one.

WRT to signing, I fear the crypto bootstrapping issues we'd suffer.

However, in the same vein as index multi-formatting, perhaps we could
make it optional.

One signed, and one unsigned. Client picks the level of safety they want.

Adam K

Re: Adjusting CPAN::Mirrors to make it more useful

[Adam Kennedy]

I think I may have implemented what you're looking for several years
ago for JSAN, which has a client that auto-detected appropriate
mirrors in a few seconds each time it starts.

http://search.cpan.org/~adamk/Mirror-URI-0.90/lib/Mirror/YAML.pm

Or at least, something similar to it.

It autodetects mirrors, can validate them for both speed and
staleness, and doesn't give a crap about where they or you are
physically in the world.

It auto-updates to new master servers, and is resistant to mirror/repo
hijacking, and it can (with a tweak to support an async library) do it
in parallel.

Adam K


On Tue, Feb 8, 2011 at 5:55 PM, brian d foy brian.d@gmail.com wrote:
 I've cloned the cpanpm repo and played with CPAN::Mirrors to make it a
 bit more useful for things outside of CPAN.pm. Most of its use in
 CPAN.pm is to support urllist in CPAN::FirstTime, but I want to use it
 to also update the urllist as I travel, and create other interesting
 applications for it.

 I haven't merged anything, but you can look at the firsttime branch:

 https://github.com/briandfoy/cpanpm/blob/firsttime/lib/CPAN/Mirrors.pm

 I have some other refactorings to do, but I don't want to drop them all
 on you at once.

 And, who makes the MIRRORED.BY file? I imagine that's something from a
 script that Jarkko makes, but how does it get the data? I'd like to see
 about exporting it as JSON or something. Also, is it something that
 noc.perl.org has to handle as the master CPAN moves off of FUNET?

 --
 brian d foy brian.d@gmail.com

Re: How To Build A Perl Package Database

[Adam Kennedy]

Packlist 2.0

MYMETA + installed file details

?
On Dec 17, 2012 12:36 AM, Tim Bunce tim.bu...@pobox.com wrote:

 On Sun, Dec 16, 2012 at 04:53:49PM -0800, Michael G Schwern wrote:
  On 2012.12.16 11:57 AM, Leon Timmermans wrote:
 
   * Where to put the database?  What about non-standard install
 locations?

   Another is to have a separate install database for non-standard
 install
   locations.

 A separate install database for each install location seems like the only
 workable approach.

   This makes sense to me, but it brings in the sticky problem
   of having to merge install databases.  Sticky, but still a SMOP.
  Once you
   have to implement merging anyway, it now makes sense to have an
 install
   database for each install location.  One for core.  One for vendor.
  One for
   perl.  And one for each custom location.  This has a lot of
 advantages to
   better fit how Perl layers module installs.
  
   * allows separation of permissions
   * allows queries of what's installed based on what's in @INC

 Perhaps that could be taken one step further: one per installed
 distribution.

 Then, what's kept at each install location is a cached summary of what's
 installed below it. One that can be cross-checked against the individual
 distribution 'databases' and rebuilt from it.

 That seems more robust against various kinds of 'damage'.

   That second one is important.  When a normal user queries the
 database, they
   want to get what's installed in the standard library location.  When a
   local::lib user queries the database, they want to get what's
 installed in the
   standard library locations AND their own local lib.

 I.e., the default view is what's installed in my @INC.

   The combination of these is problematic. You might upgrade EU::Install
   in your local module path, but not have write permissions on the
   system paths. In practice, we might have to support all our older
   versions :-|
 
  Erg, good point.  That very likely scenario is definitely going to
 require
  some thought.

 *nods*

 Here's where one install database per distribution with a cache
 database at the install location offers another benefit.
 The per distribution install database can be kept in a very simple
 plain text format that targets readability and future-proofing,
 while the cache database at the install location can target
 performance.

 If an install location has an incompatible version of the db,
 the per distribution dbs could be read instead. That's slow but workable
 and seems reasonable for that presumably uncommon case.
 I can think of a few further options as well.

 Tim.

Re: No . in @INC breaks CPAN

[Adam Kennedy]

You should probably scan CPAN for other uses of use inc::...

My darker memory is throwing up some other potentially false positive red flags.

File::ShareDir may be worth a look as it did some fairly funky stuff at 
build/test time... at one point in its history.

Anything file in CPAN with an explicit mention of Makefile.PL in a string is 
maybe worth a quick scan, for CPAN like tooling that doesn't use CPAN itself.

Adam

> On 14 Nov. 2016, at 6:11 am, Todd Rinaldo  wrote:
> 
> Howdy,
> 
> I've done a write up of a recent change to blead perl. In the future it will 
> no longer be possible to count on . being in @INC. This will break many of 
> the existing CPAN installs.
> 
> It was suggested I send the RFC here:
> 
> http://blogs.perl.org/users/todd_rinaldo/2016/11/how-removing-from-inc-is-about-to-break-cpan.html
> 
> In Perl 5.26, it will no longer be a safe assumption to assume . is in @INC. 
> This is a good move towards a more secure Perl, but will break the 
> installation of many CPAN modules. For those of you wondering why this was 
> done, see this post for more information.
> 
> Many CPAN modules try to do things like: use inc::Module::Install; This 
> depends on . being in @INC. If you invoke Makefile.PL without it, the script 
> will not even run.
> 
> We have come up with several ways to mitigate and ultimately fix the problem:
> 
> Short Term
> 
> Perl 5.26 will support an environment variable "PERL_USE_UNSAFE_INC=1". If 
> you set this, any perl script invoked will include . at the end of @INC. 
> Tentatively, support for this environment variable will be immediately 
> deprecated since long term, the CPAN modules need to simply take this into 
> account.
> 
> My current thinking is that if we inject this environment variable into the 
> CPAN clients (cpanm, cpan, cpanplus, etc.), then they will build and install 
> modules as they normally did. Packagers (RPM, deb, etc.) will also need to 
> amend their build systems by also setting this environment variable. It is 
> also possible that a fix will be require to CPAN smoke testers.
> 
> Long Term
> 
> We need to fix the CPAN modules themselves. The vast majority of modules can 
> be fixed by putting use lib "."; at the top of Makefile.PL or Build.PL. 
> Others will need to fix additional scripts in their tree to also take this 
> into account. In some cases use blib; might be more appropriate, for 
> instance, in unit tests which invoke child scripts.
> 
> My original proposal included a patch to ExtUtils::MakeMaker, Module::Build, 
> and Module::Build::Tiny. At this point I think that this might be the wrong 
> place to fix the problem.
> 
> These are all my thoughts based on conversations with others about how this 
> transition needs to be addressed. I do not claim to have all the correct 
> answers. I am using this blog post to anchor the conversations that need to 
> be had with multiple groups (CPAN Testers, P5P, Tool Chain Gang, etc.).
> 
> If you want to try a Perl with this functionality now, you will need to build 
> Perl with the Configure option: -Ddefault_inc_excludes_dot. This is available 
> in blead and the next development build of perl.
> 
> I'll be opening a ticket with the CPAN clients this week. If you know of 
> other items that need consideration, please let me know in comments or feel 
> free to reach out to me or perl 5 porters.
> 
> -- Todd

Re: No . in @INC breaks CPAN

[Adam Kennedy]

That doesn't help those of us with a habit of naming our test modules 
t::Foo::Bar

I think there's a fair few things with copies of test modules bundled that way.

Adam

> On 14 Nov. 2016, at 11:45 am, Karen Etheridge  wrote:
> 
> > In this case, adding '.' to the distribution's Makefile.PL made no 
> > difference.  I had to add "use lib ('.');" to Auxiliary.pm to enable it to 
> > locate 'eligible_chars', after which 'make test' PASSed.
> 
> > Based on this example and several other failures, my hunch is that many of 
> > the failures which we'll see on CPAN are failures of *tests* rather than 
> > failures of the modules themselves.
> 
> I would agree.  I'd also encourage authors to not add "use lib '.';" to their 
> tests to fix these issues, but rather move the test modules to t/lib and 
> instead "use lib 't/lib'".
> 
> 
>> On Mon, Nov 14, 2016 at 10:56 AM, James E Keenan  wrote:
>> 
>> On 11/14/2016 09:11 AM, Todd Rinaldo wrote:
>> > Howdy,
>> >
>> > I've done a write up of a recent change to blead perl. In the future it 
>> > will no longer be possible to count on . being in @INC. This will break 
>> > many of the existing CPAN installs.
>> >
>> > It was suggested I send the RFC here:
>> >
>> > http://blogs.perl.org/users/todd_rinaldo/2016/11/how-removing-from-inc-is-about-to-break-cpan.html
>> >
>> > In Perl 5.26, it will no longer be a safe assumption to assume . is in 
>> > @INC. This is a good move towards a more secure Perl, but will break the 
>> > installation of many CPAN modules. For those of you wondering why this was 
>> > done, see this post for more information.
>> >
>> > Many CPAN modules try to do things like: use inc::Module::Install; This 
>> > depends on . being in @INC. If you invoke Makefile.PL without it, the 
>> > script will not even run.
>> >
>> 
>> Here is a use case which I found very soon after building a perl at blead 
>> with the new option and then installing App::cpanminus against that perl.
>> 
>> #
>> Summary of my perl5 (revision 5 version 25 subversion 7) configuration:
>>   Commit id: dd4f16e4ff71ea6d0422d277f00fe430e1d93938
>> [snip]
>> config_args='-des -Dusedevel -Uversiononly 
>> -Dprefix=/home/jkeenan/testing/nodot -Dman1dir=none -Dman3dir=none 
>> -Ddefault_inc_excludes_dot'
>> [snip]
>>   @INC:
>> lib
>> /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7/x86_64-linux
>> /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7
>> /home/jkeenan/testing/nodot/lib/perl5/5.25.7/x86_64-linux
>> /home/jkeenan/testing/nodot/lib/perl5/5.25.7
>> #
>> 
>> I used ./bin/cpanm to install one of my CPAN distros that has a second-level 
>> dependency on another one of those distros, Perl-StringIdentifier.
>> 
>> #
>> Building and testing String-PerlIdentifier-0.05 ... FAIL
>> ! Installing String::PerlIdentifier failed. See 
>> /home/jkeenan/.cpanm/work/1479138905.14485/build.log for details. Retry with 
>> --force to force install it.
>> #
>> 
>> Let's inspect that build log.
>> 
>> #
>> PERL_DL_NONLAZY=1 "/home/jkeenan/testing/nodot/bin/perl" 
>> "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef 
>> *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
>> Can't locate t/eligible_chars in @INC (@INC contains: t/ 
>> /home/jkeenan/.cpanm/work/1479138905.14485/String-PerlIdentifier-0.05/blib/lib
>>  
>> /home/jkeenan/.cpanm/work/1479138905.14485/String-PerlIdentifier-0.05/blib/arch
>>  /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7/x86_64-linux 
>> /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7 
>> /home/jkeenan/testing/nodot/lib/perl5/5.25.7/x86_64-linux 
>> /home/jkeenan/testing/nodot/lib/perl5/5.25.7) at t/Auxiliary.pm line 14.
>> Compilation failed in require at t/01_basic.t line 8.
>> BEGIN failed--compilation aborted at t/01_basic.t line 8.
>> # Looks like your test exited with 2 just after 1.
>> t/01_basic.t ..
>> Dubious, test returned 2 (wstat 512, 0x200)
>> Failed 40/41 subtests
>> #
>> 
>> Here's what that distro has in/under its 't/' directory.
>> 
>> #
>> $ ls t |cat
>> 01_basic.t
>> 02_specified.t
>> 03_min.t
>> 04_max.t
>> 05_default.t
>> 06_no_scores.t
>> Auxiliary.pm
>> eligible_chars
>> #
>> 
>> #
>> $ head t/01_basic.t
>> # t/01_basic.t - four basic tests
>> use Test::More tests => 41;
>> use strict;
>> use warnings;
>> 
>> BEGIN { use_ok( 'String::PerlIdentifier' ); }
>> use lib ("t/");
>> use Auxiliary qw{ _first_and_subsequent };
>> 
>> four_basic_tests() for (1..10);
>> #
>> $ head -15 t/Auxiliary.pm
>> package Auxiliary;
>> use strict;
>> use warnings;
>> our ($VERSION, @ISA, @EXPORT_OK);
>> $VERSION = '0.05';
>> require Exporter;
>> @ISA = qw(Exporter);
>> @EXPORT_OK   = qw(
>> _first_and_subsequent
>> );
>> *ok = *Test::More::ok;
>> use lib ('.');
>> 
>> our (%eligibles, %chars);
>> require "t/eligible_chars";
>> #
>> 
>> The test file attempts to load Auxiliary.pm, which is located in 

Re: Network connection

[Adam Kennedy]

Additional note.

The internet is not all the same. Different network environments will screw
you on almost anything you try, especially if it’s not HTTP (which at least
has protocols in operating systems for detecting “real internet”)

Don’t do it in install tests, generally.

Adam

On Tue, 14 Nov 2017 at 9:29 pm, Adam Kennedy <a...@ali.as> wrote:

> I have fragments and variations of this stuff tucked away in old code I’m
> sure.
>
> Look at LWP::Online and Test::NeedsDisplay, and I may have done similar
> things in the test suites for ORDB::*
>
> Adam
>
> On Sun, 12 Nov 2017 at 7:00 am, James E Keenan <jkee...@pobox.com> wrote:
>
>> Is there any code which is considered "best practice" for "skip_all
>> unless I have an Internet connection"?
>>
>> For the first time I want to write a library whose tests will benefit
>> from connection to an FTP server.  If there is some code that I could
>> just drop in for situations where the test suite is run offline, that
>> would be helpful.
>>
>> Thank you very much.
>> Jim Keenan
>>
>