This has been covered before ( http://lists.macromates.com/textmate-dev/2009-May/013933.html ), so I'm not hopfeul, but I thought it was worth asking again, in case anything has changed. Probably not.
The responders to the thread linked above recommend writing Ruby modules and stuff, which I do when I'm working on a bundle, but what if I have a bundle and I want to call another bundle's commands?
Fortunately, I'm in control of both bundles, but for organizational and responsibility reasons, I don't want to combine them. One is very utilitarian (basic FTP) and the other is extremely specific (stuff related to a single project I work on, has absolutely no relevance to anything outside of the project). The good news is that I already have my bundles set up to be somewhat modular/class-driven.
I realize that doing this creates dependencies between bundles, but I'm OK with this, and feel it's better than recreating my FTP commands in another bundle.
One thought I had would be to get the TM_BUNDLE_SUPPORT value, pop off the bundle name and replace it with the bundle name of the target, and get to the Ruby file I need. But then...wouldn't any TM_BUNDLE_SUPPORT values used in the other bundle's scripts evalulate to the wrong place?
Would it be better to find a place for such universally appealing ruby files outside of TextMate? Should I learn how to write plugins, and/or deposit code into the SUPPORT_PATH?
The original poster's idea seems close to my idea. But it would be sweet to be able to do something like:
require ENV['TM_SUPPORT_PATH'] + '/lib/bundle_access' BundleAccess.executeCommand("Some Bundle", "Some Command", argin)
Or something that could safely instantiate Ruby objects from other bundles to allow them to be used in your bundle without mucking with the BUNDLE_SUPPORT value.
I don't know...just spitballing.
Thanks, Dru
On 27 Oct 2009, at 01:52, Dru Kepple wrote:
[…] One thought I had would be to get the TM_BUNDLE_SUPPORT value, pop off the bundle name and replace it with the bundle name of the target, and get to the Ruby file I need. But then...wouldn't any TM_BUNDLE_SUPPORT values used in the other bundle's scripts evalulate to the wrong place?
It will be possible to mark either a bundle or command to require another bundle. That will give TM_«bundle»_SUPPORT_PATH in the environment, but I did not consider that the included functionality might expect TM_BUNDLE_SUPPORT to point to “current dir” — though I don’t think stuff in a bundle’s support folder would need to make a reference to this variable, all files should be available via relative paths.
So I would suggest that you do what you suggest, that is, simply “hardcode” knowledge about where that other bundle is (relative to the current), and in the future, TM will resolve the proper path for you, so you can take out the hardcoding.
Would it be better to find a place for such universally appealing ruby files outside of TextMate? Should I learn how to write plugins, and/or deposit code into the SUPPORT_PATH?
I think your bundle approach is the proper one. In fact, when bundle requirements will be introduced (2.0) we intend to move a lot of the things in the shared support folder into bundles that will then be required by their respective users.
As for invoking commands (rather than including shared library files) that is a way more complex problem to solve, and I don’t think this should become general functionality, though I do want to expose the commands to CLI apps, mainly so that commands can be used as regular filters (in a shell).
That's positive information, Allan, thank you. Looking forward to 2.0...keep it up!
-----Original Message----- From: textmate-bounces+dru=summitprojects.com@lists.macromates.com [mailto:textmate-bounces+dru=summitprojects.com@lists.macromates.com] On Behalf Of Allan Odgaard
It will be possible to mark either a bundle or command to require another bundle. That will give TM_<bundle>_SUPPORT_PATH in the environment, but I did not consider that the included functionality might expect TM_BUNDLE_SUPPORT to point to "current dir" - though I don't think stuff in a bundle's support folder would need to make a reference to this variable, all files should be available via relative paths.
-
Allan Odgaard -
Dru Kepple