search

trueagi-io / hyperon-experimental

MeTTa programming language implementation
https://metta-lang.dev
MIT License
123 stars 43 forks source link

Issue 662 solution, hyperon version refactor #667

Closed DaddyWesker closed 2 months ago

DaddyWesker commented 3 months ago

Check issue https://github.com/trueagi-io/hyperon-experimental/issues/662

Code should be simple, but I wasn't been able to test it properly. In my environment this variant works: user installs Python package pip install -e hyperon[dev] and gets the version

Also in a new environment I was able to make this variant work: user clones repo, builds code and adds ./python dir into PYTHONPATH, after that gets version using import hyperon; print(hyperon.__version__)

Variant with cibuildwheel worked for me only once and then I wasn't been able to reproduce it. Maybe it is lack of experience of using this cibuildwheel. Anyway, if someone could check cibuildwheel path and get version of hyperon properly - it will be really great.

vsbogd commented 3 months ago

  1. I am sorry I didn't mentioned another important use-case when package is installed using PyPi repo or from distribution package file. In this case user doesn't even have git installed and code in PR doesn't work in this case. Something similar in fact should happen when using cibuildwheel because it copies source code (excluding git root) and releases package from the copy.

  2. Calling git each time when package is loaded has two other issues:

    • Package can be imported from any location in the filesystem thus at least git should be called from the git repo root dir.
    • It is a bit overhead even for dev environment. I would not say it is absolutely not a way to go but I would try a solution when git is called only on the stage of the package building first. For instance current code calls git only at the build stage. Yes, we loose ability to assign a git tag to the package which is loaded via PYTHONPATH modification but: (a) we can call git as a last resort measure when version is not found (localbuild branch in current code) (b) it may not that important as it is a rare case.
    • Git can be absent on a user machine (see item (1)) thus we need to check the call for errors.

  3. Importing __version__ from hyperon in pyproject.toml also has problems. Importing hyperon on a build stage may require dependency libraries which can be unavailable at the moment of the package building (see item 6 at the link https://packaging.python.org/en/latest/guides/single-sourcing-package-version/#single-sourcing-the-version). It is more theoretical issue for our project though.

vsbogd commented 3 months ago

I would propose closing this PR or converting it into a "Draft PR" before new change is ready for review.

DaddyWesker commented 3 months ago

I've converted PR to draft.

DaddyWesker commented 2 months ago

Currently I'm testing latest changes. So probably something can be changed still.

DaddyWesker commented 2 months ago

@vsbogd everything should be fine now. Please check if you agree with those changes.