Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Split gem into Ruby and extension parts

Abierto
  • ¿Algo no está bien?
#3,959 15 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
c, ruby, wasm
Área
build-system, developer-experience

Línea de trabajo

No se nombran archivos ni pruebas. Empieza por rastrear el empaquetado actual de prism gem y la compilación de la extensión nativa; después, evalúa los artefactos propuestos de prism y prism-ext y la ruta WASM de JRuby; se considera terminado cuando la división y el comportamiento por plataforma estén implementados, y el paquete prism de JRuby excluya las bibliotecas nativas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

java

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.
Lenguaje dominante
C
Estrellas
1k
Forks
194
Merge medio
2 d 9 h
PR fusionados (30 d)
15

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ruby/prism

Todos los issues de ruby/prism

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.