Python enthought apptools with merging namespace - python-2.7

I am currently using python 2.7 with enthought from pythonxy package.
In my software, I need to use my own user_manager and other permissions tool. So I need to add external sources into apptools.permissions.
In apptools documentation, it said I need to develop another egg with namespace, apptools.permissions.external.
Therefore, I have developed a folder with three level:
apptools,
apptools.permissions,
apptools.permissions.external.
and setup.py.
In setup.py, I wrote:
# 3
from setuptools import setup, find_packages
setup(
name = "apptools.permissions.external",
author = "Airbus",
version = '0.1' ,
include_package_data = True, package_data={'': ['*.*']},
packages = find_packages(),#exclude=["*.tests", "*.tests.*", "tests.*", "tests"]),
test_suite = 'nose.collector',
entry_points = """
[envisage.plugins]
apptools.permissions.external = apptools.permissions.external.permissions_plugin:ExternalPermissionsPlugin
""",
#install_requires = ['Aerocity==1.01'],
zip_safe=True,
namespace_packages = ['apptools',
'apptools.permissions',
'apptools.permissions.external',
],
)
However, after I did python setup.py develop. I went to python and try to import apptools.permissions.external.
Python told me:
>>> import apptools.permissions.external
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named external
So it somehow cannot find this external egg. However, if I quickly changed the name of apptools to like apptools_test and related in folders and setup.py. I actually can import apptools_test.permissions.external.
So I think there is some problems when I merge namespace apptools.permissions.external to apptools. Python somehow gets confused.
Could someone help me with this case?

apptools.permissions was architected a long time ago when it was enthought.permissions and enthought was a namespace package. We have long since stopped doing that and refactored most of ETS into separate packages (sadly, apptools is still something of a grab-bag). When we did that, it seems that no one noticed that it was (ab)using the namespace package like that. Sorry about that. We, uh, don't use it much ourselves. Take that for whatever cold comfort it brings you. :-)
The only places it does this kind of indirection is in _*_default() methods, so you should be able to just assign your own instances for these traits. I'm not really sure why the namespace extension mechanism was attempted at all.

Related

RDKit drawing problem: fingerprint graph didn't show up using Draw.DrawRDKitBit command

I simply copied and pasted these code from rdkit (https://www.rdkit.org/docs/GettingStartedInPython.html#generating-images-of-fingerprint-bits)
I was expecting to generate graphs.
However, I got a long string.
from rdkit import Chem
from rdkit.Chem import AllChem
from rdkit.Chem import Draw
mol = Chem.MolFromSmiles('c1ccccc1CC1CC1')
bi = {}
fp = AllChem.GetMorganFingerprintAsBitVect(mol, radius=2, bitInfo=bi)
mfp2_svg = Draw.DrawMorganBit(mol, 872, bi)
rdkbi = {}
rdkfp = Chem.RDKFingerprint(mol, maxPath=5, bitInfo=rdkbi)
rdk_svg = Draw.DrawRDKitBit(mol, 1553, rdkbi)
Does anyone know how to solve this problem?
Thanks a lot in advanced.
I am now using python 3.6 and latest rdkit version (2018.09.1.0) on Windows
To see depiction in IPython or Jupyter notebooks just add
from rdkit.Chem.Draw import IPythonConsole
The RDKit 'GettingStarted' did not use Ipython for the sample scripts, so the import of the IPythonConsole is never declared, allthough it is not new.
Look in the RDKit Blog or search for notebooks the web and you see it is a standard.

Mock import of ctypes fails with unsupported operand on Read The Docs

I have small Windows module that relies on the ctypes core module. On the project RTD site the page for the module comes up empty. Looking at the latest almost successful build log https://readthedocs.org/builds/apt/2900858/ there is a failure during make html stage.
File "/var/build/user_builds/apt/checkouts/latest/knownpaths.py", line 5, in <module>
from ctypes import windll, wintypes
File "/usr/lib/python2.7/ctypes/wintypes.py", line 23, in <module>
class VARIANT_BOOL(_SimpleCData):
ValueError: _type_ 'v' not supported
Following the FAQ entry https://read-the-docs.readthedocs.org/en/latest/faq.html#i-get-import-errors-on-libraries-that-depend-on-c-modules I tried to fake import ctypes using mock, but doing so cause the build to fail completely. From what I can tell, but I'm no means an expert in this area, it's because mock itself is missing some math functions:
File "/var/build/user_builds/apt/checkouts/latest/knownpaths.py", line 13, in GUID
("Data4", wintypes.BYTE * 8)
TypeError: unsupported operand type(s) for *: 'Mock' and 'int'
Research on the error leads to only 3 search hits, the most relevant about Mock missing (at least) a true division operator: https://mail.python.org/pipermail/python-bugs-list/2014-March/235709.html
Am I following the right path? Can ctypes be used in a project on RTD and I just need to persevere, or do I need to give up and just use sphinx from my local machine?
Here is the current mock block from my conf.py:
try:
#py3 import
from unittest.mock import MagicMock
except ImportError:
#py27 import
from mock import Mock as MagicMock
class Mock(MagicMock):
#classmethod
def __getattr__(cls, name):
return Mock()
MOCK_MODULES = ['ctypes']
sys.modules.update((mod_name, Mock()) for mod_name in MOCK_MODULES)
// this is a cross post from https://github.com/rtfd/readthedocs.org/issues/1342. Zero responses after a week so am looking farther afield. //
Initially I thought it was ctypes itself that needed to be mocked, but
it turns out I needed to work closer to home and mock the module which
calls ctypes, not ctypes itself.
- MOCK_MODULES = ['ctypes']
+ MOCK_MODULES = ['knownpaths']
Thank you to #Dunes, whose comment I thought was off-track and not going to help. However it gave just enough of a turning to my mind and path of investigation to land me in the right place after all. Not all teachings look like teaching when they first grace one's attention. ;-)

Is there a way to access python code from third party kodi/xbmc plugins in your plugin?

I have experience with python, but I just got started learning how to develop addons for Kodi. Having a bit of trouble understanding the docs.
Is it possible to import or otherwise access python code from another plugin or script?
For example if my addon was: script.hello.world and i wanted to use some_method from plugin.video.someplugin.
addon.xml imports the plugin i wish to access:
<requires>
<import addon="xbmc.python" version="2.14.0"/>
<import addon="plugin.video.plexbmc" version="3.4.5" optional="true"/>
</requires>
I was fairly sure this would not work, and i was correct:
from plugin.video.someplugin.default import some_method
The only thing in the docs that looked like it might work was this:
spi = xbmcaddon.Addon ('plugin.video.someplugin')
I can access the xbmc's built in methods of spi, but no way to get to the actual python objects.
Got it! Simply add the desired directory to the system's python path:
spi = xbmcaddon.Addon ('plugin.video.someplugin')
path = spi.getAddonInfo('path')
sys.path.append (xbmc.translatePath( os.path.join( path) ))
from default import some_method
some_method()

Changes to django-appengine-toolkit for Windows

I want to use django-appengine-toolkit to provide symlinks needed by Appengine to include dependencies in the production runtime environment as discussed here. Unfortunately, I ran into an "AttributeError: 'module' object has no attribute 'symlink' " problem. A bit of research took me to this solution for apptrace, which indicated it was due to running the code on Windows. Adding this change with the arguments for
kdll.CreateSymbolicLinkA(srcname, dstname, 0)
changed to
kdll.CreateSymbolicLinkA(path, dest, 0)
at _utils.py at line 62 (as shown here) fixed the AttributeError and allowed the code to complete and autogenerate appengine_config.py with the necessary sys.path information.
Unfortunately, the dependencies were not populated under the 'libs' directory and I fear that my Python skills failed me at that point.
Can anyone identify what further code changes are needed to populate the dependencies?
since I really needed this ASAP, I ended up modifying the _utils.py file on appengine_toolkit:
def make_simlinks(dest_dir, paths_list):
"""
TODO docstrings
"""
for path in paths_list:
dest = os.path.join(dest_dir, os.path.split(path)[-1])
if os.path.exists(dest):
if os.path.islink(dest):
os.remove(dest)
else:
sys.stderr.write('A file or dir named {} already exists, skipping...\n'.format(dest))
continue
try:
os.symlink(path, dest)
except:
import shutil
sys.stdout.write('Couldn\'t create symlink copying files instead ...\n')
shutil.copytree(path, dest)
Basically if symlinking fails, I just copy everything. Not the cleanest hack but it works

Boost::Python: embed and load Boost::Python modules and converters

This might be a trivial one, but I kind of stuck here.
I have the following setup:
entity.cpp/.hpp: containing my Entity class definition and implementation.
entity_wrap.cpp: my boost python wrapper file which I compile to entity.so
entity_test.cpp: a test file
What I'd like to do in entity_test.cpp is the following:
Py_SetProgramName(argv[0]);
Py_Initialize();
...
Entity* entity = new Entity;
globals["entity"] = entity;
I now get the following exception:
TypeError: No to_python (by-value) converter found for C++ type: Entity
Which is obvious since I do not load the conversion definition of my types. I now tried to load the entity.so with globals["entity_module"] = import("entity"); but I ran into this exception:
ImportError: No module named entity
I can load the module from a python shell as expected.
My question now is: how do I load the converters defined in entity_wrap.cpp?
Solution
As eudoxos stated, I have to ensure that the module I want to load is in the sys.path:
globals["sys"] = import("sys");
exec("sys.path.append('/path/to/my/module')\n"
"import entity", globals);
It now works like a charm. Apparently just using Py_SetProgramName(argv[0]); was not enough.
With boost::python::import; watch for sys.path though so that your module is found, you might want to add a call to
PyRun_SimpleString("import sys; sys.path.append('.');")
first. Well, you can do the import via PyRun_SimpleString as well then :-)
Another option: write the entity_test itself in python.