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. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx https://www.happyassassin.net -- _______________________________________________ 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
