hyperon-experimental: Dockerfile is broken : extend-py! doesn't work . REPL cannot be compiled.

Dockerfile is broken. There are at least two critical issues:

extend-py! is completely broken

In order to reproduce. Create a new directory. In this directory create a binding for (random) from https://github.com/trueagi-io/hyperon-experimental/issues/553 and try to run the following metta script

!(extend-py! random_binding)
; random will be executed, a1 is associated with the result
!(bind! a1 (random))

It will fail with the following error:

[(Error (extend-py! random_binding) Exception caught:
RuntimeError: Failed to load module random_binding; could not locate file: random_binding/__init__.py

At:
  /home/user/hyperon-experimental/python/hyperon/runner.py(164): load_py_module_from_mod_or_file
  /home/user/hyperon-experimental/python/hyperon/runner.py(78): <lambda>
  /home/user/hyperon-experimental/python/hyperon/atoms.py(327): execute
  /home/user/hyperon-experimental/python/hyperon/atoms.py(174): _priv_call_execute_on_grounded_atom
  /home/user/hyperon-experimental/python/hyperon/runner.py(196): run
  /home/user/hyperon-experimental/python/hyperon/runner.py(188): import_file
  /home/user/hyperon-experimental/python/hyperon/metta.py(32): main
  /home/user/.local/bin/metta(8): <module>
)]

Compilation of REPL fails

cargo build in repl directory returns the following error:

Updating crates.io index
Updating git repository `https://github.com/kkawakam/rustyline`
error: failed to select a version for the requirement `rustyline = "^12.0.0"`
candidate versions found which didn't match: 13.0.0
location searched: Git repository https://github.com/kkawakam/rustyline
required by package `metta-repl v0.1.0 (/home/user/hyperon-experimental/repl)`

About this issue

Original URL
State: closed
Created 5 months ago
Comments: 19 (2 by maintainers)

Most upvoted comments

It wouldn’t be a hotfix as the new module system will not use extend-py, so people will still have to fix their scripts. No one asked for rolling back the behavior with loading .py files without extension which are not in PYTHONPATH

Necr0x0Der on Feb 9, 2024

Hm for me it was not a Docker issue, I ran on Mac OS Ventura and on Ubuntu 22 LTS, both showed this new issue.

One source of the issue may be the fact that different Python packages uses different sys.path values. At least I faced this difference even between Ubuntu and Debian distributions.

vsbogd on Feb 2, 2024

I would prefer the current solution with .py assuming it will also work in the future. The reason why I like it is that it is explicit about that a single Python file is imported, while when .py is missing we could generally use that to indicate a folder / module that is imported.

patham9 on Feb 1, 2024