search

cms-gem-daq-project / gem-plotting-tools

Repository for GEM commissioning plotting tools
GNU General Public License v3.0
1 stars 26 forks source link

remove slc6 template from travis builds #166

Closed jsturdy closed 6 years ago

jsturdy commented 6 years ago

Description

due to some introduced backwards incompatibilities, remove slc6 templates from default travis run

jsturdy commented 6 years ago

@lmoureaux, do you know where this is coming in from (it's affecting all builds, not just slc6):

Could not import extension sphinx.ext.pngmath (exception: No module named pngmath)

Local building doesn't complain, so some difference exists between docker image (pulling in reqs from package) and development machines. Quick comparison shows: gem904daq02

Running Sphinx v1.1.3

docker

Running Sphinx v1.8.1
lmoureaux commented 6 years ago

pngmath was giving a deprecation warning before, so probably they removed it from the pip packages. The local version must be older and still have it.

The warning was saying that one should use imgmath instead.

I can see three options on top of my head:

jsturdy commented 6 years ago

For building (build-requires), I don't have a strong preference (we don't need the build version to be installed anywhere), as it won't be an installation dependency of either the pip package, nor the RPM package. vfatqc-python-scripts works with whatever the build script requests, but perhaps whatever is using this functionality doesn't exist there? What in the documentation is using this feature? I can make either change in this PR, but it doesn't actually seem used explicitly?

fgrep pngmath -r . --exclude-dir=rpm --exclude-dir=.git
./doc/conf.py:    'sphinx.ext.pngmath',
Binary file ./doc/_build/doctrees/environment.pickle matches
lmoureaux commented 6 years ago

What in the documentation is using this feature?

Try grepping for .. math::

jsturdy commented 6 years ago

Adding the restriction to requirements-dev helps, but I'd like a better (cleaner) long-term solution, as this dependency is only required for building the docs, not for using the package. Using something like the BuildRequires field in the RPM spec file (exposed in setuptools with the bdist_rpm.build_requires field) might be an option, but then again, maybe just tracking build requirements in requirements-dev (possibly renamed to requirements-build) and then pulling these into the build_requires field would be a better solution.

lmoureaux commented 6 years ago

requirements-dev is kind of a standard in the Python community, see eg here. Pulling the requirements into BuildRequires looks like the cleanest solution to me.