Closed MehmedGIT closed 2 years ago
kba
commented
2 years ago Gotcha, as I said, I was only curious because once we leave Python 3.6 behind, we can change the setup to use pytproject.toml in most projects. But that is not time-essential.
I don't know why a pull request was created here, I think it is automatically because we merged a branch.
Always a good idea to create PR to have discussions like this.
MehmedGIT
commented
2 years ago In order to merge from the website interface I had to create a PR. That's the reason for the PR.
I have pushed a setup.py and removed the setup.cfg and pyproject.toml in the refactoring branch. I also cleaned the requirements_3.7.txt. Seems I am able to reuse the routers in Operandi without issues. The only problem is the DB which i have to start manually but this is easily fixable once we clearly separate the local install from docker. Ideally, the local install should not depend on anything based on docker. The dockerized version of the WebAPI can then just reuse the locally available configurations and source code and builded over the ocrd-all image.
joschrew
commented
2 years ago My thoughts: You focus on python3.7 but currently I need python3.6 to run the webapi standalone because it has to extend ocrd-all. Maybe I should change that because in the near future ocrd-all should run with python3.7 as well. And for the meantime I could try to build a ocrd-all with python3.7 by myself. I was not able to use pyproject.toml with python3.6, but I think it should works with python3.7. I think we should try that because I think pyproject.toml is the way to go nowadays. Additionally the tests currently need he pyproject.toml because the variables are set there.
MehmedGIT
commented
2 years ago As it is now we have no python version restrictions with the provided setup.py although it still reads the requirements from the requirements_3.7.txt. I am running Python 3.8 inside the Operandi environment.
On the pyproject.toml part, I agree that we should switch to that. But I need to dig more into that topic to make it work properly. For now, I have temporarily removed the pyproject.toml and setup.cfg and installing the ocrd_webapi package just with setup.py.
The main idea is that other implementation projects should be able to install the ocrd_webapi package with as less dependencies as possible without breaking their environment.
For the standalone WebAPI, yes, currently seems there is no other way than sticking to a specific Python version.
I don't know why a pull request was created here, I think it is automatically because we merged a branch. At first I used pyproject.toml just for the tests to set env's and some stuff and for flake8. Later I wanted to use it for packaging, but realized this does not work with python3.6 so I created a setup.cfg. I don't know if it works with or without pyproject.toml but I keep that for tests. I don't really understand how this should work I just created an example project on my machine and modified the setup.cfg from ocrd-webapi-implementation until I was able to use the ocrd-webapi-implementation as a library. So there is no specific intention behind anything i did here just to make it work to import it as a library.