[txmt-dev] Re: How to run the right™ Ruby in bundle commands
On 6 Aug 2014, at 23:20, Eric Hsu wrote: What is the simplest change I could make when I “upgrade” to Yosemite to allow Textmate 2 bundles to continue functioning ? Any standard bundle should work out of the box, as it will use the ruby18 shim, which checks if your system has ruby 1.8, and if not, will download it to TextMate’s Application Support folder, and then use that. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: How to run the right™ Ruby in bundle commands
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 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
[txmt-dev] Re: How to run the right™ Ruby in bundle commands
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
[txmt-dev] Re: How to run the right™ Ruby in bundle commands
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
