Missing advices for plugin development

[smortex]

Hello

Some more information about his project in the root REAME.md file would be awesome!

Goal of this repository

Is this repository supposed to become a common place for finding plugins ? If I develop a plugin, should I fork this repository, hack in a branch and do a pull request, or should I create a dedicated repository for that purpose ?

Naming convention

How should I name my plugin ? For example, the command-mystats directory contains a plugin referenced to as pkg-plugin-mystats and then as pkg-plugins-mystats in the README file, while the installed binary is called mystats(.so) and the configuration file has to refer to mystats for enabling it… That's a bit confusing, some guidance would be welcome.

Thanks!

[dnaeon]

Hi,

Some time ago, I've created a documentation specifically for this purpose -- introduction to writing plugins for pkgng.

Though a a few things might have changed since then the general idea is the same. You can find the documentation at the link below:

• http://unix-heaven.org/writing-plugins-for-pkgng

If you spot things which are not the way as described there, please point them out so I can update the documentation.

Hope you find it useful and happy hacking! :)

[smortex]

Hi!

This handbook would have saved me a few hours of code browsing :-) Is it possible to add a link to it on this project's README.md? Or maybe even better, migrate the content in this project so that people can contribute more easily?

A few things have to be updated there:

• The init() function is now called pkg_plugin_init();
• A typo for previous (search for previus, there may be more :smiley: );
• The shutdown function pkg_plugins_shutdown_stats() should be pkg_plugins_shutdown();
• A chapter on writting new commands may be a plus;

To get back to my original point, I unfortunately did not find answers to my questions… I have authored a plugin that reports leaf packages by providing a pkg leaves command. I could not find a pkg plugins repository (I mean some kind of pkg plugins market where I can search for something somebody might have already coded) so I created a repository and put the code there, but it might not be ideal in a sharing point of view. Moreover, I have some concerns about the name of my repository / plugin since the examples I found in this repository are a bit inconsistent in regard to that.

What would really help is a quick-start guide that tells:

---

If you are writting a plugin that provide a foo command, you should have the following source tree:

• pkg-plugin-command-foo/
  • Makefile
  • README.md
  • foo.c

…and if should install foo.so into ${PREFIX}/lib/pkg/commands.

If you are writting a torrent-fetch plugin that use hooks to fetch distfiles using bitorrent, you should have the following source tree:

• pkg-plugin-torrent-fetch/
  • vendor/
  • bitorrent.c
  • Makefile
  • README.md
  • torrent-fetch.c

…and if should install torrent-fetch.so into ${PREFIX}/lib/pkg.

If you are storing your plugin on github, name your repository pkg-plugin-command-<name> if it provides a command or pkg-plugin-<name> otherwise (and if does both, what dot do?) and ask for referencing it over there.

---

Code snippets would be cool too. I think that make it so confusing for me is that there are two kinds of plugins, but only a single template…

[dnaeon]

Hi,

I remember that I've added 2 kind of templates when I first committed the initial plugins implementation, but that could have been wiped out during the refactoring, I'll need to check that :)

I like the idea of having the handbook in Github, so that people can also contribute. I'll try to find some free time and publish the handbook here, but can't say when exactly as I'm a bit ENOTIME these days...

Regards,

[bapt]

2013/2/4 Marin Atanasov Nikolov notifications@github.com

Hi,

I remember that I've added 2 kind of templates when I first committed the initial plugins implementation, but that could have been wiped out during the refactoring, I'll need to check that :)

I like the idea of having the handbook in Github, so that people can also contribute. I'll try to find some free time and publish the handbook here, but can't say when exactly as I'm a bit ENOTIME these days...

Regards,

Your version of the plugin is totally outdated, looking at existing plugins migh help.

It is really simple to create plugin for the new interface, sorry I haven't yet documented the new way.

regards, Bapt

[MirLach]

I am searching the net for some documentation about writing plugins for pkg and found this issue. Is there any doc / handbook available? http://unix-heaven.org/writing-plugins-for-pkgng does not work anymore.

Must be plugins written in C or is there possibility to use shellscripts as a plugins?

[srcbucket]

@MirLach You may want to have a look at https://github.com/freebsd/pkg-plugins/pull/2, which updates some of the examples.

The easiest way is for sure to go with C. Of course plugins can be written in any language, as long as they are available as a shared library (<plugin-name>.so) that implements the expected interface. This is not possible using shellscripts.