You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Multiple different Python images v.s. Single image with different Python versions. #265
Accout for devcontainer, I suggest to take a thought from generic to specific scenaries and from developing alpha stage to maintaining.
From generic and developing alpha stage, I sugges one (image)devcontainer developing is fine(maybe the image in the condition is also not necessary to cache becase rebuild images is easy to rebuild and switch)
focus on simple to use.
focus on generic to use.
foucs on developing alpha stage.
focus development build and switch rapidly to verify what's the possible problem in the following stages.
Actually, i think the commons sometimes maybe can not be used in production but can rapidly verify ideas and implement some simple apps such as cmdline tools, plugins, or utils and common packages.
From specific and maintaining views, I suggest multiple development images must be provieded to facilitate to construct a full function develping environment.
focus on specific binaries in images such as AI NGC images.
focus on large codebase contains multiple language develpment projects.
focus on specific permission allowed in images such as executable, avaiable network and so on.
focus on the stability of continuous delivery. This comes to important consistency needs relative development images for specific deployment.
Maybe I did not clarify my personal initial motivation to use devcontainers. Considering several scenarios:
FastAPI based application tends to be distributed via container image.
Command line application sometimes also distributed via container image.
PyTorch based development on GPU cluster needs a development image.
GitLab CI/CD also needs an development image to run CI/CD jobs.
So for me, it means more than just devcontainers, but also production image and development image. It would be great make all these happen out-of-box. And another lesson learned from my past experience is better to maintain the image within the code repo, otherwise, it will lead to extra complexicity to maintain the consistency.
Activity
msclock commentedon Jan 9, 2024
Accout for devcontainer, I suggest to take a thought from generic to specific scenaries and from developing alpha stage to maintaining.
From generic and developing alpha stage, I sugges one (image)devcontainer developing is fine(maybe the image in the condition is also not necessary to cache becase rebuild images is easy to rebuild and switch)
Actually, i think the commons sometimes maybe can not be used in production but can rapidly verify ideas and implement some simple apps such as cmdline tools, plugins, or utils and common packages.
From specific and maintaining views, I suggest multiple development images must be provieded to facilitate to construct a full function develping environment.
huxuan commentedon Jan 11, 2024
Maybe I did not clarify my personal initial motivation to use devcontainers. Considering several scenarios:
So for me, it means more than just devcontainers, but also production image and development image. It would be great make all these happen out-of-box. And another lesson learned from my past experience is better to maintain the image within the code repo, otherwise, it will lead to extra complexicity to maintain the consistency.