python-lml / lml Goto Github PK

atm, it only looks for any plugin names that start with a text, or that is white-listed and is not black-listed.

but now, it needs support plugin names that end with a text.

hence, the change will be to support regular expression in search so that prefix and suffix could be specified in one regular expression.

reference:

moremoban/moban#35

Receiving this warning when trying out the v2 example . Any suggestions on fixing it ?
$robotchef_v2 "Portable Battery"
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/lml/loader.py:64: UserWarning: Deprecated! since version 0.0.3. Please use scan_plugins_regex!
"Deprecated! since version 0.0.3. Please use scan_plugins_regex!"
I can cook Portable Battery for robots

Regards

When a white-listed extension is absent, ignore the ModuleNotFoundError.

https://github.com/chfw/lml/blob/master/lml/utils.py#L43

reference: pyecharts/pyecharts#815

There is a situation where a plugin is not installed then please use raise_exception() function call so that downstream/lower lane could handle it properly.

https://github.com/indygreg/PyOxidizer/ is really interesting, especially as it has decided to not support __file__ (indygreg/PyOxidizer#69).

https://github.com/storyscript/community/issues/8#issuecomment-540956151 has a survey of the other similar tools.

If PyOxidizer works with lml, the others should also work.

The ability to ship a moban standalone binary with all deps, and extensions, included, would be fantastic ;-)

It would be ok even if some lml functionality is degraded because of no __file__.

PyOxidizer can be detected with sys.oxidized, and other similar tools usually set sys._MEIPASS.

Currently tests fail quite badly on PyOxidizer and other similar tools.

On Python 2.7, the tests need mock, and six is also mentioned in tests/requirements.txt but I can not see it mentioned in the source of the tests.

Even with them both installed on openSUSE, there is an interesting error at https://github.com/chfw/lml/blob/master/tests/test_utils.py#L16
import pyexcel_test

======================================================================
ERROR: test_utils.test_do_import
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/abuild/rpmbuild/BUILD/lml-0.0.8/tests/test_utils.py", line 17, in test_do_import
    import pyexcel_test
ImportError: No module named pyexcel_test

and also two others like

======================================================================
ERROR: test_plugin_loader.test_load_plugins
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/usr/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched
    return func(*args, **keywargs)
  File "/home/abuild/rpmbuild/BUILD/lml-0.0.8/tests/test_plugin_loader.py", line 39, in test_load_plugins
    info = CACHED_PLUGIN_INFO["test_io"][0]
IndexError: list index out of range
-------------------- >> begin captured logging << --------------------
lml.loader: DEBUG: scanning for plugins...
lml.utils: ERROR: pyexcel_test is abscent or cannot be imported
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/BUILD/lml-0.0.8/lml/utils.py", line 42, in do_import
    return _do_import(plugin_module_name)
  File "/home/abuild/rpmbuild/BUILD/lml-0.0.8/lml/utils.py", line 51, in _do_import
    plugin_module = __import__(plugin_module_name)
ImportError: No module named pyexcel_test
lml.loader: DEBUG: pyexcel_test
lml.loader: DEBUG: No module named pyexcel_test
lml.loader: DEBUG: ignored pyexcel_io
lml.loader: DEBUG: scanning done
--------------------- >> end captured logging << ---------------------

https://build.opensuse.org/package/live_build_log/home:jayvdb:soe/python-lml/openSUSE_Tumbleweed/x86_64

It might be related to different versions of six ..?

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.

because their tag groups were not registered whereas load-me-now plugins get tag groups registered. Hence it creates a discrepancy in behavior in moban's plugins.

I am building openSUSE packages for lml & moban at https://build.opensuse.org/project/show/home:jayvdb:soe , and noticed that the tests and docs/source are missing, so there is only one doctest running to validate the package.

If they are not too big, it would be good to include tests and docs/source in the source tarball.

Alternatively, a second tarball including those could be created during the release process, to be used by packagers.

(I expect I will encounter the same problem when polishing the package for moban)

Could you please consider to use unittest.mock instead of mock, at least optionally?

Would love to be able to list loaded plugins.
Maybe also displaying some info about them: name, tags, etc.

The links for source code and issues at http://lml.readthedocs.io/ point to the nonexistent http://github.com/lml/lml

I initially created the openSUSE .spec using py2pack, and it injected the following into the spec

License: New BSD (FIXME:No SPDX)

I havent fully investigated this yet, and it isnt mentioned in https://en.opensuse.org/openSUSE:Packaging_Python .

I have found https://github.com/openSUSE/py2pack/blob/master/py2pack/spdx_license_map.p , which contains both New BSD License and BSD-3-Clause.

Interesting that https://packaging.python.org/tutorials/packaging-projects/ doesnt mention using setup(.. license='...', ..) at all.

Semi related, we should at least be including some more Trove classifiers, including a license classifier -- probably this one...?

License :: OSI Approved :: BSD License

No need to rush out a new release for this, as I can manually solve this one in the .spec , but it is an interesting problem that needs to be understood and solved so that running py2pack on a moban powered package 'just works', to make it easier to package them (them = moban / pyexcel / etc).