Skip to content

Instantly share code, notes, and snippets.

@Ovid
Last active September 5, 2023 07:59
Show Gist options
  • Save Ovid/05b69b8fa266e6d6b3600479871074b1 to your computer and use it in GitHub Desktop.
Save Ovid/05b69b8fa266e6d6b3600479871074b1 to your computer and use it in GitHub Desktop.
Native CPAN Authoring Tools

The Problem

CPAN uploads are declining. Part of this is the challenge of figuring out how to write a new module, navigate PAUSE, and release it. Many languages make it very easy to share new open source code with their community and that support is often in the core language.

Go Example

To publish a module in Go:

$ go mod tidy
$ go test ./...
$ git commit -m "mymodule: changes for v0.1.0"
$ git tag v0.1.0
$ git push origin v0.1.0
$ GOPROXY=proxy.golang.org go list -m example.com/[email protected]

And then others can easily install it:

$ go get example.com/[email protected]

See also:

Possible Solution

Perl needs a core solution for solving this problem. What I would like is a workflow similar to this:

$ module new My::Awesome::Module # might prompt for name and email
$ cd my-awesome-module
$ # hack, hack, hack
$ module build                   # builds all files needed for installation and CPAN sharing
$ module test                    # also does `build`
$ module release                 # also does `build` and `test`

Much of the above could be started with something like Module::Starter or Module::Build::Tiny. However, the module release step is not supported, though 'Dist::Zilla' and Minilla handle this.

Some of those solutions are opinionated and some are bewildering to new developers. Having to understand the CPAN and figure out which of multiple solutions are appropriate is painful. Having a core solution that works "out of the box" would be very valuable to Perl.

One CPAN author I have spoken to wants to build something like this, but he will be using bash, making it a potentially non-portable solution. I've already seen P5P reject bash-based solutions for some ideas.

Issues

Giving us PAUSE

PAUSE is a potential obstacle for the first-time module author. Navigating the PAUSE web site is a bit painful and the use of basic authentication and the 1995-style layout help reinforce the "Perl is dead" meme. Releasing a module for the first time should automatically request a new PAUSE account for the would-be author. There should be clear feedback to the author that this process might take X amount of time.

A naïve, first-pass solution, given that PAUSE does not (as far as I know) have an API, is to POST https://pause.perl.org/pause/query?ACTION=request_id with the name and email taken from the new module info, the description being "I would like to upload $module_name to the CPAN." and letting them choose a user-name, though we'd need to let them know before they submit if that name is taken.

Cyber Resiliency Act

Others would like to be able to easily release to, and install from, github or something similar. This would increase the tool's utility, but the upcoming EU Cyber Resiliancy Act might make module author's liable for not responding to security issues. This is discussed here and here. Thus, until we have clarity on what is needed here, going outside of CPAN should be approached cautiously.

I've started working on a CycloneDX SBOM Parser (json only) which might be part of a longer-term plan to address some of these issues, but I don't have much spare time.

Abandonware

Later versions of this software might even allow us to do this:

$ module download Abandoned::Software # downloads https://cpan.metacpan.org/...Abandoned.tgz and unpacks it
$ cd abandoned-software
$ module --request comaint

Adopting modules, requesting comaint, deprecating your own modules, and so on, could be "one-stop shopping," without ever visiting PAUSE.

MVP

At a minimum, the software should allow:

  • Creating a new module shell
  • Building all necessary metadata files
  • Releasing the module

For this to go into core, stripping out all non-core dependencies would likely be needed.

@Ovid
Copy link
Author

Ovid commented Sep 2, 2023

@sjn
Copy link

sjn commented Sep 5, 2023

It looks to me that you in practice are proposing that we collectively (or by force of implementation) decide on an easy-to-understand and fully-featured but maximally-optional deployment stanza.

I, for one, would love to see this. 😁

Though what (presumably, small/easy) steps can we take in order to move in this direction? Here are a couple of my thoughts on the matter.

  • Decide on a stanza pattern that clearly communicates all the steps we would like to support and that is trivial to both remember and figure out what means for anyone reading it. And as you say, these stanzas should include steps for both authoring, publishing, verification, the traditional deployment steps and possible other community-supporting "quality of life" activities.
  • Find some existing tooling that can be extended to support this, and help it move it this direction.
  • Start offering pull-requests

What's a good way to enable something like this to happen? 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment