Hi, How do others use gems with c extensions across ruby versions? I don't see a way to do this with rip. For example if I `rip install hpricot` in 1.8.7 and then switch to 1.9.2 (with rvm), hpricot and its c extensions can't be used. I read the rip-build manpage and saw that flags could be passed to extconf.rb but wasn't sure what flags to pass. Anyone have a rip command that can clone a ripenv but build its package extensions in a different ruby version i.e. `rip clone hpricot_env path_to_1.9.2`? Thanks, Gabriel
Hey Gabriel, This is a known problem at the moment. And we're not sure how we want it to work. We might be able to detect the current ruby vm and automatically pass that info to rip-build. But we probably want a way to specify any ruby vm to build against. I'd like to investigate a subpath for compiled extensions within your env: .rip/system/lib/ree-1.8.7/mysql.bundle .rip/system/lib/ruby-1.9.2/mysql.bundle so one env could contain multiple compiled packages so you wouldn't have to switch between multiple envs. On Wed, Jun 16, 2010 at 5:14 PM, Gabriel Horner <gabriel.horner@gmail.com> wrote: > Hi, > How do others use gems with c extensions across ruby versions? I > don't see a way to do this with rip. For example if I `rip install > hpricot` in 1.8.7 and then switch to 1.9.2 (with rvm), hpricot and its > c extensions can't be used. I read the rip-build manpage and saw that > flags could be passed to extconf.rb but wasn't sure what flags to > pass. Anyone have a rip command that can clone a ripenv but build its > package extensions in a different ruby version i.e. `rip clone > hpricot_env path_to_1.9.2`? > > Thanks, > Gabriel > -- Joshua Peek
Hey josh and defunkt, Thought you'd like to know I got a working version of a rip command which manages packages with c extensions across ruby versions: http://github.com/cldwalker/rip/tree/ext . More about how the command works: http://github.com/defunkt/rip/issues/issue/122 I ended up not embedding ruby-version-specific bundles in a ripenv directory or in a package. Instead, I took the same approach as rip-build and placed each ruby-version-specific package in its own package. Ended up having to barely touch any existing rip commands as a result. I also found no need to pass ruby vm info to rip-build. Hopefully we get this or something like it in rip soon. It's really the only feature holding me back from using rip to manage all my gems across ruby versions. Gabriel On Wed, Jun 16, 2010 at 6:20 PM, Joshua Peek <josh@joshpeek.com> wrote: > Hey Gabriel, > > This is a known problem at the moment. And we're not sure how we want > it to work. > > We might be able to detect the current ruby vm and automatically pass > that info to rip-build. But we probably want a way to specify any ruby > vm to build against. > > I'd like to investigate a subpath for compiled extensions within your env: > > .rip/system/lib/ree-1.8.7/mysql.bundle > .rip/system/lib/ruby-1.9.2/mysql.bundle > > so one env could contain multiple compiled packages so you wouldn't > have to switch between multiple envs. > > On Wed, Jun 16, 2010 at 5:14 PM, Gabriel Horner > <gabriel.horner@gmail.com> wrote: >> Hi, >> How do others use gems with c extensions across ruby versions? I >> don't see a way to do this with rip. For example if I `rip install >> hpricot` in 1.8.7 and then switch to 1.9.2 (with rvm), hpricot and its >> c extensions can't be used. I read the rip-build manpage and saw that >> flags could be passed to extconf.rb but wasn't sure what flags to >> pass. Anyone have a rip command that can clone a ripenv but build its >> package extensions in a different ruby version i.e. `rip clone >> hpricot_env path_to_1.9.2`? >> >> Thanks, >> Gabriel >> > > > > -- > Joshua Peek >
On Tue, Jul 13, 2010 at 6:34 PM, Gabriel Horner <gabriel.horner@gmail.com> wrote: > Hey josh and defunkt, > Thought you'd like to know I got a working version of a rip command > which manages packages with c extensions across ruby versions: > http://github.com/cldwalker/rip/tree/ext . More about how the command > works: http://github.com/defunkt/rip/issues/issue/122 > > I ended up not embedding ruby-version-specific bundles in a ripenv > directory or in a package. Instead, I took the same approach as > rip-build and placed each ruby-version-specific package in its own > package. Ended up having to barely touch any existing rip commands as > a result. I also found no need to pass ruby vm info to rip-build. > > Hopefully we get this or something like it in rip soon. It's really > the only feature holding me back from using rip to manage all my gems > across ruby versions. Great, I'm glad someone took a stab at this. I think we should avoid the explicit link to the "parent" package. It adds some complexity to rip-gc has you mentioned and is a slippery slope to package corrupt issues. Seems like this type of command fits under the "rip-env" operation tree. Maybe "rip-env-rebuild" aliased to "rip env -r". I'd just record the current env, wipe it, and reinstall it with the current ruby. How useful do you find the interactive prompt option? -- Joshua Peek
> I think we should avoid the explicit link to the "parent" package. It > adds some complexity to rip-gc has you mentioned and is a slippery > slope to package corrupt issues. I'm not sure if there is a way to avoid a parent package. Rebuilding a package works the same as rip-build, by copying the original clean source (parent package) into a new directory and then building extensions. If we don't know where the original clean source is, what should we be rebuilding from? We could use the package directory containing extensions for a particular ruby version. But what happens if rebuilding for another ruby version doesn't overwrite extensions for the previous ruby version? We risk having packages with extensions for the wrong ruby version. > Seems like this type of command fits under the "rip-env" operation > tree. Maybe "rip-env-rebuild" aliased to "rip env -r". I'd just record > the current env, wipe it, and reinstall it with the current ruby. rip-ext rebuilds packages across all envs so it may not be a good fit for rip-env. I'm not sure how reloading an env is similar to rip-ext. rip-ext only rebuilds packages with extensions, not all packages. It allows packages with multiple ruby versions to coexist. Once a package is built for a particular version, it persists and needs no rebuilding when switching again to that particular version. Seems with reloading envs, we would be rebuilding packages with each version switch. > How useful do you find the interactive prompt option? Having 10+ gems that have extensions, it can be handy to put off rebuilding till later when switching to a new ruby version. I figure hitting enter is a small price for having the option to not automatically rebuild. Gabriel
On Wed, Jul 14, 2010 at 3:11 AM, Gabriel Horner <gabriel.horner@gmail.com> wrote: >> I think we should avoid the explicit link to the "parent" package. It >> adds some complexity to rip-gc has you mentioned and is a slippery >> slope to package corrupt issues. > I'm not sure if there is a way to avoid a parent package. Rebuilding a > package works the same as rip-build, by copying the original clean > source (parent package) into a new directory and then building > extensions. If we don't know where the original clean source is, what > should we be rebuilding from? We could use the package directory > containing extensions for a particular ruby version. But what happens > if rebuilding for another ruby version doesn't overwrite extensions > for the previous ruby version? We risk having packages with extensions > for the wrong ruby version. There are ways of getting around this i.e. FileUtils.rm_f(Dir[''**/*.bundle"]) so maybe it's a non-issue. I forgot to mention that I mainly needed to create a .rip_parent to save the parent/source md5 and thus determine a built package's ruby version (platform_hash). You can see how I use a package's source md5 and current Rip.platform_hash to determine if a package belongs to the current ruby version here: http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L21 and http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L60. Is there another way to extract a built package's ruby version? If not, I would propose saving a package's ruby version on each build i.e. `ruby -rrip -e 'puts Rip.platform_hash >> .rip_platform_hash' . I would've proposed adding this info to metadata.rip but that would mess with the .rip format. Since there doesn't seem to be interest in integrating rip-ext, it would help to at least have a package's ruby version so rip-ext can exist as a plugin. Gabriel
On Tue, Jul 20, 2010 at 9:54 AM, Gabriel Horner <gabriel.horner@gmail.com> wrote: > On Wed, Jul 14, 2010 at 3:11 AM, Gabriel Horner > <gabriel.horner@gmail.com> wrote: >>> I think we should avoid the explicit link to the "parent" package. It >>> adds some complexity to rip-gc has you mentioned and is a slippery >>> slope to package corrupt issues. > >> I'm not sure if there is a way to avoid a parent package. Rebuilding a >> package works the same as rip-build, by copying the original clean >> source (parent package) into a new directory and then building >> extensions. If we don't know where the original clean source is, what >> should we be rebuilding from? We could use the package directory >> containing extensions for a particular ruby version. But what happens >> if rebuilding for another ruby version doesn't overwrite extensions >> for the previous ruby version? We risk having packages with extensions >> for the wrong ruby version. > > There are ways of getting around this i.e. > FileUtils.rm_f(Dir[''**/*.bundle"]) so maybe it's a non-issue. > > I forgot to mention that I mainly needed to create a .rip_parent to > save the parent/source md5 and thus determine a built package's ruby > version (platform_hash). You can see how I use a package's source md5 > and current Rip.platform_hash to determine if a package belongs to the > current ruby version here: > http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L21 and > http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L60. Is there > another way to extract a built package's ruby version? If not, I would > propose saving a package's ruby version on each build i.e. `ruby -rrip > -e 'puts Rip.platform_hash >> .rip_platform_hash' . I would've > proposed adding this info to metadata.rip but that would mess with the > .rip format. > > Since there doesn't seem to be interest in integrating rip-ext, it > would help to at least have a package's ruby version so rip-ext can > exist as a plugin. Lets write out platform to compiled packages somewhere. We should store the full path to the ruby binary that built the package so we can reread that and get fetch the arch string to print in rip list. $ rip-list hpricot 0.8.2 (i686-darwin10.3.0) (something like that) I think I got "platform" wrong, more to do with Windows vs Mac. Need a better word that includes other versions of rubies too. -- Joshua Peek
On Tue, Jul 20, 2010 at 11:42 AM, Joshua Peek <josh@joshpeek.com> wrote: > On Tue, Jul 20, 2010 at 9:54 AM, Gabriel Horner > <gabriel.horner@gmail.com> wrote: >> On Wed, Jul 14, 2010 at 3:11 AM, Gabriel Horner >> <gabriel.horner@gmail.com> wrote: >>>> I think we should avoid the explicit link to the "parent" package. It >>>> adds some complexity to rip-gc has you mentioned and is a slippery >>>> slope to package corrupt issues. >> >>> I'm not sure if there is a way to avoid a parent package. Rebuilding a >>> package works the same as rip-build, by copying the original clean >>> source (parent package) into a new directory and then building >>> extensions. If we don't know where the original clean source is, what >>> should we be rebuilding from? We could use the package directory >>> containing extensions for a particular ruby version. But what happens >>> if rebuilding for another ruby version doesn't overwrite extensions >>> for the previous ruby version? We risk having packages with extensions >>> for the wrong ruby version. >> >> There are ways of getting around this i.e. >> FileUtils.rm_f(Dir[''**/*.bundle"]) so maybe it's a non-issue. >> >> I forgot to mention that I mainly needed to create a .rip_parent to >> save the parent/source md5 and thus determine a built package's ruby >> version (platform_hash). You can see how I use a package's source md5 >> and current Rip.platform_hash to determine if a package belongs to the >> current ruby version here: >> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L21 and >> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L60. Is there >> another way to extract a built package's ruby version? If not, I would >> propose saving a package's ruby version on each build i.e. `ruby -rrip >> -e 'puts Rip.platform_hash >> .rip_platform_hash' . I would've >> proposed adding this info to metadata.rip but that would mess with the >> .rip format. >> >> Since there doesn't seem to be interest in integrating rip-ext, it >> would help to at least have a package's ruby version so rip-ext can >> exist as a plugin. > > Lets write out platform to compiled packages somewhere. We should > store the full path to the ruby binary that built the package so we > can reread that and get fetch the arch string to print in rip list. Okay. Sounds like we're talking about saving the same output i.e. Rip.shell_ruby_platform. The question is how to save it. I suggested saving it in a .rip_platform_hash file in a package's directory. We could also save it globally i.e. ~/.rip/.versions.yml and have the yaml file be a hash mapping package file basenames to these ruby platform values. Thoughts? Gabriel
On Tue, Jul 20, 2010 at 3:48 PM, Gabriel Horner <gabriel.horner@gmail.com> wrote: > On Tue, Jul 20, 2010 at 11:42 AM, Joshua Peek <josh@joshpeek.com> wrote: >> On Tue, Jul 20, 2010 at 9:54 AM, Gabriel Horner >> <gabriel.horner@gmail.com> wrote: >>> On Wed, Jul 14, 2010 at 3:11 AM, Gabriel Horner >>> <gabriel.horner@gmail.com> wrote: >>>>> I think we should avoid the explicit link to the "parent" package. It >>>>> adds some complexity to rip-gc has you mentioned and is a slippery >>>>> slope to package corrupt issues. >>> >>>> I'm not sure if there is a way to avoid a parent package. Rebuilding a >>>> package works the same as rip-build, by copying the original clean >>>> source (parent package) into a new directory and then building >>>> extensions. If we don't know where the original clean source is, what >>>> should we be rebuilding from? We could use the package directory >>>> containing extensions for a particular ruby version. But what happens >>>> if rebuilding for another ruby version doesn't overwrite extensions >>>> for the previous ruby version? We risk having packages with extensions >>>> for the wrong ruby version. >>> >>> There are ways of getting around this i.e. >>> FileUtils.rm_f(Dir[''**/*.bundle"]) so maybe it's a non-issue. >>> >>> I forgot to mention that I mainly needed to create a .rip_parent to >>> save the parent/source md5 and thus determine a built package's ruby >>> version (platform_hash). You can see how I use a package's source md5 >>> and current Rip.platform_hash to determine if a package belongs to the >>> current ruby version here: >>> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L21 and >>> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L60. Is there >>> another way to extract a built package's ruby version? If not, I would >>> propose saving a package's ruby version on each build i.e. `ruby -rrip >>> -e 'puts Rip.platform_hash >> .rip_platform_hash' . I would've >>> proposed adding this info to metadata.rip but that would mess with the >>> .rip format. >>> >>> Since there doesn't seem to be interest in integrating rip-ext, it >>> would help to at least have a package's ruby version so rip-ext can >>> exist as a plugin. >> >> Lets write out platform to compiled packages somewhere. We should >> store the full path to the ruby binary that built the package so we >> can reread that and get fetch the arch string to print in rip list. > > Okay. Sounds like we're talking about saving the same output i.e. > Rip.shell_ruby_platform. The question is how to save it. I suggested > saving it in a .rip_platform_hash file in a package's directory. We > could also save it globally i.e. ~/.rip/.versions.yml and have the > yaml file be a hash mapping package file basenames to these ruby > platform values. Thoughts? Right, It would be in the package dir, but I'm not sure what to call it. I want to rename the existing stuff away from "platform". -- Joshua Peek
On Tue, Jul 20, 2010 at 5:50 PM, Joshua Peek <josh@joshpeek.com> wrote: > On Tue, Jul 20, 2010 at 3:48 PM, Gabriel Horner > <gabriel.horner@gmail.com> wrote: >> On Tue, Jul 20, 2010 at 11:42 AM, Joshua Peek <josh@joshpeek.com> wrote: >>> On Tue, Jul 20, 2010 at 9:54 AM, Gabriel Horner >>> <gabriel.horner@gmail.com> wrote: >>>> On Wed, Jul 14, 2010 at 3:11 AM, Gabriel Horner >>>> <gabriel.horner@gmail.com> wrote: >>>>>> I think we should avoid the explicit link to the "parent" package. It >>>>>> adds some complexity to rip-gc has you mentioned and is a slippery >>>>>> slope to package corrupt issues. >>>> >>>>> I'm not sure if there is a way to avoid a parent package. Rebuilding a >>>>> package works the same as rip-build, by copying the original clean >>>>> source (parent package) into a new directory and then building >>>>> extensions. If we don't know where the original clean source is, what >>>>> should we be rebuilding from? We could use the package directory >>>>> containing extensions for a particular ruby version. But what happens >>>>> if rebuilding for another ruby version doesn't overwrite extensions >>>>> for the previous ruby version? We risk having packages with extensions >>>>> for the wrong ruby version. >>>> >>>> There are ways of getting around this i.e. >>>> FileUtils.rm_f(Dir[''**/*.bundle"]) so maybe it's a non-issue. >>>> >>>> I forgot to mention that I mainly needed to create a .rip_parent to >>>> save the parent/source md5 and thus determine a built package's ruby >>>> version (platform_hash). You can see how I use a package's source md5 >>>> and current Rip.platform_hash to determine if a package belongs to the >>>> current ruby version here: >>>> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L21 and >>>> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L60. Is there >>>> another way to extract a built package's ruby version? If not, I would >>>> propose saving a package's ruby version on each build i.e. `ruby -rrip >>>> -e 'puts Rip.platform_hash >> .rip_platform_hash' . I would've >>>> proposed adding this info to metadata.rip but that would mess with the >>>> .rip format. >>>> >>>> Since there doesn't seem to be interest in integrating rip-ext, it >>>> would help to at least have a package's ruby version so rip-ext can >>>> exist as a plugin. >>> >>> Lets write out platform to compiled packages somewhere. We should >>> store the full path to the ruby binary that built the package so we >>> can reread that and get fetch the arch string to print in rip list. >> >> Okay. Sounds like we're talking about saving the same output i.e. >> Rip.shell_ruby_platform. The question is how to save it. I suggested >> saving it in a .rip_platform_hash file in a package's directory. We >> could also save it globally i.e. ~/.rip/.versions.yml and have the >> yaml file be a hash mapping package file basenames to these ruby >> platform values. Thoughts? > > Right, It would be in the package dir, but I'm not sure what to call > it. I want to rename the existing stuff away from "platform". Since we're saving RbConfig::CONFIG['sitearchdir'], why not just .rip_archdir? Or perhaps .rip_ruby_version? Gabriel
On Wed, Jul 21, 2010 at 4:57 PM, Gabriel Horner <gabriel.horner@gmail.com> wrote: > On Tue, Jul 20, 2010 at 5:50 PM, Joshua Peek <josh@joshpeek.com> wrote: >> On Tue, Jul 20, 2010 at 3:48 PM, Gabriel Horner >> <gabriel.horner@gmail.com> wrote: >>> On Tue, Jul 20, 2010 at 11:42 AM, Joshua Peek <josh@joshpeek.com> wrote: >>>> On Tue, Jul 20, 2010 at 9:54 AM, Gabriel Horner >>>> <gabriel.horner@gmail.com> wrote: >>>>> On Wed, Jul 14, 2010 at 3:11 AM, Gabriel Horner >>>>> <gabriel.horner@gmail.com> wrote: >>>>>>> I think we should avoid the explicit link to the "parent" package. It >>>>>>> adds some complexity to rip-gc has you mentioned and is a slippery >>>>>>> slope to package corrupt issues. >>>>> >>>>>> I'm not sure if there is a way to avoid a parent package. Rebuilding a >>>>>> package works the same as rip-build, by copying the original clean >>>>>> source (parent package) into a new directory and then building >>>>>> extensions. If we don't know where the original clean source is, what >>>>>> should we be rebuilding from? We could use the package directory >>>>>> containing extensions for a particular ruby version. But what happens >>>>>> if rebuilding for another ruby version doesn't overwrite extensions >>>>>> for the previous ruby version? We risk having packages with extensions >>>>>> for the wrong ruby version. >>>>> >>>>> There are ways of getting around this i.e. >>>>> FileUtils.rm_f(Dir[''**/*.bundle"]) so maybe it's a non-issue. >>>>> >>>>> I forgot to mention that I mainly needed to create a .rip_parent to >>>>> save the parent/source md5 and thus determine a built package's ruby >>>>> version (platform_hash). You can see how I use a package's source md5 >>>>> and current Rip.platform_hash to determine if a package belongs to the >>>>> current ruby version here: >>>>> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L21 and >>>>> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L60. Is there >>>>> another way to extract a built package's ruby version? If not, I would >>>>> propose saving a package's ruby version on each build i.e. `ruby -rrip >>>>> -e 'puts Rip.platform_hash >> .rip_platform_hash' . I would've >>>>> proposed adding this info to metadata.rip but that would mess with the >>>>> .rip format. >>>>> >>>>> Since there doesn't seem to be interest in integrating rip-ext, it >>>>> would help to at least have a package's ruby version so rip-ext can >>>>> exist as a plugin. >>>> >>>> Lets write out platform to compiled packages somewhere. We should >>>> store the full path to the ruby binary that built the package so we >>>> can reread that and get fetch the arch string to print in rip list. >>> >>> Okay. Sounds like we're talking about saving the same output i.e. >>> Rip.shell_ruby_platform. The question is how to save it. I suggested >>> saving it in a .rip_platform_hash file in a package's directory. We >>> could also save it globally i.e. ~/.rip/.versions.yml and have the >>> yaml file be a hash mapping package file basenames to these ruby >>> platform values. Thoughts? >> >> Right, It would be in the package dir, but I'm not sure what to call >> it. I want to rename the existing stuff away from "platform". > > Since we're saving RbConfig::CONFIG['sitearchdir'], why not just > .rip_archdir? Or perhaps .rip_ruby_version? arch is just "i686-darwin10.3.0", doesn't convey any version information. -- Joshua Peek
For anyone interested, I made rip-ext into a rip plugin: http://github.com/cldwalker/rip-ext Works beautifully to synchronize rip envs across ruby versions. On Wed, Jul 21, 2010 at 6:30 PM, Joshua Peek <josh@joshpeek.com> wrote: > On Wed, Jul 21, 2010 at 4:57 PM, Gabriel Horner > <gabriel.horner@gmail.com> wrote: >> On Tue, Jul 20, 2010 at 5:50 PM, Joshua Peek <josh@joshpeek.com> wrote: >>> On Tue, Jul 20, 2010 at 3:48 PM, Gabriel Horner >>> <gabriel.horner@gmail.com> wrote: >>>> On Tue, Jul 20, 2010 at 11:42 AM, Joshua Peek <josh@joshpeek.com> wrote: >>>>> On Tue, Jul 20, 2010 at 9:54 AM, Gabriel Horner >>>>> <gabriel.horner@gmail.com> wrote: >>>>>> On Wed, Jul 14, 2010 at 3:11 AM, Gabriel Horner >>>>>> <gabriel.horner@gmail.com> wrote: >>>>>>>> I think we should avoid the explicit link to the "parent" package. It >>>>>>>> adds some complexity to rip-gc has you mentioned and is a slippery >>>>>>>> slope to package corrupt issues. >>>>>> >>>>>>> I'm not sure if there is a way to avoid a parent package. Rebuilding a >>>>>>> package works the same as rip-build, by copying the original clean >>>>>>> source (parent package) into a new directory and then building >>>>>>> extensions. If we don't know where the original clean source is, what >>>>>>> should we be rebuilding from? We could use the package directory >>>>>>> containing extensions for a particular ruby version. But what happens >>>>>>> if rebuilding for another ruby version doesn't overwrite extensions >>>>>>> for the previous ruby version? We risk having packages with extensions >>>>>>> for the wrong ruby version. >>>>>> >>>>>> There are ways of getting around this i.e. >>>>>> FileUtils.rm_f(Dir[''**/*.bundle"]) so maybe it's a non-issue. >>>>>> >>>>>> I forgot to mention that I mainly needed to create a .rip_parent to >>>>>> save the parent/source md5 and thus determine a built package's ruby >>>>>> version (platform_hash). You can see how I use a package's source md5 >>>>>> and current Rip.platform_hash to determine if a package belongs to the >>>>>> current ruby version here: >>>>>> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L21 and >>>>>> http://github.com/cldwalker/rip/blob/ext/bin/rip-ext#L60. Is there >>>>>> another way to extract a built package's ruby version? If not, I would >>>>>> propose saving a package's ruby version on each build i.e. `ruby -rrip >>>>>> -e 'puts Rip.platform_hash >> .rip_platform_hash' . I would've >>>>>> proposed adding this info to metadata.rip but that would mess with the >>>>>> .rip format. >>>>>> >>>>>> Since there doesn't seem to be interest in integrating rip-ext, it >>>>>> would help to at least have a package's ruby version so rip-ext can >>>>>> exist as a plugin. >>>>> >>>>> Lets write out platform to compiled packages somewhere. We should >>>>> store the full path to the ruby binary that built the package so we >>>>> can reread that and get fetch the arch string to print in rip list. >>>> >>>> Okay. Sounds like we're talking about saving the same output i.e. >>>> Rip.shell_ruby_platform. The question is how to save it. I suggested >>>> saving it in a .rip_platform_hash file in a package's directory. We >>>> could also save it globally i.e. ~/.rip/.versions.yml and have the >>>> yaml file be a hash mapping package file basenames to these ruby >>>> platform values. Thoughts? >>> >>> Right, It would be in the package dir, but I'm not sure what to call >>> it. I want to rename the existing stuff away from "platform". >> >> Since we're saving RbConfig::CONFIG['sitearchdir'], why not just >> .rip_archdir? Or perhaps .rip_ruby_version? > > arch is just "i686-darwin10.3.0", doesn't convey any version information. > > > -- > Joshua Peek >
> We might be able to detect the current ruby vm and automatically pass > that info to rip-build. But we probably want a way to specify any ruby > vm to build against. > > I'd like to investigate a subpath for compiled extensions within your env: > > .rip/system/lib/ree-1.8.7/mysql.bundle > .rip/system/lib/ruby-1.9.2/mysql.bundle > > so one env could contain multiple compiled packages so you wouldn't > have to switch between multiple envs. I like that idea. So basically any of those files would be a symlink to .rip/system/lib/mysql.bundle. If we had a command like `rip-ruby-env 1.9.2` to switch the symlinks, that command could be executed in .rvmrc each time we switch ruby versions. I would vote for putting the ruby versions somewhere under lib where they're guaranteed to not conflict with other namespaces i.e. rip/system/lib/.rubies/ree-1.8.7/mysql.bundle. Some questions I still have: * When a user switches to a ruby version that doesn't have a compiled extension, should rip automatically build it or have the user explicitly do it? * What environment variables need to be set for extconf.rb for a given ruby version? I imagine most of this is in Config::CONFIG I'm up for helping out with this. The sooner I can use rip for all of my gem managing needs, the better :) Gabriel > > On Wed, Jun 16, 2010 at 5:14 PM, Gabriel Horner > <gabriel.horner@gmail.com> wrote: >> Hi, >> How do others use gems with c extensions across ruby versions? I >> don't see a way to do this with rip. For example if I `rip install >> hpricot` in 1.8.7 and then switch to 1.9.2 (with rvm), hpricot and its >> c extensions can't be used. I read the rip-build manpage and saw that >> flags could be passed to extconf.rb but wasn't sure what flags to >> pass. Anyone have a rip command that can clone a ripenv but build its >> package extensions in a different ruby version i.e. `rip clone >> hpricot_env path_to_1.9.2`? >> >> Thanks, >> Gabriel >> > > > > -- > Joshua Peek >