On 2021-10-26 17:32:46 +0800 (+0800), Boxiang Zhu wrote: [...]
## reorganize to one Python package per Git repository Now skyline-apiserver has divided the source code into six sections: - skyline-apiserver: core source code of skyline apiserver - skyline-config: config library with yaml to parse config file - skyline-console: git submodule of skyline-console - skyline-log: log library with loguru - skyline-nginx: generate the nginx.conf file with openstack environment - skyline-policy-manager: generate policy yaml file Generally, we just focus on skyline-apiserver.
Each of these will need to be in a separate Git repository, rather than packaging them from a single skyline-apiserver Git repository.
## stop using Git's submodule feature Is there any reason why we should stop using git's submodule?
The distinct Git repositories should be more loosely coupled so that you can rely on OpenDev's CI system (Zuul) to use cross-project change dependencies correctly.
## use Python package configuration and tooling consistent with existing OpenStack projects Now skyline-apiserver use yaml to parse config and poetry to manage dependency.
OpenStack does not use poetry, currently PBR and SetupTools are used for packaging other OpenStack deliverables.
## call Python entrypoints directly from tox instead of using tox as a wrapper around make Scripts[0] get converted to console_scripts entry points, plugins[1] would allow for arbitrary entry points.
I understand, but this is inconsistent with how other OpenStack deliverables and developed and tested.
## constrain Python dependencies and test dependencies in tox configuration (pip -c) Yet, there is no constraints like pip -c in poetry. Find some discussion about this in poetry. But all are closed, not merged. https://github.com/python-poetry/poetry/pull/4005 https://github.com/python-poetry/poetry-core/pull/172
Yes, stop using poetry.
## track Python dependencies and test dependencies in requirements files Now we track python depentdencies and test dependencies in poetry's tool.poetry.dependencies and tool.poetry.dev-dependencies
I feel like I'm a broken record here, but stop using poetry and you will be able to do these things the way they're done in OpenStack.
## get Python package versions from Git tags rather than hard-coded in configuration files Sure, but hard-coded package version is not serious problem.
Using PBR and SetupTools will solve that for you automatically, and will be compatible with OpenStack's release automation.
## rely more on Oslo libraries (currently only oslo.policy is used) Reuse wherever possible. oslo.policy is used to generate the policy yaml for skyline to use. [...]
Yes, but does Skyline have configuration? Does it perform any logging? Does it use any databases? There are Oslo libraries for handling tasks common to many OpenStack services so that all services can do them in a consistent fashion and fixes only need to be applied in one place to address them for all of OpenStack. -- Jeremy Stanley