fix: container now copies managed python into runtime

[coretl]

Fixes #294

[coretl]

Test error will be fixed by #296

[gilesknap]

I have tested this against
https://github.com/DiamondLightSource/fastcs-example/tree/dev-in-cluster

All is working great and I can deploy the runtime container to the cluster like so:
https://github.com/DiamondLightSource/fastcs-example/tree/dev-in-cluster

HOWEVER: the debug container fails to start in cluster with:

bash: line 1: fastcs-example: command not found

Which is because this line in the runtime is not applied to the debug target:

PATH=/app/.venv/bin:$PATH

[gilesknap]

I believe we just need to add this to the build stage:

PATH=/app/.venv/bin:$PATH

trying it in fastcs-example.

[gilesknap]

Adding the Path in the debug phase does fix the issue. It also repeats the same line but I figure that is required as the two stages have differing base images.

[gilesknap]

Another question. I have put sdtio-socket in fastcs-example dependencies and set the args as below:

ioc-instance:
  image: ghcr.io/diamondlightsource/fastcs-example-debug:2025.10.1
  args:
    - stdio-socket --ptty "fastcs-example run /epics/ioc/config/controller.yaml"

This gives us ability to connect to the console from a shell in the container. The dependency could go in the copier template and be available to all. Do we want that?

[gilesknap]

I have seen a non-critical problem which is that when you use the debug container and you are not root you don't get all the nice .inputrc etc. because you can't read the /root folder.

I've been changing the HOME variable to /tmp so ipython has a place to write its files. I thought that was why I was not seeing the friendly shell but it turns out I cant see it even with HOME=/root. It would be nice to have a solution that gives writable dot files and nice bash config.

The simplest answer is to make the /root folder writeable by all at build time. I feel that is mildly dangerous though.

Maybe the best way to handle this is to not support fancy bashrc in cluster. You have console which gets you into a nice interactive python session anyway.

[gilesknap]

It looks like the README is out of date, still mentioning pip et al. I have not checked the docs yet.

[coretl]

Another question. I have put sdtio-socket in fastcs-example dependencies and set the args as below:

ioc-instance:
  image: ghcr.io/diamondlightsource/fastcs-example-debug:2025.10.1
  args:
    - stdio-socket --ptty "fastcs-example run /epics/ioc/config/controller.yaml"

This gives us ability to connect to the console from a shell in the container. The dependency could go in the copier template and be available to all. Do we want that?

I think this is probably too specific to go in the copier template, best to leave it in the FastCS modules

[coretl]

It looks like the README is out of date, still mentioning pip et al. I have not checked the docs yet.

Fixed

[gilesknap]

looks good

[coretl]

I have seen a non-critical problem which is that when you use the debug container and you are not root you don't get all the nice .inputrc etc. because you can't read the /root folder.

I've been changing the HOME variable to /tmp so ipython has a place to write its files. I thought that was why I was not seeing the friendly shell but it turns out I cant see it even with HOME=/root. It would be nice to have a solution that gives writable dot files and nice bash config.

The simplest answer is to make the /root folder writeable by all at build time. I feel that is mildly dangerous though.

Maybe the best way to handle this is to not support fancy bashrc in cluster. You have console which gets you into a nice interactive python session anyway.

We could make it writable to all just for the debug container? That should be reasonably safe...