Skip to content

Specify plugin directory #695

Closed
unnonouno opened this Issue Feb 26, 2014 · 14 comments

3 participants

@unnonouno
Jubatus member

I want to change a plugin directory on runtime.
How about use an environment variable, such as JUBATUS_PLUGIN_PATH?

@kmaehashi
Jubatus member

I think paths in LD_LIBRARY_PATH will be looked-up via dlopen.

@kmaehashi kmaehashi added this to the Far Future milestone Mar 3, 2014
@kmaehashi
Jubatus member

From discussion in meeting in 2014-03-03:

  • It's better to use specific environment variable like JUBATUS_PLUGIN_PATH instead of LD_LIBRARY_PATH, which is usually expected to be used for program invocation.
  • How about investigating other programs with plug-in features?
  • Contribution wanted!
@unnonouno
Jubatus member

First we need to the current specification.
jubatus/website#123

@kmaehashi
Jubatus member

Related to #713:

Giving basename to dlopen is ambiguous.

How about trying in this order?

  1. If absolute or relative path is given in config, try it.
  2. When failed, and if JUBATUS_PLUGIN_PATH environment variable is available, try JUBATUS_PLUGIN_PATH + basename.
  3. When failed, try JUBATUS_PLUGIN_DIR (compile-time option) + basename.
  4. When failed, raise exception.

In this way, we can tell the exact path to the library when loading it.
This also means LD_LIBRARY_PATH etc. to be ignored.

@tkng
Jubatus member
tkng commented Mar 12, 2014

Hi,

I think it is good to follow the conventions of the famous OSS like Gtk+.

Gtk+ provides an environment variable GTK_PATH. In a nutshell, when the variable is set, Gtk+ loads plugins under the path. If not set, Gtk+ loads plugins under the default path (determined when Gtk+ was configured.)

Detailed behavior of Gtk+ is somewhat complex, so please see the following URL:

https://developer.gnome.org/gtk3/stable/gtk-running.html

@unnonouno
Jubatus member

I also think using LD_LIBRARY_PATH is a bad idea. It is confusing.
@kmaehashi 's idea and @tkng 's idea are same, aren't they?

I also found some plugin frameworks:
http://boost-extension.redshoelace.com/docs/boost/extension/index.html
http://www.codeproject.com/Articles/20648/DynObj-C-Cross-Platform-Plugin-Objects

@tkng
Jubatus member
tkng commented Mar 12, 2014

I agree, @kmaehashi 's idea and my idea seems almost same.

@kmaehashi kmaehashi modified the milestone: 0.5.4, Far Future Apr 7, 2014
@unnonouno unnonouno was assigned by kmaehashi Apr 7, 2014
@unnonouno
Jubatus member

How about like this:

  1. When absolute or relative path is given (that means the path contains '/')
    • Use the path directly (dlopen does not use LD_LIBRARY_PATH in such case)
  2. Otherwise
    • Try to load from JUBATUS_PLUGIN_PATH environment variable if it is set
    • Try to load from JUBATUS_PLUGIN_DIR (compile-time option)

Do we need to use basename?

@kmaehashi
Jubatus member

@unnonouno I agree with the spec!

Do we need to use basename?

I don't think it is not needed as it's confusing.

@unnonouno
Jubatus member

I mean when a user uses a relative or absolute path, do we need to try to load a plugin from the plugin paths with its basename? In such case, a user want to load only from the current directory or the absolute path, isn't it?

@unnonouno
Jubatus member

In other word, when a user fails to write the correct path, Jubatus fails to load it, and if an old version of the same plugin locates in jubatus plugin path, Jubatus loads it. Is that expected behavior?

@kmaehashi
Jubatus member

@kmaehashi, @kumagi will review the spec.

@kmaehashi
Jubatus member

In other word, when a user fails to write the correct path, Jubatus fails to load it, and if an old version of the same plugin locates in jubatus plugin path, Jubatus loads it. Is that expected behavior?

I think it is better to raise error in that case, rather than silently using basename.

@unnonouno
Jubatus member

👍 I agree with you.

@unnonouno unnonouno closed this Apr 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.