Python module refactor

[ferrouswheel]

We have the contents of the opencog python package split across repos. This is somewhat unusual.

I propose (one day in the indeterminate future) that the atomspace library be placed in a atomspace package and the cython bindings in this repo should be placed under opencog, etc.

The problem is that if python discovers the root package opencog in one location, it won't look elsewhere. It looks like we have some code to try to mess with the sys.path in our code, but this likely would just create more confusion due to normal python environment settings being mutated outside of the user's control.

I also wonder if this is why, in various python scripts, we have a whole lot of other relative imports along with PYTHONPATH changes to somehow get around the "first location found to have a package is the returned one, and all others are masked out".

An alternative is to not install the atomspace python modules with make install, but for opencog to take responsibility for the root opencog package. Copying the atomspace modules from the atomspace's build environment into opencog.atomspace and building the final package opencog (that is optionally installed with make install).

I'm less sure about the atom type system fitted into this, it's still fuzzy in my head as to how that would fit in this proposal.

[linas]

The best long-term solution would be to have an atomspace package, independent of the opencog package.

Most of the code in the atomspace repo is mature, tested, debugged, maintained, clean, has fairly low software-debt. It works, its stable, its reliable (yeah, there are trouble areas too, but overall its in good condition).

Much of the code in the opencog repo is the opposite of this: its a dumping ground of abandoned subsystems that no one uses, no one maintains, no one cares about. with several notable exceptions. (for example, ghost, and some of the stuff in the nlp directories, and pln. and openpsi are maintained).

The issue #3391 is meant to deal with this. The meta-issue is that its just hard to maintain the grab-bag of stuff in the opencog repo, and, to add insult to injury, its just wasted effort if no one actually cares about whether the decaying parts work or not.

[linas]

fyi @noskill @vsbogd

[vsbogd]

I am not sure I understand description right. My understanding this issue states that Python package from opencog projects hides Python package from atomspace project after installation. @ferrouswheel am I right?

Right now atomspace contains Python Atomese API. Not sure what does opencog repo contains. According to README.md most part of the code is some experiments with Atomspace on Python.
It is logical to have Atomese Python API in atomspace projects. So I would vote for resolving conflict which leads to the issue but NOT for moving all code on Python into separate repo.