All CPAN releases (these days) include a metadata file which has information about the distribution. It can be used by tools like CPAN clients (when installing modules), but it's also helpful for other tool writers, and people analysing the structure of CPAN. The metadata file will be called META.yml or META.json, and recent releases often contain both.
In this blog post we'll introduce some of what's in the files and how they're used by CPAN clients.
This post is brought to you by FastMail, a gold sponsor for this year's Toolchain Summit, which is being held in Lyon, France in May. The summit is only possible with the support of companies like FastMail. We'll be doing a series of toolchain-related blog posts, to thank our sponsors.
I've been looking for a better way to access the public CPAN metadata in files such as 02packages.details.txt and 06perms.txt, for checking the module index and CPAN permissions. For the latter you can always sign into https://pause.perl.org but I found that to be inconvenient. So I wrote a simple app that caches these files, converts them into a SQLite database, and then serves query results. You can find the result here: http://cpanmeta.grinnz.com/ and the source on GitHub. If there's any other metadata files that you want to be searchable let me know in a comment or GitHub issue.
berrybrew, the Perlbrew for Windows has been updated.
The significant new feature is the ability to automatically fetch the available Perl instances using Strawberry's new JSON releases file. This does not happen every time you use
available, as I didn't want to force a user to have to be connected to the Internet while using
berrybrew. Instead, I added a new
berrybrew fetch command that does the work.
Things to know:
- we now only list the most recent point version of each major release (this may change in the future)
- we list the 64bit, 32bit and the PDL version of each major release, where available (this may also change to include other versions, such as
- upon the first fetch, if any of the currently installed instances are lower than the most recent point release per version, we register them as
custom installs. This allows them to continue to be maintained by
berrybrew, and don't fall off the map as orphaned instances
Toronto.pm is hosting a LWP Hack Night tomorrow (Thursday) evening @ 7 PM. If you're interested in attending in person or virtually, I've put together a getting started guide. You don't need to be in the know in order to participate. The sheer volume of open issues means that there is plenty of low hanging fruit.
On a related note, I also announced a very helpful new module, LWP::ConsoleLogger::Everywhere, which can help you in debugging 3rd party HTTP requests made by the LWP family.
This document is the March, 2017 progress report for TPF Standardization,
Test Coverage, and Documentation of Perl 6 I/O Routines
My delivery of the Action Plan was one week later than I originally
expected to deliver it. The delay let me assess some of the big-picture
consistency issues, which led to proposal to remove 15 methods from IO::Handle
and to iron out naming and argument format for several other routines.
I still hope to complete all the code modifications prior to end of weekend of
April 15, so all of these can be included in the next Rakudo Star release. And
a week after, I plan to complete the grant.
Note: to minimize user impact, some of the changes may be included only in
6.d language, which will be available in 2017.04 release only if the user uses
use v6.d.PREVIEW pragma.
IO Action Plan
Alien::Base was first released in alpha form five years ago this month!
The good things that Alien::Base (runtime) and Alien::Base::ModuleBuild (its installer ABMB) did
when it was unleashed on the world are many, but chiefly:
- It suggested a standard way of providing the compiler and linker
flags needed to use an already installed alien. The
was pretty flip in terms of standards or best practices.
- It made it dead simple to create an Alien distribution that
“alienized” a package that used
pkg-config, which probably covers a majority of open source libraries
that you would be likely to want to “alienize”.
(For those who are unfamiliar, autoconf provides a similar
functionality to ExtUtils::MakeMaker in the C world
and pkg-config is used to deal with dependencies in the C
- It made it possible with some work to create an Alien distribution
that wrapped around a package that used vanilla Makefile's,
CMake, and in some cases crazy custom installers.
So when I was working on:
A few weeks ago, SROMANOV sent me a patch for Git::Database adding initial support for accessing the Git object database references via Git::Raw. He had already contributed a partial implementation for a Git::Wrapper backend some time ago.
This motivated me to explore that module further, and implement the methods that were missing from Sergey's patch. So I asked JACQUESG to implement a few features that I needed. He was amazingly fast at responding, and I found myself asking for more and more features. And he just kept adding them!
So, thanks to a motivated contributor and a very reactive maintainer, Git::Database 0.08 can now access data from a Git repository using any of these seven Perl Git backends:
There are in fact more Git backends on CPAN... Anyone interested in adding support for Git::Class must have understood by now that patches are welcome.
Like all subjective decisions in technology, which log level to use is the cause of much angry debate. Worse, different logging systems use different levels: Log4j has 6 severity levels, and Syslog has 8 severity levels. While both lists of log levels come with guidance as to which level to use when, there's still enough ambiguity to cause confusion.
When choosing a log level, it's important to know how visible you want the message to be, how big of a problem it is, and what you want the user to do about it. With that in mind, this is the decision tree I follow when choosing a log level: