Standard plugin locations

Development
#1

Hi,

I have been spending some time working on improvements to our build
system. Part of this is making the prospect of writing external plugins
compiled outside of the Avogadro source directory simpler. So you will
notice some changes being pushed soon to make Avogadro easily
discoverable when using CMake as your build system.

This brings the question of standard locations to install contributed
plugins. I think one should be system wide, and one should be in the
users home directory. One application currently doing something similar
is ParaView [1], and so I thought we might take some inspiration from there.

They use HOME/.config/ParaView/ParaView<version>/Plugins for Unix/Linux/Mac and %APPDATA\ParaView\ParaView\Plugins for
Windows. Does this seem reasonable? I would propose the system wide
location be,

$ORIGIN/…/$LIB_INSTALL_DIR/avogadro/contrib
-> /usr/local/lib/avogadro/contrib (default on Linux - using relative
pathing)

Then the user specific ones could be,

$HOME/.config/Avogadro/plugins
-> HOME/.config/Avogadro-0.9/plugins (using major and minor version) %APPDATA\Avogadro\Avogadro\plugins
-> %APPDATA$\Avogadro\Avogadro-0.9\plugins (as above)

The code changes would be quite minimal, but I think it is important
that we agree on a convention and stick to it. Currently we do not load
anything outside of the system installed plugins.

Another point is ensuring users of the Avogadro library can load custom
plugins. I was thinking of adding PluginManager::loadFactories(const
QString& dir) that would take a plugin directory as an argument and load
the plugins in there.

Thanks,

Marcus

[1] http://paraview.org/Wiki/Plugin_HowTo

#2

On Apr 22, 2009, at 5:05 PM, Marcus D. Hanwell wrote:

They use HOME/.config/ParaView/ParaView<version>/Plugins for Unix/Linux/Mac and %APPDATA\ParaView\ParaView\Plugins for
Windows. Does this seem reasonable? I would propose the system wide
location be,
…
Another point is ensuring users of the Avogadro library can load
custom
plugins. I was thinking of adding PluginManager::loadFactories(const
QString& dir) that would take a plugin directory

Yeah, absolutely. People will want to add directories of plugins or
scripts. And we should have some documented locations where plugins
should be installed. I think it’s really good that we can have a per-
system and per-user path at a minimum.

I’d suggest that on Mac, we use $HOME/Library/Application Support/
Avogadro/Plugins – this directory is visible to users, while .config
is not. Plus, many advanced Mac users are used to putting scripts of
various kinds into ~/Library/

Cheers,
-Geoff

#3

On Wed, Apr 22, 2009 at 05:05:02PM -0400, Marcus D. Hanwell wrote:

$ORIGIN/…/$LIB_INSTALL_DIR/avogadro/contrib
-> /usr/local/lib/avogadro/contrib (default on Linux - using relative
pathing)

I think you have to distinguish between three cases on GNU/Linux: 1.
Distribution-installed plugins, 2. Sysadmin-installed plugins, 3.
User-installed plugins.

The first would be e.g. /usr/lib/avogadro/, the second
/usr/local/lib/avogadro, and something in ~/ for the third.

Then the user specific ones could be,

$HOME/.config/Avogadro/plugins
-> $HOME/.config/Avogadro-0.9/plugins (using major and minor version)

Are you sure binary objects (which I assume plugins are) should be below
~/.config? This looks like a serious violation of what users might
expect in ~/.config to me. So why not have ~/.avogadro/plugins? (or
maybe make that directory versioned)

Michael

#4

Michael Banck wrote:

On Wed, Apr 22, 2009 at 05:05:02PM -0400, Marcus D. Hanwell wrote:

$ORIGIN/…/$LIB_INSTALL_DIR/avogadro/contrib
-> /usr/local/lib/avogadro/contrib (default on Linux - using relative
pathing)

I think you have to distinguish between three cases on GNU/Linux: 1.
Distribution-installed plugins, 2. Sysadmin-installed plugins, 3.
User-installed plugins.

The first would be e.g. /usr/lib/avogadro/, the second
/usr/local/lib/avogadro, and something in ~/ for the third.

I think the second case is a great idea for Linux at least. Mac and
Windows do not seem to have equivalents to this.

Then the user specific ones could be,

$HOME/.config/Avogadro/plugins
-> $HOME/.config/Avogadro-0.9/plugins (using major and minor version)

Are you sure binary objects (which I assume plugins are) should be below
~/.config? This looks like a serious violation of what users might
expect in ~/.config to me. So why not have ~/.avogadro/plugins? (or
maybe make that directory versioned)

I just want us to agree on something and stick to it. I was influenced
by ParaView, but can see that a .config directory should likely just
contain configuration files. So I propose using
~/.avogadro//plugins, although the versioning may be overkill
as we can bump the plugin API version to prevent older Avogadro’s
loading new plugins.

#5

I know I haven’t said much but I felt I could chime in here cause i
think natural intuition is important…

You should determine the plugin location by using the $PREFIX variable
at compile time. If someone says to install avogadro to (for extreme
example) /opt/avogadro/install

then avogadro should look in: /opt/avogadro/install/lib/avogadro

I don’t think you should hardcore /usr or /usr/local. As far as I know,
/usr/local is something that kinda just developed out of habit, and not
all distributions even mess with /usr/local by default. I don’t think
i’d consider /usr/local to be sysadmin installed plugins but i see what
your point is. However, if you’re a sysadmin and you’re doing something
like that, just setup an environment variable… that’s why there is
/etc/env.d in gentoo and other distros. Environment tweaks.
What if an admin wants to use ‘/usr/extra’ as their sysadmin install
directory, or if they want multiple directories shared off an nfs.

On mac this of course needs to be handled differently. If someone wants
to install to non-standard locations, then they should use an
appropriate environment variable…

BUT, i do agree that there should be a standard ‘local’ plugin directory
by default in ~/.avogadro or something like that.

I don’t think you need versioning in the local directory.

Well, it’s OK either way, i just thought i’d chime in and say hi!..

OUT,
Donald

(Thu, Apr 23, 2009 at 12:10:04PM -0400) “Marcus D. Hanwell” marcus@cryos.org:

Michael Banck wrote:

On Wed, Apr 22, 2009 at 05:05:02PM -0400, Marcus D. Hanwell wrote:

$ORIGIN/…/$LIB_INSTALL_DIR/avogadro/contrib
-> /usr/local/lib/avogadro/contrib (default on Linux - using relative
pathing)

I think you have to distinguish between three cases on GNU/Linux: 1.
Distribution-installed plugins, 2. Sysadmin-installed plugins, 3.
User-installed plugins.

The first would be e.g. /usr/lib/avogadro/, the second
/usr/local/lib/avogadro, and something in ~/ for the third.

I think the second case is a great idea for Linux at least. Mac and
Windows do not seem to have equivalents to this.

Then the user specific ones could be,

$HOME/.config/Avogadro/plugins
-> $HOME/.config/Avogadro-0.9/plugins (using major and minor version)

Are you sure binary objects (which I assume plugins are) should be below
~/.config? This looks like a serious violation of what users might
expect in ~/.config to me. So why not have ~/.avogadro/plugins? (or
maybe make that directory versioned)

I just want us to agree on something and stick to it. I was influenced
by ParaView, but can see that a .config directory should likely just
contain configuration files. So I propose using
~/.avogadro//plugins, although the versioning may be overkill
as we can bump the plugin API version to prevent older Avogadro’s
loading new plugins.

Stay on top of everything new and different, both inside and
around Java ™ technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

#6

Hi,

On Thu, Apr 23, 2009 at 11:24:12AM -0500, Donald Ephraim Curtis wrote:

You should determine the plugin location by using the $PREFIX variable
at compile time. If someone says to install avogadro to (for extreme
example) /opt/avogadro/install

then avogadro should look in: /opt/avogadro/install/lib/avogadro

Well, certainly. This would be the distribution-case for distributions,
or anything what the user/sysadmin wants for local installs.

I don’t think you should hardcore /usr or /usr/local. As far as I
know, /usr/local is something that kinda just developed out of habit,

I was suggesting looking there optionally. AFAIK /usr/local is
specified by the File Hierachy Standard for locally-installed stuff.

and not all distributions even mess with /usr/local by default.

Sure, e.g. Debian/Ubuntu guarantee not to mess with /usr/local, ever,
as it is consideres sysadmin turf.

i’d consider /usr/local to be sysadmin installed plugins but i see what
your point is. However, if you’re a sysadmin and you’re doing something
like that, just setup an environment variable… that’s why there is
/etc/env.d in gentoo and other distros. Environment tweaks.

Personally, I don’t like having to set environment variable to make
software work.

But anyway, I am not sure a hypothetical sysadmin installing 3rd-party
Avogadro plugins is so likely to happen that we should argue a lot about
this.

Michael

#7

Michael Banck wrote:

Hi,

On Thu, Apr 23, 2009 at 11:24:12AM -0500, Donald Ephraim Curtis wrote:

You should determine the plugin location by using the $PREFIX variable
at compile time. If someone says to install avogadro to (for extreme
example) /opt/avogadro/install

then avogadro should look in: /opt/avogadro/install/lib/avogadro

Well, certainly. This would be the distribution-case for distributions,
or anything what the user/sysadmin wants for local installs.

We currently look relative to the binary location at runtime, i.e.
$origin/…//avogadro/. This allows Avogadro to be relocated
after compile time and still find its plugins without the need of
environment variables.

I don’t think you should hardcore /usr or /usr/local. As far as I
know, /usr/local is something that kinda just developed out of habit,

I was suggesting looking there optionally. AFAIK /usr/local is
specified by the File Hierachy Standard for locally-installed stuff.

Yes, it is for user compiled applications. This seems like it would be a
reasonable candidate to be hard coded on Linux.

and not all distributions even mess with /usr/local by default.

Sure, e.g. Debian/Ubuntu guarantee not to mess with /usr/local, ever,
as it is consideres sysadmin turf.

As does Gentoo, and I think virtually every other distro. It seems like
for that reason it would be a good candidate for system wide plugins
installed by an administrator. May be this is overkill for Avogadro
though. The simpler proposal I originally had was searching our
<bin_location>…/<lib_dir>/avogadro/contrib for contributed system wide
plugins. This would not be touched by Avogadro, in much the same way
that Python etc allow additional extensions in the same prefix.

i’d consider /usr/local to be sysadmin installed plugins but i see what
your point is. However, if you’re a sysadmin and you’re doing something
like that, just setup an environment variable… that’s why there is
/etc/env.d in gentoo and other distros. Environment tweaks.

Personally, I don’t like having to set environment variable to make
software work.

But anyway, I am not sure a hypothetical sysadmin installing 3rd-party
Avogadro plugins is so likely to happen that we should argue a lot about
this.

I wondered. It also does not translate outside of Avogadro. Any sysadmin
installing extra plugins would likely do whatever we documented. There
is something to be said for having a directory for system wide plugins
in the same prefix if it is an NFS mounted volume too.