Devpod dependency, yay or nay? #234
Replies: 1 comment
-
|
Just adding some more information to the mix. Indeed loft-sh seems to have abandoned, or at least put devpod into maintenance mode, but a promising fork exists, done by skevetter, that is activly developed and right now in the process of a re-branding. So if this project wants to stick to devpod, maybe taking a look at skevetters fork is an option. Another, possible solution could be to look at Crib. I have not tested it myself, but it popped up in some discussion somewhere as an alternative. Maybe in the best of worlds, the underlying "engine" could be swappable, but I do understand that this approach might be to unwieldly to manage. No answers from me, just posting some alternative that could be considered :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
loft-sh/devpod#1963
Reading through ^^^ my understanding is that devpod itself is not under active development / support.
There's a community fork, linked in one of the issues.
Question: is devpod the correct choice as a dependency for this project?
Anecdotally, I've had issues with devpod since forever, random cli output, broken commands in this plugin due to version differences, control sequences as part of json output, no support on arm64 linux (which i raised on the community fork yesterday as a potential build target).
I've no real horse in this race... I don't code enough for my opinion to count. But I've hit enough devpod related issues spinning up devcontainers and trying to have a smooth experience that I think the points worth considering.
Yay devpod. Boo bugs.
Disclaimer, I'm on Asahi Linux on apple m1 silicon... I am sure that I encounter a disproportionately high number of problems day to day compared to someone on x86 linux or windows/ macos. Stil, a boy can dream of a world where his toys work.
Beta Was this translation helpful? Give feedback.
All reactions