What is the simplest change I could make when I “upgrade” to Yosemite to allow Textmate 2 bundles to continue functioning ?
I don’t (knowingly) use Ruby for anything besides TM2, so I don’t mind symlinking Ruby 1.8 or other similar brute force approaches. best wishes, Eric — Eric Hsu, Professor of Mathematics Director, Center for Science and Mathematics Education San Francisco State University http://math.sfsu.edu/hsu On Aug 6, 2014, at 5:14 PM, Stefan Daschek <ste...@daschek.net> wrote: > Thanks for the detailled explanation! Seems like it’s time for a bunch of > pull requests ... :-) > > s. > > Am 06.08.14 um 10:46 schrieb Allan Odgaard: >> 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 > _______________________________________________ > textmate-dev mailing list > textmate-dev@lists.macromates.com > http://lists.macromates.com/listinfo/textmate-dev _______________________________________________ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
