Investigate packaging genie_python

[zsoltkebel]

This Ticket should instead be a discussion based on points raised in comments

I suggested investigating whether we could turn genie_python helper functions into a pip installable package from vcs for better maintenance and clarity.

I suggest revisiting this ticket in planning and deciding priority etc.

Work done

On branch ticket8381-package in the genie_python repository.

• ticket branch created and requirements.txt file trimmed to the package that are used by genie_python code. We had a lot of seemingly unused dependencies (pygame?), some of which were severely outdated (e.g. https://pypi.org/project/ipython_genutils/)
  • pygame might be used for collision avoidance on some instruments. not in genie python itself
• Note that some environment variables have to be set for the CaChannel package to install correctly through pip.

Going further

• [ ] Dependencies seemingly unused here might be necessary on instruments, somehow separate this. Idially we don't want genie_python to list any dependency that it doesn't use directly.
• [ ] Do we need caRepeater.exe in our Python installation directory? One of the install steps is moving this into there. We already have one at EPICS dir. do we need both? Could not find usage of it within genie_python code.
• [ ] Perhaps separate the python install from genie_python helper functions (package)

discussed ~1:21 20/60/24/

[FreddieAkeroyd]

Should we consider splitting some parts of genie python that are server specific and/or shared into separate packages e.g. i think we have things like CaChannel wrappers that may be common to both client and server, but scripting stuff is not needed by inst_servers, which could run in their own virtual environment separate from genie python

[FreddieAkeroyd]

regarding caRepeater, it is launched by the EPICS ca.dll which needs to find it in your PATH. As the epics site packages is not in the PATH, i think it got copied to next to python.exe so it would be found. However we now build cachannel with our own epics that i modified to add the directory where ca.dll is loaded from to the internal search path, so it would probably work without it next to python.exe now

[Tom-Willemsen]

This likely needs splitting into a series of tickets - I think this is too big to just do as one ticket.

Some likely subtasks which I think we need/want to do as part of this (in no particular order) - each of which could be a sensible ticket in itself:

• Ensure genie_python can be made public (may need some git history manipulation)
• Create an isiscomputinggroup or similar organisation in pypi
  • Or we could use a private pypi server, but for sharing with other groups I think we should prefer to put everything on pypi directly
• Decide our python version support policy
  • What we currently do: just one version, but that's not great for sharing with other groups and limits the benefit that we get from packaging genie_python
  • "Industry standard" for scientific python is SPEC00 which typically covers 3 recent python versions
  • Something else.
• Work out what to do with our customized builds - may need to build and package these ourselves, or contribute our changes upstream:
  • EPICS libraries - complexity as we use local-ish builds
  • smslib - complex build
  • ode - I think we build our own wheels currently?
  • readline - we apply a manual path currently.
• Separate library from distribution.
  • The end result of installing the distribution should look identical to currently, but
• Move to PEP621 (pyproject.toml) for genie_python
• Set up build to automatically push new releases of genie_python to pypi