Dependencia de Ruby Gemspec: ¿Es posible tener una dependencia de rama de git?

82

¿Es posible tener una dependencia de rama de git, dentro de mygem.gemspec?

Estoy pensando en algo similar a lo siguiente:

gem.add_runtime_dependency 'oauth2', :git => 'git@github.com:lgs/oauth2.git'

... pero no funciona.

— Luca G. Soave
fuente

Tengo este mismo problema, excepto que quiero una dependencia de ruta, no una dependencia de git. ¿No hay una manera de evitar esto de alguna manera? ¿Quizás pegando algún código Ruby pirateado en el gemspec en alguna parte?

— Ajedi32

44

Esto no es posible, y probablemente nunca lo será porque sería bastante torpe para RubyGems permitir que los desarrolladores de gemas requieran que los usuarios tengan un sistema de control de versiones específico instalado para acceder a una gema. Las gemas deben ser independientes con un número mínimo de dependencias para que las personas puedan usarlas en una gama de aplicaciones lo más amplia posible.

Si desea hacer esto para sus propios proyectos internos, mi sugerencia sería utilizar Bundler, que lo admite bastante bien.

— gtd
fuente

22

... sí, pero ¿cómo puedo hacerlo?

— Luca G. Soave

33

Pero, ¿qué pasa si su gema se va a incluir más tarde en otra gema (por ejemplo, foobar_gem)? Cuando foobar_gem quiere resolver dependencias en su gema, ¿no se verá exclusivamente en el archivo gemspec?

— eremzeit

7

¿Alguna vez encontró una solución a esto? Tengo exactamente el mismo problema?

— msaspence

14

@eremzeit & msaspence: dado que tienes tantos votos a favor, me siento obligado a responder. No hay solución para esto porque lo estás haciendo mal . Está bien depender de un repositorio de git para una sola aplicación usando Bundler, es completamente incorrecto que una gema publicada dependa de GitHub o de cualquier otro repositorio de código fuente. Si está lanzando una gema, todas sus dependencias también deben liberarse como gemas. Hacer un paquete formal como una gema confiar en un código fuente inédito es poner el carro delante del caballo. No intente hacer esto .

— gtd

23

@gtd Crear una gema y lanzar una gema en rubygems son dos cosas separadas. Es posible que una joya privada inédita tenga dependencias privadas propias. Eso me parece bien. RubyGems no parece adaptarse a este caso de uso, pero no estoy convencido de que esto lo esté haciendo mal. Simplemente no hay mucho que lo respalde. ¿Me equivoco?

— Stephen Crosby

13

EDITAR

Según un comentarista, esto ya no es cierto. Información previa retenida para contexto histórico.

Duplicar la referencia a una gema en Gemfile y .gemspec ahora parece generar un mensaje de advertencia en Bundler, por lo que esta respuesta parecería que ya no es cierta.

Información desactualizada

Este artículo de Yehuda Katz me aclaró una confusión similar. Dice que, solo para uso en desarrollo, es mejor agregar las cosas de git en el archivo de gemas, pero ese paquete seguirá usando la información de dependencia / versión de gemspec (me parece mágico, pero confío en Yehuda).

— heartpunk
fuente

3

¿Qué tiene de mágico eso? Bundler lee solo del Gemfile, excepto que si lo gemspecingresa, también lee del gemspec. Entonces, cuando ejecuta bundle install, supongo (pero no lo he probado) que lo que sucede es que Bundler instala la gema especificada en el Gemfile. Dado que Bundler ya lo ha instalado, esa gema está disponible para la gema require, independientemente del hecho de que no provenga de un repositorio de gemas. Sin magia, solo Bundler funcionando como de costumbre.

— Marnen Laibow-Koser

2

Duplicar la referencia a una gema en Gemfile y .gemspec ahora parece generar un mensaje de advertencia en Bundler, por lo que esta respuesta parece que ya no es cierta ...

— Andy Jones

7

Yo también estaba tratando de resolver este problema. Y se me ocurrió la siguiente solución (que no estoy seguro de si estás publicando tu gema o tienes derechos para redistribuir esa gema oauth2).

En su gema que requiere gema oauth2 ejecute esto.

git submodule add git@github.com:lgs/oauth2.git lib/oauth2

Si necesita una rama diferente a la predeterminada

cd lib/oauth2 && git checkout <branchname_or_ref>
cd .. && git add lib/oauth2
git commit -m "adding outh2 submodule"

En su gemspec agregue esto arriba de su línea de versión requerida

$:.push File.expand_path('../lib/oauth2/lib', __FILE__)

También deberá agregar todas las dependencias de tiempo de ejecución de la gema oauth2 a su gemspec. Todavía no he descubierto una forma de evitar esto.

Esto es lo que hice, y nos funciona porque nuestra gema se requiere a través de git, por lo que no estoy seguro de si esto funcionaría para una gema publicada en rubygems.

— kwbock
fuente

Agregar la dependencia como un submódulo es la solución correcta si ha creado ambas gemas y ambas están en desarrollo activo.

— Benjineer

Es importante destacar que si hace esto, es posible que deba usar: gem 'my_gem', git: 'git@github.com:me/myrepo', submodules: trueen su aplicación de host si está instalando desde github.

— Joe Edgar

1

Encontré una solución bastante sencilla:

Digamos que estás en un proyecto Py quieres usar la gema hecha por ti toolsmismo que usa una gema del sistema operativo oauth2.

Si hizo un parche dentro oauth2y necesita ese parche en su gema tools, no podrá solucionar este problema en la gema de acuerdo con la respuesta aceptada .

Sin embargo, puede especificar la versión que desee dentro Pdel Gemfile de su proyecto , y esta será la versión utilizada por toolsen tiempo de ejecución:

gem 'oauth2', github: 'lgs/oauth2'

Aquí hay un ejemplo mío de la vida real.

— Ulysse BN
fuente