Request for Comment: Casual Package Consolidation

[kickingvegas]

Request for Comment: Casual Package Consolidation

As of 2024-09-27, the Casual project is organized into multiple packages, where each package is specialized to a particular Emacs mode. There is an umbrella package called casual-suite which uses the Package-Requires: feature to include all the different Casual packages as dependencies. All the aforementioned packages are distributed on MELPA.

There is a desire to distribute the Casual project on ELPA (GNU or nonGNU TBD). Initial feedback on doing so from the Emacs Devel mailing list has expressed that the current organization of Casual into a multitude of packages is not desirable as it makes their review logistically difficult.

Proposal

To support distribution on ELPA, it is proposed to consolidate all Casual packages into a single package. A migration plan would obsolete the current Casual packages and direct users to the new single package.

Questions & Unknowns

• Does this consolidation make it easier for users? What do users get out of this?

  • New users to Casual
  • Existing Casual users

• Using casual as the single package name.

  • This IMHO is the most ideal thing to do. However this also breaks the :old-names rule used by casual-calc as it was originally named casual. It is unknown what the impact of breaking this will be.

• I do not know how to obsolete a package on MELPA. Is this even feasible?

• How much merit is there to having package granularity that is specialized to a particular Emacs mode?

• I do not know how much configuration change will be required by existing Casual users to migrate to a single package.

  • Best effort will be made to minimize effort by users to migrate. Ideally, no configuration change (outside of package distribution) will be required.

Request for Comment

No final decision has been made on whether or not to consolidate. This is a request for comment by existing Casual users. The feedback gathered here will inform my final decision on whether to move forward with this proposal.

[minad]

I propose to consolidate all packages without third-party dependencies into a single package (casual ). Packages which have dependencies external to Emacs itself should be packaged up separately, e.g., casual-avy. You can then use casual-suite (or casual-all) which depends on all casual and casual-* packages, but this should also be distributed separately. This is a common practice and will likely be accepted by ELPA. My consult package follows a similar pattern, where packages with dependencies are distributed separately, e.g., consult-flycheck. Furthermore I propose to simplify the overall setup slightly: Integrate casual-lib into the main casual package. Remove the *-version.el files since they don't offer any additional value over the info UIs of the various package managers.

[kickingvegas]

@minad Genuinely appreciate the input. Right now I'm drafting a migration plan which I intend to post here that incorporates a lot of what you have suggested. Would welcome your thoughts on this.

Thanks much!

[kickingvegas]

Proposal for Casual Package Consolidation

Consolidate current set (as of 2024-10-01) of Casual packages into the packages as described:

• casual which will contain user interfaces that pertain to packages or modes that are built-in to Emacs.
• casual-* which will contain user interfaces that pertain to packages not built-in to Emacs but are published on either GNU or NonGNU ELPA.
  • At current casual-avy and casual-symbol-overlay fall in this category.
• casual-suite which will be refactored into an umbrella package that includes casual and the casual-* packages as dependencies.

The current set of Casual packages superseded by casual shall be obsoleted and removed on MELPA upon publication of the new casual package on MELPA.

Note that this document is WIP and subject to change.

Rationale

Motivating this migration is the desire to publish the Casual packages on ELPA (GNU or NonGNU TBD) to obtain wider distribution to the Emacs user-base. Early feedback from ELPA reviewers expressed the desire to consolidate the multitude of Casual packages to minimize their review efforts.

Consideration was given to the pros and cons of migration.

Pros:

• Wider distribution of the Casual user interfaces to the Emacs user-base.
• Lower maintenance cost due to consolidated code base in a smaller number of repositories.
• Less user effort in installing a multitude of packages.

Cons:

• Disruption to current means of distribution.
  • Existing users must change their configuration (at the very least how packages are installed) with no significant improvement in functionality.
• More difficult to discover Casual features.
  • Easier to highlight mode-specific features with an individual package, particularly to new users of Casual.
  • Existing marketing links to Casual packages that will be superseded will need to be updated.
• Migration engineering effort
  • Work must be done by Casual maintainer to design, implement, and deploy migration effort. This effort has a high opportunity cost to the maintainer.

Requirements

1. A new package named casual shall be created.
   1. This package shall contain user interfaces that pertain to packages or modes that are built-in to Emacs.
2. Existing packages that depend on packages not built-in to Emacs but are published on either GNU or NonGNU ELPA shall be refactored to support the new casual package.
   1. The packages casual-avy and casual-symbol-overlay shall be refactored.
3. Users who migrate to casual or the updated casual-suite shall have little to no configuration changes.
   1. No name changes to publicly facing menus or functions shall be made to support this migration.
4. The new casual package shall provide a means of removing the packages it supersedes.
5. Superseded packages that are still installed shall issue a warning message to upgrade to the new casual package.
6. The resultant packages after migration are to be published on ELPA (GNU or NonGNU TBD) and MELPA (including Stable).

Specification

Current inventory of the packages to be migrated is shown in the table below.

• The Original column contains the name of existing package published on MELPA.
• The Migration column contains the name of the new or existing package to be published on ELPA (GNU or NonGNU TBD) and MELPA (including Stable).
• The Dependencies column lists the current package dependencies of the original packages.

Original	Migration	Dependencies	Notes
casual-lib	casual		Package will be superseded by casual.
casual-agenda	casual		Package will be superseded by casual.
casual-bookmarks	casual		Package will be superseded by casual.
casual-calc	casual		Package will be superseded by casual.
casual-dired	casual		Package will be superseded by casual.
casual-ibuffer	casual		Package will be superseded by casual.
casual-info	casual		Package will be superseded by casual.
casual-isearch	casual		Package will be superseded by casual.
casual-re-builder	casual		Package will be superseded by casual.
casual-editkit	casual	casual-symbol-overlay, transpose-frame	Package will be superseded by casual. Will remove all dependencies on non-built-in packages before migration.
casual-avy	casual-avy	avy	Package will be refactored.
casual-symbol-overlay	casual-symbol-overlay	symbol-overlay	Package will be refactored.
casual-suite	casual-suite	casual, casual-avy, casual-symbol-overlay	Package will be refactored.

The diagram above visualizes the resulting organization of functional behavior after the migration. Each tabbed box represents a package, the boxes contained within them are libraries. Arrows illustrates dependencies.

Migration Plan

The migration plan is detailed in the following actions below.

MELPA: Change legacy casual to casual-calc to redirects

The package casual-calc was originally named casual on MELPA. After the rename to casual-calc, references to casual were redirected using the :old-names keyword in its MELPA recipe.

This action will remove the :old-names keyword, freeing up the name casual for a new package with a new repository with the same name (kickingvegas/casual) to be located on GitHub.

Note that this action shall break redirects as follows:

• On MELPA, casual will no longer redirect to casual-calc.
• On GitHub, kickingvegas/casual will no longer redirect to kickingvegas/casual-calc.

Remove casual-editkit dependencies

Given that most of the functionality provided by casual-editkit uses built-in Emacs behavior, a decision has been made to remove any dependency on the symbol-overlay and transpose-frame package. Current work on Emacs 30 promises that transpose-frame behavior will be included as a built-in as that package is currently not maintained. This opens a possible future release that restores transpose-frame support to casual-editkit.

Create casual package

Migrate code-base for the existing packages listed in table above to casual package. Build migrate-casual-2024 command that will uninstall existing superseded packages. Guidance will be to run migrate-casual-2024 upon installation.

1. Migrate casual-lib
2. Migrate casual-agenda
3. Migrate casual-bookmarks
4. Migrate casual-calc
5. Migrate casual-dired
6. Migrate casual-ibuffer
7. Migrate casual-info
8. Migrate casual-isearch
9. Migrate casual-re-builder
10. Migrate casual-editkit

Add migration warning to superseded packages

Packages to be superseded shall be updated to message a warning to migrate to the new casual package. This is to be done for the interim before removing their MELPA distribution.

(Might be able to get away with just updating casual-lib.)

MELPA: Remove superseded package recipes

Casual packages that have been superseded will be removed from MELPA distribution.

Refactor non-built-in Casual packages

1. casual-avy
2. casual-symbol-overlay
3. casual-suite

Submit casual packages for ELPA review

1. casual
2. casual-avy
3. casual-symbol-overlay
4. casual-suite

Submit casual for MELPA review

As casual is a new package, this will require that its MELPA recipe be reviewed. Upon its approval and distribution will existing Casual users be allowed to migrate their local installation of Casual.

Migration Plan Dependencies

The diagram shown below illustrates the dependencies of the action items described above. The first action item is shown at the bottom of the diagram, the final action items are shown at the top.

[kickingvegas]

@minad here's a plan, would welcome your thoughts on it.

[kickingvegas]

Preliminary sizing and schedule. Tasks and dates are subject to change.

[sachac]

Just popping in to say: nice Gantt chart and other diagrams, very cool. =) I appreciate your thoughtfulness and the evolution of this suite of packages!

[kickingvegas]

DECISION MADE: Moving forward with proposal to consolidate Casual packages as described in #50 (comment).

[kickingvegas]

Work on Casual package consolidation to be tracked in #57