On 6 Aug 2014, at 9:12, Stefan Daschek wrote:
I understand that bundle commands using ruby should use the new ruby
shim.
Correct. In theory they could use the “Current” symbolic link provided
by the OS, but since it can point to either 1.8 or 2.0 (depending on
what OS we run under), such code must be written for both ruby 1.8 and
2.0 and the same goes for any code required. Currently TextMate’s
support libraries have not been updated for 2.0, so anything using
support libraries effectively can’t use ruby 2.0.
What I expect we do is first update support libraries to run on both 1.8
and 2.0, then introduce a ruby20 shim, and then we can start to migrate
commands to use the ruby20 shim instead of ruby18, that way, we don’t
have to ensure that commands work on both 1.8 and 2.0, only the support
libraries.
[…] in the RSpec bundle there are some commands to run RSpec examples
in the current project […]
Should we use $TM_RUBY for that?
Yes, always use TM_RUBY for user code, but falling back on ruby found
via PATH.
Of course this requires that any potential code running as part of the
user’s code, e.g. for Ruby → Run (⌘R) we inject an exception handler
into the user’s script, must be able to run on at least ruby 1.8 and 2.0.
Or rely on $PATH being customized correctly?
We strongly recommend not customizing PATH for the purpose of ruby.
However, if all commands use the ruby18 shim, changing PATH should not
break things.
Generally I’m a bit confused here: There’s the new ruby shim, there’s
$TM_RUBY (used in many third party bundles for running bundle
commands), there’s the possibility of customizing $PATH – what should
be used when?
Using TM_RUBY to run bundle code is wrong, but it’s something we did in
the past before we realized how big of a mess ruby compatibility would
become.
TM_RUBY is solely for things like Run, Validate Syntax, Rake, etc. where
the user may have a preference as to what ruby to use.
This is a general convention, i.e. any bundle that offers an interface
to a tool, like tidy, git, markdown, etc., should call the tool via the
TM_«tool» variable, so that it’s easy for the user to change what
version of the tool to call (and maybe add some default parameters to
this variable) — but in the implementation of a command, we should never
use a TM_«tool» variable — ideally implementations would just use the
tools from PATH, but unfortunately this has proven to not always work,
because user may install updated/alternative versions that are not
drop-in replacements for the old ones, ruby though is the main problem
here, but we’ve also had issues with people installing GNU’s mktemp and
having that before the BSD mktemp in PATH, which is why some commands
call /usr/bin/mktemp and for the former (ruby) we’ve had to introduce a
shim (previously we used absolute path, but then Apple removed ruby 1.8
in 10.10)…
_______________________________________________
textmate-dev mailing list
textmate-dev@lists.macromates.com
http://lists.macromates.com/listinfo/textmate-dev
