Load plugins via setuptools entrypoints

[jayvdb]

See moremoban/moban#191 for the need. coala could also use this, as it loads bears using setuptools, and it would be really nice to have the setuptools dependency/problem managed.

I'm not sure lml is the best option, but it is worth asking the question and having a decision whether this would work.

There are three options, either

1. wrap setuptools
2. use an existing library which re-implements setuptools
3. re-implement this setuptools feature internally within lml

If the first option is taken, there are a lot of versions of setuptools which are broken and need blacklisting, depending on which features is used, so it would be helpful to have a set of tests here which verify all supported versions of setuptools load the hooks correctly.

[chfw]

lml picks up modules from current python environment using pkgutil.iter_modules(). If the package has not been installed, I'm afraid that lml has no power. This is my current understanding. and I need more enlightenment.

[chfw]

entry_points="""
          [babel.extractors]
          kajiki = kajiki.i18n:extract
          [python.templating.engines]
          kajiki = kajiki.integration.turbogears1:XMLTemplateEnginePlugin
      """

after the package installation, if the entry is exposed somehow, then lml can try to access it.

[jayvdb]

The need is to find & load installed packages registered under entry point 'python.templating.engines'.

I expect this will stop lml being lightweight ;-)

So maybe it is better for moban to load them using setuptools, or another wrapper if helpful.

[jayvdb]

coala/coala#5755 provides a much safer way to use setuptools.

[chfw]

I had a look. thanks for the pointer. See my comments below

---

The entry point specs in coala's setup point to an included directory with the installed package. And when coala starts, all end points were scanned for bears and bears are then loaded.

I had a look at https://github.com/coala/coala-bears/blob/master/bears directory and all official bears are found there.

---

From lml's perspective, lml asks for each lml based python package to expose their spec in highest level of init.py, i.e. https://github.com/moremoban/moban-handlebars/blob/dev/moban_handlebars/__init__.py, where the relative path of the plugin location is then up to the plugin developer to decide.

---

If lml is to support coala's way of loading bears, lml can take advantage of existing coala code to find out where the bears but still lml would require https://github.com/coala/coala-bears/blob/master/bears/__init__.py to give a full specification/registry of all bears.

Once __init__.py is done, we would then ask a question, why not provide such a registry into module level __init__.py, for which lml does not need to write any extra codes.

Why should __init__.py have a specification/registry? For lazy loading, the registry tells lml that this library path does 'x'. When 'x' in runtime is summoned, lml loads the library path in memory. For proactive loading, the plugin shall exists in module level __init__.py, meaning this plugin is loaded immediately into memory during plugin-discovery phase, however although I do not foresee the value of proactive loading, it is doable with lml.

[jayvdb]

https://gitlab.com/coala/bears has more bear.

But primary motivation is hook 'python.templating.engines'

[jayvdb]

https://pypi.org/project/entrypoints/ could be helpful.

[chfw]

Just found Python file system 2 use setup entry points too.