-
Notifications
You must be signed in to change notification settings - Fork 725
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python module refactor #3522
Comments
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. |
I am not sure I understand description right. My understanding this issue states that Python package from Right now |
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 underopencog
, 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 thesys.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 intoopencog.atomspace
and building the final packageopencog
(that is optionally installed withmake 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.
The text was updated successfully, but these errors were encountered: