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
