search

trueagi-io / hyperon-experimental

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

Python package version is determined incorrectly in repository forks as "0.1.devX+Y" #662

Closed vsbogd closed 7 months ago

vsbogd commented 7 months ago

Describe the bug

cargo run metta fails to start claiming Python hyperon package version is incorrect when being started from a local repo created from a fork of the main repository.

To Reproduce Steps to reproduce the behavior:

  1. Create a fork of trueagi-io/hyperon-experimental on GitHub
  2. Clone fork locally git clone <your-fork-uri>
  3. cd <you-fork-local-dir>
  4. git tag should show empty list of tags (if the fork has no tags)
  5. Build app using "Manual installation" instruction in README.md
  6. Install Python package from the root directory of the local repo using python3 -m pip install ./python[dev]
  7. Run python -c "import hyperon; print(hyperon.__version__)"
  8. Run cargo run

Expected behavior import hyperon; print(hyperon.__version__) prints last version of the Python package for example 0.1.8.dev50+g1d41ab11.d20240412. cargo run starts REPL.

Actual behavior import hyperon; print(hyperon.__version__) prints v0.1 version like 0.1.dev2411+g65e26e9. cargo run fails with a message "Fatal Error: MeTTa repl requires HyperonPy version matching '>=0.1.0, <0.2.0'. Found version: '0.1.dev2411+g65e26e9'"

vsbogd commented 7 months ago

Root cause is that dynamic version logic defined in pyproject.toml: https://github.com/trueagi-io/hyperon-experimental/blob/07021cb73d1fbaba19a41c98599a981a644177ab/python/pyproject.toml#L22 uses tags to find out what was the latest release of the package. If in a fork repo no tags are present then current version is determined as 0.1 which causes incorrect behavior of the REPL.

vsbogd commented 7 months ago

We already have the fallback version in hyperon/__init__.py: https://github.com/trueagi-io/hyperon-experimental/blob/07021cb73d1fbaba19a41c98599a981a644177ab/python/hyperon/__init__.py#L15 Because some users doesn't use pip install at all and we still need to return a proper version. See discussions in #434 and #440.

Thus I would suggest adding the single place where current "base" version of the Python package would be defined. And then derive any "specific" version using local git commit or anything else.

vsbogd commented 7 months ago

Three use-cases need to be supported:

In all three cases version should be based on a current package version (0.1.8 for instance). For debug purposes it would be nice to include the latest git commit into a version (0.1.8+<git commit> for instance).

vsbogd commented 7 months ago

Another important use-case:

vsbogd commented 7 months ago

Fixed by #667