I didn't look at it thoroughly, but it looks really cool and I'll probably give it a proper try at some point. Judging by your comment only...
> watches your repository for new commits and continuously builds the environment
That feels wrong to me. For example, what happens if I want to check out a 1 year old commit and edit it? Will the dev environment that was used at the time be available or will it be rebuilt? If it gets rebuilt, there's no way I get any guarantees it's going to work.
IMHO most of the industry is getting it wrong when it comes to dev environments and build systems. I've always called it butterfly effect builds. You make a commit and it triggers a ton of non-repeatable builds. There's not much value in doing that for every commit IMO. What happens when something like an APT mirror fails and the whole system grinds to a halt? What happens when a runtime or dependency gets updated and breaks at exactly the worst time during the week?
I'd rather see something on a (calendar) schedule with the potential to trigger a manual build if needed. For example, skim this [1] article. That's always made sense to me and, in the context of a dev environment, why not build the base dev environment once a week (or day) and only layer in the resources / code on-demand? IE: Build the things I don't control on a calendar schedule and only build on-demand for changes that are part of my project (using the base env).
The way I've always envisioned it is to have a stable env build once per month or per week. It's fast enough to keep everything rolling in terms of being current, yet slow enough that I'm not spending time wondering if a problem I'm debugging is caused by a change in my dev environment. I try to do the same thing as dedicated build containers for projects, but it's hard because everything is tunnel visioned on per-commit re-builds these days.
> what happens if I want to check out a 1 year old commit and edit it?
Your dev environment is version controlled too because it lives in your repository. You would run a prebuild for that old commit and get a dev env from that time. It would only break if your old dev env can no longer be built, for example if it depended on some external resource which is no longer available on the internet.
> I'd rather see something on a (calendar) schedule with the potential to trigger a manual build if needed.
That's actually on our todo list, but it didn't make it into the 0.1 release. This feature is especially useful for monorepos, where rebuilding everything on every commit is too much.
> It would only break if your old dev env can no longer be built, for example if it depended on some external resource which is no longer available on the internet.
That's what I was getting at. Version controlling a config doesn't make a build deterministic when it depends on transient resources that aren't in version control.
There's nothing repeatable about a container style build. They can change between runs that are 5 seconds apart. I see a lot of Docker builds where the author claims they're repeatable because they're version controlled and then they start with 'apt-get update && apt-get upgrade'.
At least you don't claim yours repeatable, but I'd much rather build my dev environment on the first Monday of every month, check it in to an artifact repository, and use that for a full month. The re-build would be similar to (using Docker as an example):
FROM mygroup/myproject:2023.04
RUN git checkout ...
That way when I go back to a commit that's a year old I re-use the exact environment that was in use at the time, If I want an updated dev environment I create a branch and update the version of the dev environment.
From the perspective of being the developer, I'd rather specify a release cadence and have the matching dev environment used. Ex: monthly, weekly, daily, ci. IMO container like systems that are used as part of the dev / build chain should be promoted and reused, not comitted and rebuilt. The only person using a CI based build environment should be the person responsible for maintaining it. Everyone else should be on a slower cadence.
It's seems so weird to me to come to HN and see people livid about Windows auto-updates and then having no problem with their dev and build tools (potentially) change 50 times a day.
To put it another way, would you auto-update VS Code, your runtime, and your dependencies every time you commit to Git? If not, why build the auto-magical dev environment so it works like that? Maybe I'm misunderstanding what it does. Admittedly, I didn't try it out yet.
> watches your repository for new commits and continuously builds the environment
That feels wrong to me. For example, what happens if I want to check out a 1 year old commit and edit it? Will the dev environment that was used at the time be available or will it be rebuilt? If it gets rebuilt, there's no way I get any guarantees it's going to work.
IMHO most of the industry is getting it wrong when it comes to dev environments and build systems. I've always called it butterfly effect builds. You make a commit and it triggers a ton of non-repeatable builds. There's not much value in doing that for every commit IMO. What happens when something like an APT mirror fails and the whole system grinds to a halt? What happens when a runtime or dependency gets updated and breaks at exactly the worst time during the week?
I'd rather see something on a (calendar) schedule with the potential to trigger a manual build if needed. For example, skim this [1] article. That's always made sense to me and, in the context of a dev environment, why not build the base dev environment once a week (or day) and only layer in the resources / code on-demand? IE: Build the things I don't control on a calendar schedule and only build on-demand for changes that are part of my project (using the base env).
The way I've always envisioned it is to have a stable env build once per month or per week. It's fast enough to keep everything rolling in terms of being current, yet slow enough that I'm not spending time wondering if a problem I'm debugging is caused by a change in my dev environment. I try to do the same thing as dedicated build containers for projects, but it's hard because everything is tunnel visioned on per-commit re-builds these days.
1. https://phauer.com/2019/no-fat-jar-in-docker-image/