Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine adapterPath in robot.coffee, rather than bin/hubot #1109

Merged
merged 1 commit into from
Jan 20, 2016

Conversation

technicalpickles
Copy link
Member

Previously, adapterPath was determined in bin/hubot, and passed to index.coffee,
and eventually passed ot the constructor in robot.coffee. This is used by Robot
to determine where to load builtin adapters from.

It also makes it hard to progmatically construct a robot without running bin/hubot,
since you'd need to find a way to figure out the path that the hubot module is installed.

This changes it so Robot will determine the adapterPath since it's relative to where
it live. The constructor still takes it as an option so it remains backward compatible
to anything that might be specifying it.

This is work towards #858

Previously, adapterPath was determined in bin/hubot, and passed to index.coffee,
 and eventually passed ot the constructor in robot.coffee. This is used by Robot
to determine where to load builtin adapters from.

It also makes it hard to progmatically construct a robot without running bin/hubot,
since you'd need to find a way to figure out the path that the hubot module is installed.

This changes it so Robot will determine the adapterPath since it's relative to where
it live. The constructor still takes it as an option so it remains backward compatible
 to anything that might be specifying it.
@technicalpickles
Copy link
Member Author

This allows you to have a file like index.coffee:

Hubot = require 'hubot'

robot = new Hubot.Robot(null, 'shell', false, 'Hubot', '/')

robot.respond /ping/i, (res) ->
  res.send 'PONG'

require('hubot-shipit')(robot)

robot.run()

And to run it with coffee index.coffee.

@technicalpickles
Copy link
Member Author

I was able to take that example a bit further:

Hubot = require 'hubot'
Path  = require 'path'robot = new Hubot.Robot(null, 'shell', false, 'Hubot', '/')
​
# wait for adapter to be connected, since it might change things at runtime,
# like robot name
robot.adapter.on 'connected', -># require external hubot scripts
  require('hubot-help')(robot)
  require('hubot-shipit')(robot)
​
  # load scripts from a local scripts directory
  # NOTE you need to either specify NODE_PATH=. or Path.resolve a local directory for this to work
  robot.load Path.resolve 'scripts'# or do things them inline
  robot.respond /ping/i, (res) ->
    res.send 'PONG'# then run hubot
robot.run()

technicalpickles added a commit that referenced this pull request Jan 20, 2016
Determine adapterPath in robot.coffee, rather than bin/hubot
@technicalpickles technicalpickles merged commit 4f9544e into master Jan 20, 2016
@technicalpickles technicalpickles deleted the robot-determine-own-adapter-path branch January 20, 2016 03:38
@technicalpickles technicalpickles mentioned this pull request Jan 20, 2016
# adapter - A String of the adapter name.
# httpd - A Boolean whether to enable the HTTP daemon.
# name - A String of the robot name, defaults to Hubot.
#
# Returns nothing.
constructor: (adapterPath, adapter, httpd, name = 'Hubot', alias = false) ->
@adapterPath ?= Path.join __dirname, "adapters"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the list of adapters is hard coded as a constant (used on L461), it seems to me the adapter path should be hard coded as well... I guess we're maintaining backwards compatibility, but I can't ever see a situation when you would actually want to specify a custom adapterPath.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants