If you have a Perl-related news item you'd like to share, you may post it in the Perl Newssection.
Please try to avoid duplicating news; but pointers (with summaries) to important stories on other sites are acceptable here.
I am in favor of this change, because it reflects an ancient wisdom:
“No one sews a patch of unshrunk cloth on an old garment, for the patch will pull away from the garment, making the tear worse. Neither do people pour new wine into old wineskins. If they do, the skins will burst; the wine will run out and the wineskins will be ruined. No, they pour new wine into new wineskins, and both are preserved.”
"CPAN is wonderful and it is vast. Task::Kensho offers a curated look at the best it has to offer for those who don't know what to look for. But to remain useful, it must keep up with the trends of CPAN and the community. Thus, the community's input is vital to its maintenance.
"Please, take a moment and look through the open issues. Comment or add a reaction in support of changes that make sense to you, and open a new issue if you think something is missing."
See my blog post for more information, and an example of the new berrybrew virtual command.
Here's a summary of the new features:
berrybrew virtual allows you to manage non-Strawberry external Perls
Unattended installations now possible
new quick argument to berrybrew switch allows switching to new Perl instances without opening a new CLI window
berrybrew module export and berrybrew modules import allows you to export and import modules between Perls. Custom module list files allowed
Ability to change between Strawberry's home directory and Windows home directory when using File::HomeDir
Management of external Perl installations; Using the new berrybrew virtual command, one can bring in other installations of Perl for management under berrybrew. For example, if you have an ActiveState Perl installed on the system, you can virtualize it under berrybrew, and use or switch to it just like any of the portable Strawberry Perls we normally manage. This means that you can switch over to your system Perl when needed, without having to modify PATH, or temporarily disabling berrybrew
Unattended installations are now possible. We no longer prompt for user acceptance when running the initial configuration
New quick argument to berrybrew switch; This allows you to switch to a different Perl instance persistently without having to close the existing CLI window and opening a new one (note: some binaries and features may not work correctly. If you run into problems, simply open a new window)
Export and import modules from one Perl instance to another; berrybrew modules export and berrybrew modules import will dump a list of all installed CPAN distribution names from one Perl and install it on others. The export files can be edited at will before re-importing, and you can even create your own module list files to use as you see fit. Using this feature, in conjunction with berrybrew clone allows you to easily set up template Perl instances for very quick Perl platform setup
Ability to change the location where File::HomeDir points to; you can switch between the Windows home directory location, or the default location that Strawberry Portable editions set
Side note... a request came in by a user to support previously installed Perls. Their developers use berrybrew, but all of their CI happens automatically on a locally installed Active State Perl. They wanted a way to be able to use Active State for their testing pipeline, without having to muck with path environment variables and such that would mess up the developer environment. With berrybrew use virtual_instance, the system Perl can be used for the CI runs without affecting the rest of the system.
I haven't seen an announcement yet, but discovered it yesterday: The videos from this year's European Perl Conference in Rīga are available on YouTube in the
PerlCon Riga channel. Credits go to Andrew Shitov and his team for organizing, and to the Enlightened Perl Organization with their helpers for providing and running the equipment. Thank you!
The complete streams (one day, one room) had already been announced in a News Article at the conference website.
Update: others have quoted what they feel to be the most salient point of ovid's article, so here's mine:
So yeah, there's bitterness and the Perl community not only needs to heal, but we need to find a way forward for both languages. The suggestion to change the name of Perl 6 to "raku" is effectively designed to make this happen. Perl 5 can figure out how to get beyond the branding issue that's been plaguing it and Perl 6 can do the same thing.
The way forward always starts with a minimal test.
wiringPi, a library for GPIO access on the Raspberry Pi is now deprecated, for the all too familiar reasons of abuse and unreasonable expectations of others. I think all of the perl and python libraries I've seen for Pi GPIO are dependent on this.
In a blog post by Dave Cross on the Perl conference in Riga there is this...
The second day started with Liz Mattijsen’s keynote DeMythifying Perl 6. I was surprised when she stated that “Perl 6 has damaged Perl 5” was not a myth, but a fact and was totally blown away when she followed that up with a proposal to rename Perl 6.
Plugin now understands Perl much better and can infer values
of different operations and invocations. Therefore - resolve and completion should be much better in many places. (Seriously,
sometimes it's looks just like a magic.)
Names suggester now taking inferred values into account when
suggesting variable names.
Introduce variable action is now available for the Perl code
Pod support has been deeply re-worked and should be much
Quick-doc on built-ins
Quick-doc on completion elements
Better completion, live-templates, smart keys, resolve and
refactoring for POD
Re-worked POD color settings
Basic project model
Actions to create an application, plugin or lite