ruby / ruby/prism

Split gem into Ruby and extension parts

Open
#3,959 15 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

java
Dominant language
C
Stars
1k
Forks
194
Avg merge
2d 6h
Merged PRs (30d)
15

Description

I would like to split the current Prism gem into two pieces: "prism" which contains the Ruby parts of the library, and "prism-ext" which contains the native extension and native library. This makes most sense for JRuby, but it would be simpler if done as a general move.

This is less of an issue and more of an idea that would make our lives easier in the JRuby world.

For JRuby users, the dependency on a native library is usually problematic. A large percentage of JRuby users (perhaps a majority) deploy JRuby into environments where there's no C build tools and frequently no allowances for random native libraries on the filesystem. Some of these deployments are all-in-one bundles that don't even unpack files to the filesystem. In such cases, the native library can't be built or loaded.

The most sensible option for the prism gem for JRuby would be that it ships only what can be run without native libraries; specifically this would mean prism would ship the WASM version of Prism so it can be embedded and bundled in all the ways JRuby users depend upon.

Users could opt-into the faster native Prism build by installing prism-ext or prism-library, which would build the dynamic library and make it available to the prism library. We would only ship prism as part of JRuby releases, since we need our distribution to always work across platforms.

The native-extension implementations would continue to just use the ext or the dynamic library as today.

The artifacts would look something like this:

  • prism gem includes only the Ruby parts of the library and can be patched and versioned independently of the native code.
  • prism-ext would work like the current prism gem does, building and installing either the CRuby extension or the dynamic library.
  • The normal non-platform-specific version of the prism gem would depend upon prism-ext.
  • The java platform version of the prism gem (for JRuby) would ship only the Ruby parts and the WASM library. Users can opt into the native version by installing prism-ext.

Alternatively, these changes would only apply to JRuby, and prism-ext would only be for JRuby users. Either way, the main prism gem for JRuby will need to exclude the native library.

I can think of other benefits to separating the extension into its own gem:

  • CRuby users would be able to update just the Ruby part of Prism while still using the built-in native extension. This might make some bug fixes easier to distribute.
  • If TruffleRuby in the future chooses to run Prism in a different form such as with Chicory or TruffleWasm, it would be a natural progression of this split.
  • Doing the split uniformly (rather than just for JRuby) will keep the differences minimal. CRuby users would just get an additional extension dependency.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by tracing the current prism gem packaging and native-extension build, then assess the proposed prism and prism-ext artifacts and JRuby's WASM path; done means the split and platform behavior are implemented, with the JRuby prism package excluding native libraries.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, ruby, wasm
Domain
build-system, developer-experience
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.