Closed sde1000 closed 4 years ago
You can run tox + travis, it was the CI in Home Assistant for a long time (currently it has moved to Azure pipelines)
I would prefer we don't split the project, it is not such a big project to start splitting.
Any other suggestions? Python packaging seems to be a bit of a minefield at the moment!
Always has been :)
You could perhaps use something like setuptools extra to declare extra dependencies.
About the debian stuff: isn't it possible to move that out of the repo and make the generation of it completely part of the CI? (I don't have any experience with debian packaging though).
Oh, yes, that looks very useful. Declare the dependencies for each driver as extras that are only required if you want to use that driver.
Debian stuff: it's complicated. The usual Debian model is that there's a separation between "upstream" packages and their Debian packaging; the packaging is itself a project, with its own maintainer, repo, etc.
For small programs like this one that haven't been included in Debian, this separation is a lot of hassle and so I just include the control files and scripts to build Debian packages in the repo.
I've been looking at making a new release (upload to pypi, and generate Debian packages) and I've run into a couple of blockers.
When I try to build the Debian packages with current debhelper, I get:
What's happening here is that debhelper is deliberately setting up the environment to prevent setuptools from fetching build or test dependencies. Furthermore, reading around the issue, I've found that
setup.py test
is deprecated: see https://github.com/pypa/setuptools/issues/1684 — the reasoning appears to be that, amongst other things, fetching and installing test requirements is out of scope for setuptools.Currently in
setup.py
we have:This works well enough for the current Travis CI integration, but is obviously going to be problematic in the future. There are a couple of things to talk about:
If I remove those three lines from
setup.py
then debhelper builds the packages without running any tests. If I adddali.tests
to thepackages
list then debhelper runs all the tests usingpython3 -m unittest discover
— which fails on the unipi driver tests which require mock and pymodbus.So what should we do? I'm not sure, but things I'm considering include:
dali.driver
, and arrange that they are not run by default bypython3 -m unittest discover
(but are run by Travis CI)Any other suggestions? Python packaging seems to be a bit of a minefield at the moment!