Github Action fails (see #269)

[NicoRobertIn]

Describe the bug Github Action workflow fails systematically during the pyLODE installation process

To Reproduce Just trigger the Gihub Action integration workflow. The sanity of the project does not matter.

Expected behavior Starting from a sane project state, the workflow should execute properly

Screenshots See Action #269 for more details

Additional context

The installation process looks like as follows:

1. The GithubAction workflow described in .github/workflows/deploy.yml begins
2. During this process the requirements in .acimov/requirements.txt are installed
3. The requirements of pyLODE dependencies are then installed
4. This requirements end with the installation of pylode@git+https://github.com/HyperAgents/pyLODE@skos_tags
5. In the tag skos_tags, the setup.py file begins with imports, and one of these involves importing an element of the library that is being installed
6. This import lauches a execution cascade of the init.py files in the library hierarchy
7. This cascade ends up with imports of libraries that are supposed to be dependencies of the one that is being installed
8. We finally have the No module named 'markdown' error

@maximelefrancois86 wondered why this error is here since the dependencies are mentioned in .acimov/requirements.txt

My point is even if it can be intriguing, the problem is elsewhere: we have 2 problems:

• This should not be hmas Github Action's responsibility to install pyLODE's dependencies. It should be up to pyLODE to install what it needs during its own setup() invocation
• The installation process should not import the library that is being installed

The solutions that we could adopt:

• About the 1st problem
  • We should remove the "pip install -r .acimov/requirements.txt" part in .github/workflows/deploy.yml and keep the pyLODE installation part
  • We should also remove the file .acimov/requirements.txt itself, since it would not be used anymore
  • Then we just can rely on the install_requires argument in the pyLODE setup to let it install the dependencies it needs
• About the 2nd one, we have several options
  • Bring the version.py at the project root, remove the mention to version.py in init.py (main subfolder), and change the import in setup.py accordingly. If this file is in the pyLODE folder it will import the library we want to install, and also trigger the init.py execution cascade and try to import the dependencies. The package manager is the one responsible of knowing the package version and the version is not used anywhere in the projet. This is in my opinion the best option.
  • Use the poetry files we have in the master branch... But this implies relying on poetry
  • Use a open() invocation to fetch the file in the directory. It allows to workaround the init file but this is really brutal and rude though

What are your thoughts about it?

[FabienGandon]

@NicoRobertIn is this issue still a problem or was it fixed?

[NicoRobertIn]

The deploy.yml action seems to have been re executed successfully 2 weeks ago here: https://github.com/HyperAgents/hmas/actions/runs/6849799887

The problem was that pyLODE was importing its own dependencies before installing them In the current version of the workflow we can see 2 things:

• The workflow installs the requirements.txt dependencies in one command and then pyLODE in another
• The requirements.txt file does not include pyLODE anymore

That was the solution proposed by @maximelefrancois86 to solve the problem without changing the library architecture too much We could eventually prefer the library to install its own dependencies before installing itself, but for now it solves the problem

[maximelefrancois86]

As discussed, this is not the cleanest solution, but it solved the issues in the workflow (up to last week 😉https://github.com/HyperAgents/hmas/actions/runs/6947694791 )

Ultimately, we may merge the latest version of pyLODE v3 to our fork. I bet they have fixed this issue for us.