That should be an easy fix!
Would it be simpler to just have steps 1-3? At which point flox
is /usr/bin/flox
and everything is good to go?
Thank you we appreciate the feedback!
That should be an easy fix!
Would it be simpler to just have steps 1-3? At which point flox
is /usr/bin/flox
and everything is good to go?
Thank you we appreciate the feedback!
That would be perfect, if it also creates the default environment. Just apt install and youāre good to go. Awesome!
One other idea: for people that come from nix-env, it would be awesome if the apt install flox
would take care of the nix uninstall. Right now I have this in the script to uninstall nix cleanly:
# Remove nix
if [ -e $HOME/.nix-profile/bin/nix ]; then
echo "Remove Nix multi-user"
echo "- removing Nix daemons"
systemctl stop nix-daemon.service &> /dev/null
systemctl disable nix-daemon.socket nix-daemon.service
systemctl daemon-reload
echo "- removing Nix files/folders"
rm -f /etc/systemd/system/nix-daemon.service /etc/systemd/system/nix-daemon.socket /etc/tmpfiles.d/nix-daemon.conf &> /dev/null
rm -rf /nix /etc/nix /etc/profile/nix.sh ~root/.nix-profile ~root/.nix-defexpr ~root/.nix-channels ~/.nix-profile ~/.nix-defexpr ~/.nix-channels &> /dev/null
echo "- removing Nix users"
for i in $(seq 1 32); do
userdel nixbld$i
done
echo "- removing Nix user group"
groupdel nixbld
fi
[ -e "/etc/bash.bashrc.backup-before-nix" ] && echo "- restoring bashrc pre Nix" && mv /etc/bash.bashrc.backup-before-nix /etc/bash.bashrc
[ -e "/etc/zsh/zshrc.backup-before-nix" ] && echo "- restoring zshrc pre Nix" && mv /etc/zsh/zshrc.backup-before-nix /etc/zsh/zshrc
@mkenigs Matthew, I forgot one thing: it would be really nice to be able to pre-configure whatās needed to share environments. Iām referring to the GH token , and also, for the push command, to be able to have command-line options to pass the token so we can actually have a real unattended installation, without prompts, etc.
In the .config/flox folder there are config files automatically created, and itās specified not to edit those, but it would be awesome having those in a dotfiles setup so you have everything setup when installing the first time.
apt purge
should be getting rid of Nix - are you noticing that itās not?
I followed nix docs to uninstall: Installing a Binary Distribution - Nix Reference Manual
Oh sorry you meant when youāre installing flox initially, you want it to clean up a pre-existing Nix installation?
We definitely need to streamline the experience when Nix is already installed. I think itās a bit invasive to completely uninstall /nix
though, as that could contain software the user still wants to use directly with Nix
Opened an issue to track this internally!
Exactly. Iām migrating all servers to flox, and used nix on all of them.
Well, since flox sits on top of nix, a sort of āconversionā of the installation should be possible, right? Or itās necessary to start from scratch because you have a specific setup? So when you apt install flox
if nix is already installed, you modify/integrate that into flox. Something like thatā¦
You mean on the GH repo?
Yes exactly, we attempt to do that, per the āInstalling over a previous installation of Nix?ā section of flox in 5 minutes | flox:docs Did you run into an issue with how itās doing that, or is there a reason you thought you needed to completely uninstall Nix? Sorry if Iāve lost track of something in the thread
No something internal for us to triage
Well, frankly speaking: since I had problems installing nix in the past with the official procedure, I had to revert to ansible to properly install the daemon multi-user version on any server. So I didnāt really trust this āconversionā process described in your docs. So I removed it completely before installing flox.
But if you say the āconversionā works fine, and the apt install flox
will take care of that, itās all good.
Conversion is definitely a bit more error prone, but that would still be the recommended path. Please report issues though if you run into them though!
Hi Robin,
I noticed the same issue again, while trying to upgrade these two packages: flyctl and chezmoi.
If I check on https://search.nixos.org/
last versions in the unstable channel are:
If I check with flox:
āÆ flox -V
Version: 0.1.5-r448-0.0.10-r234
āÆ flox search chezmoi -v
chezmoi - Manage your dotfiles across multiple machines, securely
stable.nixpkgs-flox.chezmoi@2.29.3
stable.nixpkgs-flox.chezmoi@2.30.0
stable.nixpkgs-flox.chezmoi@2.32.0
staging.nixpkgs-flox.chezmoi@2.31.1
staging.nixpkgs-flox.chezmoi@2.32.0
staging.nixpkgs-flox.chezmoi@2.33.0
unstable.nixpkgs-flox.chezmoi@2.31.1
unstable.nixpkgs-flox.chezmoi@2.32.0
unstable.nixpkgs-flox.chezmoi@2.33.0
āÆ flox search flyctl -v
flyctl - Command line tools for fly.io services
stable.nixpkgs-flox.flyctl@0.0.450
stable.nixpkgs-flox.flyctl@0.0.456
stable.nixpkgs-flox.flyctl@0.0.492
staging.nixpkgs-flox.flyctl@0.0.498
staging.nixpkgs-flox.flyctl@0.0.500
staging.nixpkgs-flox.flyctl@0.0.509
unstable.nixpkgs-flox.flyctl@0.0.498
unstable.nixpkgs-flox.flyctl@0.0.500
unstable.nixpkgs-flox.flyctl@0.0.509
Hi @alexdelprete - thanks for letting us know. This has been resolved and the correct versions should now be available in our catalog. Please let us know if you are seeing otherwise.
looks ok now, thank you.
Iām worried there could be other packages in the same condition, but I donāt have the time right now to check all the ones Iām using. Is this something that could happen again? How are the repositerories synced?
Hi @alexdelprete - thanks for your queries. The correction wasnāt just made for the 2 packages you mentioned. There is an automated process we have to update the flox catalog but unfortunately it had fallen over which went unnoticed. We restarted the process and now things are back to normal. We are also putting in better monitoring so if this happens again, we can be proactive and over time, if there is an underlying bug causing it to fall over, hunt it down and fix it.
Thanks for your feedback @robinbrantley, you and all other team members that support us are always very kind and I much appreciate it.
Is the automated process a github action visible on the public repo? Glad that you will monitor it more closely so we donāt have to worry about not catching updates.
Thank you @alexdelprete - that was lovely to hear
No, the catalog update process isnāt a github action but is instead a service that runs continuously on one of our internal infrastructure hosts.