On 9/30/24 17:43, Adam Williamson wrote:
On Mon, 2024-09-30 at 12:56 -0400, Daniel Walsh wrote:
Honestly I feel like I would've written this so the bit that runs in
the container is just a different thing from the bit that runs outside
of the container? But I guess that's getting rather beyond the scope of
"package the thing that exists". :D
Yup. Not sure it is the best and does complicate development.
BTW I opened https://github.com/containers/ramalama/pull/209 for the
pyproject.toml file.
So I thought about this a bit and had two ideas:
1) Have ramalama always do most of its work outside of any container,
and when used in container-y mode, only do 'real stuff' in the
container. As what ramalama ultimately *does* in the end is dispatch
shell commands (unless I missed anything else it does?), this would
mean having all the business logic happen on the host, but once it's
actually constructed a shell command to run that will "do real stuff",
it would run it inside the container. There would not need to be a copy
of *ramalama per se* inside the container. In non-container mode of
course it would just run the command directly.
2) Make the main meat of ramalama a script called rl-direct, or
whatever, which does all the actual work, and always does it "directly"
with no container involved. Then have an optional wrap-it-in-a-
container script (which can still be called 'ramalama') which, when
invoked, does the "create a container then run something inside the
container with all the same args" thing. The thing it runs would be rl-
direct inside the container. The container image would have a copy of
rl-direct baked in at build time. For packaging, we would have a
package with the library and the 'direct' script in it (for use
directly on the host system) and a package with just the wrap-it-in-a-
container script (for containerized use). The wrap-it-in-a-container
script could have a --no-container arg (or whatever it is) that would
cause it to just run rl-direct (assuming it was there) and pass its
args through. The wrap-it-in-a-container script would not need to
maintain perfect parity with the rl-direct script - all the wrapper
script needs to know about is the business of setting up a container
and executing a thing inside the container. All arg evaluation and so
on would happen in rl-direct.
What do you think of those options? If either sounds interesting I can
try and carve out some time to work on one.
Yes we could just do the run and serve commands from within the
container. Will take a look at this.
Anyways I did a lot of work and have not gotten RamaLama packaged for
PyPi, so people can now do
`pip install ramalama` to try it out. Cleaned up the rpm spec file as well.
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
