Earlier quoted context omitted.
Flox employee here! To start off by addressing how this relates to nix tools: - Our goal is to be more user friendly. You don't have to learn the Nix expression language or understand nix internals to be successful. - We've been able to add some opinionation and polish. Some of that is subjective, but some examples are: - We have a hybrid imperative/declarative interface. You can `flox install && flox list`, and thos…
So what you are offering here is essentially a small UX improvement over sharing a flake with a devshell in a Git repo? I'm the first to admit that nix is way too cumbersome to use, but this alone doesn't seem like enough value add.
Show HN: Flox 1.0 – Open-source dev env as code with Nix
141–150 of 201 posts
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#142Earlier quoted context omitted.
Devbox can also run services too. Both products use an awesome process runner called process-compose ( https://github.com/f1bonacc1/process-compose/ ) which is worth checking out (it's even built with nix!)
I think the ability to run services is really what separates Devbox from other related Nix-based dev-env solutions. Essentially taking what you get from the NixOS-specific configuration.nix options (like for example `services.mediawiki.enable = true`) and letting that be per-project, per-directory, is super useful.
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#143Hi Ron, congratulations on the release. My question is: how will you make money? I see you are the CEO, there is a company, and you have employees. Crunchbase links to news articles that make it seem like you've raised $24MM. Maybe I'm just missing it, but I can't see any pricing information on your landing page or in your docs. After I log in to FloxHub with my Github profile, I don't see any billing options. What i…
Oh wow. I really don't see a way to a $2.4B exit here. Good luck!
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#144There are several tools in this space now- nix is maturing and people are realizing how useful nix can be for dev envs. * [devenv](devenv.sh) - I am using it and loving it, but worried that the development is not moving forward * [devbox](https://www.jetpack.io/devbox) * [daytona](https://www.daytona.io/docs/usage/workspaces/) * [devshell](https://github.com/numtide/devshell) * [bob.build](bob.build) more focused on…
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#145The line about nix making it easier for newcomers in the readme and similar statements always trigger me. I am quite a competent person and I've never once thought "that was easy" when trying to use nix. I adore the concepts of nix, but the user experience is awful. Maybe that's what this tool solves? It takes a frustrating amount of effort and incessant config tweaking with little to no documentation and navigating…
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#146Earlier quoted context omitted.
I think you're referring to direnv as opposed to devenv.sh which does compete in the same space. Numentide was working on one too. I am using devenv.sh at work, at home I just nix develop (but this doesn't do services, but there was a flake util just announced that adds support for that I need to check out).
Why `nix develop`, not `nix shell` or `nix profile`? Because you're also packaging the final result with nix anyway or something? > nix develop starts a bash shell that provides an interactive build environment nearly identical to what Nix would use to build installable. Inside this shell, environment variables and shell functions are set up so that you can interactively and incrementally build your package. I'm not…
aiui, nix shell was the non-flake way of doing things and nix develop is for flakes (this is probably a gross over simplification!)
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#147Earlier quoted context omitted.
I think you're referring to direnv as opposed to devenv.sh which does compete in the same space. Numentide was working on one too. I am using devenv.sh at work, at home I just nix develop (but this doesn't do services, but there was a flake util just announced that adds support for that I need to check out).
> this doesn't do services, but there was a flake util just announced that adds support for that You must be referring to services-flake: https://community.flake.parts/services-flake
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#148I wonder if something like this could be used instead of conda or pixi to manage Python packages, the used-version of Python, the Python virtualenv, etc.
It can, but I wouldn't recommend it unless you have native dependencies that are just a pain to install. You'll loose Windows compatibility, may have to package some Python packages yourself, have a learning curve for everyone in the Python ecosystem and gain... what exactly?
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#149What I desperately want is the generation of a lock file so that environment installs are cryptographically guaranteed to be repeatable byte-for-byte. I recognize that this means either checksums every platform supported, but I’ve been startled that none of the options I’ve found seem to have the capacity for this.
I think you're looking for Nix flakes proper! This is one of the promises! Given so, this means many tools based on nix provide this too, though it's not as easily surfaced.
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#150Reproducible development environment, I'm very enthusiastic about it and have been using development containers for years now, at work, they do a great job too. About a year ago, I started to hear about Nix. I was super excited at first, the promise is amazing, but the onboarding process has been awful for me. I have a defined development environment I want to achieve, but it seems I always miss something in the way…
I was leading the developer products team at Facebook back then and started a project around injecting remote capabilities into local dev. Short of it was that thousands of developers were waiting 45 minutes for cold builds... Part of the initial steps for the project was to map out the entire SDLC (so we can get a sense of what parts of the toolchains we need to rebuild), that's where that video above comes into mind if you look at that whiteboard towards the end... Visualizing how complex we've made it is what got me into the headspace of - this can't actually be how we go about this.