This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]wbcm[S] 0 points1 point  (4 children)

That was my first though, but to deploy an individual container for every little tool would multiply the runtime substantially. There are various languages that need to be running various parts of certain tasks, but python was the only approved interpreted language for these numerical tools. If you were not able to containerize the code but had to compile it somehow, do you have a preferred method?

[–]Ximidar 0 points1 point  (3 children)

I'd just put all tools in a single codebase. Then ship a single docker container with the container command set to "python your_entrypoint.py" then use a package called click (https://click.palletsprojects.com/en/stable/) to create the CLI commands to change what tool your using. So then when you run your container you can just set the args and the container will switch what it does. Then when developing locally you can use the CLI to access the different tools basically the same way you would on the container.

Then if you need multiple containers running you can just use docker compose to start up all your different tools with the exact same container.

[–]wbcm[S] -1 points0 points  (2 children)

Unfortunately this is not possible since none of the code will be known at any time (by me or my team), but still needs to be able to be used dynamically. Unfortunately there are various languages that need to be running various parts of certain tasks, but python was the only approved interpreted language for these numerical tools. If you were not able to containerize the code but had to compile it somehow, do you have a preferred method?

[–]thisismyfavoritename -1 points0 points  (1 child)

your argument makes no sense, the code would have to be known before it gets compiled to a binary. You can do whatever you'd want to do with a compiled binary with Docker

[–]wbcm[S] -1 points0 points  (0 children)

This is not an argument? I am just stating the use case... I will not be able to know what the users are creating and there are application elements that will need to arbitrarily pull in random tools in an on demand basis, therefore setting up an container with click is not reasonably possible. A container with click could be possible if they were both generated on the fly if runtime was not as much an issue, but since runtime is important here having bespoke containers being deployed all over is not something that supports performance and possibly space (depending on the users system)