<mpapis>
sorry had net problems, so the initial ticket describes the issue - sharing gems that do not require ruby/version and do not contain native code or c-extensions
<mpapis>
I have implemented it for --user-install as it seemed easier to start with
<mpapis>
from here it should be possible to also add GEM_HOME_SHARED
<mpapis>
but I spent already enough time on it - and do not want to continue without knowing if it would be accepted
<mpapis>
there could be still flag --disable-gem-sharing for paranoid that do not want to share gems between all rubies
<evan>
so the point is to be able to share a gem path between different rubies, right?
<mpapis>
yes
<mpapis>
but only for gems that can be shared
<evan>
and the reason that doesn't work now is largely extensions?
<mpapis>
extensions, ruby version requirement and platform
<mpapis>
those 3 - and I have examples for all of them
<evan>
platform is the same as extension really
<evan>
it's just whether or not the specific files are generated on this host or not.
<evan>
I didn't think that ruby version req was checked at install time
<mpapis>
not always, there are jruby gems that contain jars embedded
<evan>
could you show me the example for that?
<evan>
mpapis: sure, but thats just like, say, a linux .so file
<evan>
it's just that they're shipped in the gem
<evan>
rather than generated on the installing host
<mpapis>
this gem can not be installed in shared because it would be available also for 1.9 and 1.8 rubies
<mpapis>
and as code is nto compatible - some strange things would happen
<evan>
when you try to install that gem on 1.8
<evan>
what happens?
<evan>
does 'gem install' say "sorry!"
<evan>
i guess I can check
<mpapis>
trying
<mpapis>
ERROR: Error installing pluginator:pluginator requires Ruby version >= 1.9.3.
<mpapis>
- older version had 1.9.3 requirement
<evan>
ok
<evan>
i'm reading your PR again
<mpapis>
I have tested it on two gems with and without extensions - and they were installed properly into shared / ruby+version locations, also the tests are now fixed (had to spent some time on making it work)
<mpapis>
also there is extra request to automatically(lazy) handle installing extensions - but it's not part of what I want
<mpapis>
for me just the routing to shared path when installing
<evan>
The removal of check_that_user_bin_dir_is_in_path probably isn't good
<evan>
need to put that back in.
<mpapis>
it's in - just moved later after evaulation if shared or ruby+version is used
<mpapis>
and evaluation needs to read spec first
fromonesrc has joined #rubygems
cowboyd has quit [Remote host closed the connection]
<evan>
ah I see.
<evan>
given the fact that sharable gems are much, much more common than none
<evan>
I wonder if your patch shouldn't be the inverse
<mpapis>
I also have added installing gems to shared/cache always
<evan>
if GEM_UNSHARABLE_PATH is set, then thats where stuff that has extensions and such go.
<mpapis>
ah replacing all paths with shared - and only making it exception to ruby+version - not that bad idea
<mpapis>
the only concern I have is compatibility
<mpapis>
right now tools set GEM_HOME to platform path
<mpapis>
it would be up to user if he wants to set GEM_SHARED_HOME
<evan>
yes, thats true
<mpapis>
if it's set then share them
<mpapis>
and no changes in tools needed
<evan>
your code also seems to only be concerned with a sharable path in HOME
<mpapis>
for now
<evan>
what about when gems are installed outside that?
<evan>
ah ok
<mpapis>
I did not wanted to spent more time without hearing back from you
<mpapis>
I can add GEM_SHARED_HOME support when GEM_HOME is set
<mpapis>
in case when no GEM_HOME is set then bad things happen like jruby in gems/shared
<mpapis>
so I would avoid changing it for now
DanKnox_away is now known as DanKnox
huoxito has quit [Quit: Leaving]
<mpapis>
evan, ok so if you like the work I can add the GEM_SHARED_HOME support or GEM_HOME_SHARED - not sure which fits better
<evan>
I'm just thinking how this would effect other things.
DanKnox is now known as DanKnox_away
<evan>
for instance, the non-user shared dir
<evan>
since right now, the gem dir is inside the global installation dir
<evan>
for a specific ruby
<evan>
if this is only for a user's home
<evan>
I don't see any reason we can't accept your PR
<mpapis>
ah so I wanted to only use shared in case GEM_HOME_SHARED is given - or in config
DanKnox_away is now known as DanKnox
<mpapis>
also added you to my fork of rubygems in case you want to fix something fast
<mpapis>
I can leave this request as it is and build GEM_HOME_SHARED in new one to make it easier to review
paulca has quit [Quit: paulca]
<evan>
we can merge the PR the way it is now
<evan>
it's fine to have the users gems installed into their GEM_HOME be shared this way.
<mpapis>
great, this is good first step ;)
<evan>
what is the next step?
<mpapis>
implementing support for GEM_HOME_SHARED when it is set
rickhull has joined #rubygems
<evan>
what would that do?
<evan>
provide a way to explicitly set where the shared gems live?
<evan>
so, "~/.gem/shared" is the default value of GEM_HOME_SHARED?
<mpapis>
currently it works only for --user-install / when default is not writable
<mpapis>
so only when ~/.gem/ruby/2.0.0 would be used shared is picked
<mpapis>
with GEM_HOME_SHARED it would also work for GEM_HOME
<evan>
i'll have go remind myself when GEM_HOME is in play then :)
<evan>
I thought it was the same case you've given
<mpapis>
GEM_HOME is used by ruby version managers
<mpapis>
this would be better then the current shebang trick that can be done by anyone without any checks
kobier has joined #rubygems
kobier has quit [Client Quit]
<evan>
mpapis: whitelisting what?
tenderlove has quit [Remote host closed the connection]
<evan>
mpapis: ooh, looks like I misread what the patch does
tenderlove has joined #rubygems
<evan>
let me reread
<mpapis>
the allowed hooks - to prevent unauthorized hooking into gem executables
tenderlove has quit [Read error: Connection reset by peer]
tenderlove has joined #rubygems
<evan>
this runs basically any code at gem install time, yes?
<evan>
I think the name is confusing me
<evan>
is this hook like all the other hooks
<evan>
it's just used when generating the binstub?
dvu_ has quit [Remote host closed the connection]
jeremydei has quit [Ping timeout: 264 seconds]
<evan>
oh, it's in the stub
<evan>
the diff is confusing.
<evan>
I really don't want to do that
fromonesrc has quit [Ping timeout: 240 seconds]
<evan>
it's going to add large amounts of time startup
<evan>
having to search for the plugin each time
jeremydei has joined #rubygems
<evan>
the binstub is a very sensitive place
tenderlove has quit [Ping timeout: 240 seconds]
<evan>
if you can show that it doesn't change the startup speed
dvu_ has joined #rubygems
<evan>
then we'll consider it's other merits
<evan>
there is a big chicken-and-egg with adding this now though
<evan>
because it will run for some gems but not others
<evan>
due to the time when binstubs are generated.
fromonesrc has joined #rubygems
AlHafoudh has joined #rubygems
<mpapis>
evan, yeah there are multiple things to consider - speed is not an issue - I have tested with 200 gems with no slowdown, the search adds nothing to time
<mpapis>
for existing gems - I have also a RG command regenerate_binstubs - I could add it too
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<mpapis>
my only concern is that right now any gem can hook already to rubygems and do the same harm with shebang - user can not stop it, with whitelsting and disabling shebang we would give user control back over what is ran with gem executables