jump to navigation

rakudo-pkg v2: Github Actions/CloudSmith, devbuilds, Alpine repos, nfpm 2021-02-11

Posted by claudio in Uncategorized.
Tags: , ,
add a comment

(In case you don’t know rakudo-pkg: it’s a project to provide native packages and relocatable builds of Rakudo for Linux distributions.)

The downward spiral of Travis since it was taken over by a Private Equity firm (there is a pattern here), triggered a long coming refactoring of the rakudo-pkg workflow.  Until now the packages were created on Travis because it supported running Linux containers so we could tailor the build for each distribution/release. Almost at the same time JFrog announced it was sunsetting Bintray and other services popular with FOSS projects. The deb and rpm repos needed a new home.

Oh well, Travis and Bintray will be missed and certainly deserve our thanks for their service during years. It was difficult to imagine a better time to implement a few ideas from the good old TODO list.

From Travis to Github Actions

Github Actions is way faster than the post-P.E. Travis. Builds that took a few hours (we build around 25 distro/version combinations) now are done between 10 and 20 minutes. Not surprisingly this not only meant learning a complete new tool, but also a complete rewrite of the rakudo-pkg workflow.

Running on Github also means that every Github user can fork the repo including the rakudo-pkg Github workflows. One of the advantages of a rewrite is implementing new functionalities, like the new feature of rakudo-pkg to allow everyone to test the upstream MoarVM/NQP/Rakudo and zef commits/releases:

devbuild workflow

From Bintray to CloudSmith with Alpine repositories

Cloudsmith has a huge advantage over Bintray: it supports Alpine Linux repositories, making it a great addition to the rpm and deb repositories we already offer. The packages in the old repositories were GPG signed by BinTray. From now onwards, rakudo-pkg will be signed with his own key on Cloudsmith. Check the project’s README for instructions how to change your configuration. So far the experience with CloudSmith has been stellar. Their support is impressively responsive and they solve issues immediately, sometime while we were chatting about it.

From fpm to nfpm

rakudo-pkg created packages with the venerable fpm, written in Ruby. While the tool is extremely capable, I spent most of the time of a release getting fpm to build on new versions of distributions. The Ruby Gems ecosystem looks like a moving target. Enter nfpm, inspired with fpm but with the promise of a single binary. Written it Go, it’s more accessible to me to understand how it works and send fixes upstream if needed. The devs are also very responsive and fixed one issue I encountered extremely fast.

 

Feel free to open issues of send PRs if I missed something or if you have ideas to improve rakudo-pkg

Quo vadis, Perl? 2018-11-08

Posted by claudio in Uncategorized.
Tags: , , , ,
comments closed

We’ve had a week of heated discussion within the Perl 6 community. It is the type of debate where everyone seems to lose. It is not the first time we do this and it certainly won’t be the last. It seems to me that we have one of those about every six months. I decided not to link to many reiterations of the debate in order not to feed the fire.

Before defining sides in the discussion it is important to identify the problems that drives the fears and hopes of the community. I don’t think that the latest round of discussions was about the Perl 6 alias in itself (Raku), but rather about the best strategy to answer to two underlying problems:

  • Perl 5 is steadily losing popularity.
  • Perl 6, despite the many enhancements and a steady growth, is not yet a popular language and does not seem to have a niche or killer app in sight yet to spur rapid adoption.

These are my observations and I don’t present them as facts set in stone. However, to me, they are the two elephants in the room. As an indication we could refer to the likes of TIOBE where Perl 5 fell off the top 10 in just 5 years (from 8th to 16th, see “Very Long Time History” at the bottom) or compare Github stars and Reddit subscribers of Perl 5 and 6 with languages on the same level of popularity on TIOBE.

Perl 5 is not really active on Github and the code mirror there has until today only 378 stars. Rakudo, developed on Github, has understandably more: 1022. On Reddit 11726 people subscribe to Perl threads (mostly Perl 5) and only 1367 to Perl 6. By comparison, Go has 48970 stars on Github and 57536 subscribers on Reddit. CPython, Python’s main implementation, has 20724 stars on Github and 290 308 Reddit subscribers. Or put differently: If you don’t work in a Perl shop, can you remember when a young colleague knew about Perl 5 besides by reputation? Have you met people in the wild that code in Perl 6?

Maybe this isn’t your experience or maybe you don’t care about popularity and adoption. If this is the case, you probably shrugged at the discussions, frowned at the personal attacks and just continued hacking. You plan to reopen IRC/Twitter/Facebook/Reddit when the dust settles. Or you may have lost your patience and moved on to a more popular language. If this is the case, this post is not for you.

I am under the impression that the participants of what I would call “cyclical discussions” *do* agree with the evaluation of the situation of Perl 5 and 6. What is discussed most of the time is clearly not a technical issue. The arguments reflect different –and in many cases opposing— strategies to alleviate the aforementioned problems. The strategies I can uncover are as follows:

Perl 5 and Perl 6 carry on as they have for longer than a decade and half

Out of inertia, this a status-quo view is what we’ve seen in practice today. While this vision honestly subscribes to the “sister languages narrative” (Perl is made up of two languages in order to explain the weird major version situation), it doesn’t address the perceived problems. It chooses to ignore them. The flip side is that with every real or perceived threat to the status-quo the debate resurges.

Perl 6 is the next major version of Perl

This is another status-quo view. The “sister languages narrative” is dead: Perl 6 is the next major version of Perl 5. While a lot of work is needed to make this happen, it’s work that is already happening: make Perl 6 fast. The target, however, is defined by Perl 5: It must be faster than the previous release. Perl consists of many layers and VMs are interchangeable: it’s culturally still Perl if you replace the Perl 5 runtime with one from of Perl 6. This view is not well received by many people in Perl 5 community, and certainly by those emotionally or professionally invested in “Perl”, with most of the time Perl meaning Perl 5.

Both Perl 5 and Perl 6 are qualified/renamed

This is a renaming view that looks for a compromise in both communities. The “sister languages narrative” is the real world experience and both languages can stand on their own feet while being one big community. By renaming both projects and keeping Perl in the name (e.g. Rakudo Perl, Pumpkin Perl) the investment in the Perl name is kept, while the next major version number dilemma is dissolved. However this strategy is not an answer for those in the Perl 6 community that experience that the (unjustified) reputation of Perl 5 is hurting Perl 6’s adoption. On the Perl 5’s side is some resentment why good old “Perl” needs to be renamed when Perl 6 is the newcomer.

Rename Perl 6

Perl 6’s adoption is hindered by Perl 5’s reputation and, at the same time, Perl 6’s major number “squatting” places Perl 5 in limbo. The “sister language narrative” is the real world situation: Perl 5 is not going away and it should not. The unjustified reputation of Perl 5 for some people is not something Perl 6 needs to fix. Only action of the Perl 6 community is required in the view. However, a “sisterly” rename will benefit Perl 5. Liberating the next major version will not fix Perl 5’s decline, but it may be a small piece of the puzzle of the recovery. Renaming will result in more loosely coupled communities, but Perl communities are not mutually exclusive and the relation may improve without the version dilemma. The “sister language narrative” becomes a proud origin story. Mostly Perl 6 people heavily invested in the Perl *and* the Perl 6 brand opposed this strategy.

Alias Perl 6

While being very similar to the strategy above, this view is less ambitious as it only cares about Perl 6’s adoption is hindered by Perl 5’s reputation. It’s up to Perl 5 to fix their major version problem. It’s a compromise between (a number of) people in the Perl 6 community. It may or may not be a way to proof if an alias catches on, the renaming of Perl 6 should stay on the table.

Every single strategy will result in people being angry or disappointed because they honestly believe it hurts the strategy that they feel is necessary to alleviate Perl’s problems. We need to acknowledge that the fears and hopes are genuine and often related. Without going in detail to not reignite the fire (again), the tone of many of the arguments I heard this week from people opposing the Raku alias rung very close to me to the arguments Perl 5 users have against the Perl 6 name. Being a victim of injustice by people that don’t care for an investment of years and a feeling of not being listen to.

By losing the sight of the strategies in play, I feel the discussion degenerated very early in personal accusations that certainly leave scars while not resulting in even a hint of progress. We are not unique in this situation, see the recent example of the toll it took on Guido van Rossum. I can only sympathize with Larry is feeling these days.

While the heated debates may continue for years to come, it’s important to keep an eye on people that silently leave. The way to irrelevance is a choice.

 

(I disabled comments on this entry, feel free to discuss it on Reddit or the like. However respect the tone of this message and refrain from personal attacks.)