Closed duncanmmacleod closed 5 years ago
Duncan, sure, I would be happy to include a setup.py from you in a PR.
Ok great, the one thing I'm not sure about is the importance/use-case for the cigetcert.sh
script that calls python -E cigetcert
, can you explain why that is required, and one can't/shouldn't just call the python code directly?
I ask mainly because I would naively edit the spec file to use the setup.py
as well, but don't want to rip out the shell script wrapper simply because I don't understand it.
That is intended for environments where there may be mixed python versions. Some experiments set up default LD_LIBRARY_PATH and PYTHONPATH variables for their own application's use, and we didn't want them interfering with the operation of cigetcert (the -E ignores PYTHONPATH). That version of the wrapper script is for rpm, because there we want to use the default settings to use the system libraries and system python. We have another installation using our local packaging tools and there we have a different shell wrapper script pointing LD_LIBRARY_PATH to a directory with all the libraries cigetcert needs and PYTHONPATH pointing to a specific version of PYTHON we know works with it. It's all mostly because of the mess that has evolved over time with incompatibility of python versions.
Ok, in that case I'll just leave the spec file as it is when proposing a setup.py
build.
I think it would be nice to have built-in python packaging for
cigetcert
, to trivialise distribution and installation of this (excellent) utility. I think it would just amount to a simplesetup.py
file that can then be used to build wheels and tarballs that can be used in turn to built rpms and other binary packages.I'm happy to put the (small amount of) work in to get it going, and to post it in a pull request, if the maintainers are open to it.