Flox 1.0 – Nix ile açık kaynak geliştirme ortamlarını kodla tanımlama

 (github.com/flox)
3 puan yazan GN⁺ 2024-03-14 | 1 yorum | WhatsApp'ta paylaş
  • Flox, mühendislik ekipleri için bir yazılım ortamı platformudur; geliştirici dizüstü bilgisayarından CI ve prodüksiyona kadar aynı şekilde yeniden üretilebilen ortamları tek bir manifest ile yönetir
  • Temeli Nix olsa da Nix bilgisi isteğe bağlıdır; bildirimsel manifest ve kriptografik olarak sabitlenmiş içerik hash girdileriyle ortam drift’ini azaltan bir yapıya sahiptir
  • macOS, Linux ve Windows WSL2 üzerinde çalışır; Nixpkgs’deki 120.000’den fazla paketi arayıp kurabilir ve kendi yazılımınızı yeniden üretilebilir paketler olarak derleyip yayımlayabilirsiniz
  • flox init, flox install, flox activate akışıyla proje bazlı izole ortamlar oluşturur; etkinleştirildiğinde araçlar görünür, çıkıldığında kaybolur ve sistemi temiz tutar
  • FloxHub paylaşımı, OCI imajı oluşturma, servis çalıştırma, SBOM·CVE yamalama·SCA ve AI kodlama ajanları için deterministik yürütme ortamı dahil olmak üzere kurum ölçeğinde ortam yaşam döngüsü yönetimine odaklanır

Flox’un çözmeye çalıştığı sorun

  • Flox, geliştirme ortamını tek bir dosyada tanımlayıp aynı ortamın geliştirici dizüstü bilgisayarında, CI’da ve prodüksiyonda çalışmasını sağlayan bir platformdur
  • Geleneksel paket yöneticileri tek bir makinede paket kurulumuna odaklanırken, Flox kurum genelindeki paket ve ortam yaşam döngüsünü yönetir
  • Üç temel özelliği vardır
    • Bildirimsel: Proje için gereken araçları, ortam değişkenlerini ve servisleri tek bir dosyada açıklar
    • Yeniden üretilebilir: Aynı tanım, desteklenen herhangi bir sistemde aynı ortamı oluşturur
    • Birleştirilebilir: Proje, ekip ve pipeline bazlı ortamlar katmanlandırılabilir

Hedef kullanıcılar ve kullanım ortamı

  • Platform·DevX ekipleri, kurum genelindeki toolchain’i standartlaştırabilir ve Nix öğrenmeyi zorunlu kılmadan temel ortamları genişletebilir
  • Security·AppSec ekipleri, SBOM, hızlı CVE müdahalesi, bağımlılık kaynağı ve yeniden üretilebilir derlemelerle ilgilenebilir
  • Geliştiriciler, macOS, Linux ve Windows WSL2 üzerinde proje bazlı yeniden üretilebilir ortamlar kullanabilir; konteyner veya VM’den çok sanal ortama daha yakın bir şekilde çalışır
  • AI kodlama ajanları, üretilen kodu her seferinde aynı şekilde derleyip çalıştırabilecek deterministik bir ortam elde eder
    • Hedef örnekler Claude Code, Cursor, Copilot ve Codex’tir

Yeniden üretilebilirlik ve tedarik zinciri güvenliği

  • Flox ortamları bildirimsel manifest ile tanımlanır ve kriptografik olarak sabitlenmiş içerik hash girdilerine kilitlenir
  • Aynı lockfile, desteklenen her sistemde aynı paketlere çözümlendiğinden makineler arasında ortam aynı kalır
  • Tek bir ortam tanımı geliştirici dizüstü bilgisayarında, AI ajanı sandbox’ında, CI’da ve prodüksiyonda kullanılabilir
  • Nixpkgs’deki 120.000’den fazla paket kullanılabilir
  • Kendi yazılımınızı kaynaktan derleyerek yeniden üretilebilir paketlere dönüştürebilir ve tüm ekibin kullanması için yayımlayabilirsiniz
  • Yeniden üretilebilirlik sayesinde SBOM oluşturma, yazılım bileşimi analizi (SCA), otomatik güvenlik açığı·CVE yamalama, bağımlılık kaynağı doğrulama ve denetlenebilir derlemeleri yönetmeyi kolaylaştırır

Kurulum ve temel iş akışı

  • Flox CLI, macOS, Linux ve Windows WSL2’ye yerel şekilde kurulur
    • macOS: brew install flox veya .pkg kurulum dosyası
    • Linux: Debian/Ubuntu için .deb, Fedora/RHEL için .rpm
    • Windows: WSL2’de Linux paketlerini kullanır
  • Temel kullanım akışı, proje içinde bir ortam oluşturmak, gerekli paketleri kurmak ve ardından ortamı etkinleştirmek şeklindedir
    • flox init: projede ortam oluşturur
    • flox install python3 nodejs: ortama paket kurar
    • flox activate: ortama girer
  • README örneğinde, etkin ortam içinde python3 --version komutu Python 3.13.13, node --version komutu ise v24.15.0 olarak çalışır
  • Ortamdan çıkıldığında kurulu araçlar kaybolur; bu da projeler arası çakışmaları önler ve sistemi temiz tutar

Başlıca özellikler

  • Create: flox init ile kodun yanında bildirimsel bir ortam oluşturabilir ve otomatik etkinleştirebilirsiniz
  • Search: flox search ile Nixpkgs’deki 120.000’den fazla paketi bulabilirsiniz
  • Share: flox push / flox pull ile FloxHub’daki tek bir referans ortamı ekip üyeleri aynı şekilde alabilir
  • Containerize: flox containerize ile Dockerfile olmadan Flox ortamını OCI imajına dönüştürebilirsiniz
  • Build & publish: flox build / flox publish ile kendi yazılımınızı yeniden üretilebilir paket olarak derleyip ekibe yayımlayabilirsiniz
  • Services: flox services start ile veritabanlarını, kuyrukları ve arka plan süreçlerini ortamın parçası olarak çalıştırabilirsiniz; etkinleştirme sırasında başlar ve çıkışta durur
  • Configure: manifest.toml içinde ortam değişkenlerini, shell hook’larını ve etkinleştirme betiklerini bildirimsel olarak tanımlar
  • AI-ready: flox-agentic aracılığıyla AI kodlama ajanlarının her çalıştırmada aynı bağımlılıklarla derleme ve çalıştırma yapmasını destekler

Docker ve Nix kullanıcıları için konumu

  • Flox bir konteyner teknolojisi değildir ve Docker’ın yerine geçen bir araç değildir
  • Docker’da paketleme ile konteyner izolasyonu çoğu zaman iç içe geçer; Flox ise yazılım paketleme ile seçilen izolasyon yönteminin ayrılması gerektiğini savunur
  • Flox ortamları bare metal, VM ve konteyner üzerinde aynı şekilde çalışır
  • flox containerize, yazılım ortamını içeren OCI imajları oluşturur ve Docker, Kubernetes ile diğer konteyner runtime’larıyla birlikte kullanılabilir
  • Nix kullanıcıları için Flox bir alternatif değil, ek bir araçtır
    • İş birliği ortamı ve paket paylaşımı için merkezi servis FloxHub sunar
    • Etkinleştirme hook’larını, servisleri ve shell profillerini tek bir bildirimsel TOML dosyasında birleştirir

Kaynak ve destek kaynakları

  • Flox, D.E. Shaw group’un büyük ölçekli kurumsal Nix dağıtımından doğmuştur ve büyük mühendislik organizasyonlarında Nix’i erişilebilir kılmak için kullanılmıştır
  • İlgili kaynaklar
  • Güvenlikle ilgili başvurular security@flox.dev adresinden alınır
  • Flox CLI lisansı GPLv2’dir

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-14
Hacker News yorumları

  • Ron, lansman için tebrikler. Merak ettiğim şey gelir modelinin ne olduğu
    Bir CEO, şirket ve çalışanlar var; Crunchbase’e bakınca 24 milyon dolar yatırım almış gibi görünüyor, ama açılış sayfasında ya da dokümantasyonda fiyat bilgisi bulamıyorum
    GitHub profiliyle FloxHub’a giriş yapsam da ödeme seçeneği görünmüyor; planı merak ediyorum

    • İşaret ettiğin için teşekkürler. Bugün duyurduğumuz ücretsiz ve açık kaynak biçim, Flox’u başlatmamızın önemli bir nedeniydi ve ileride daha fazlasını eklemeyi planlıyoruz
      Bugün duyurduğumuz açık kaynak istemci ve ortam paylaşımı için FloxHub hizmeti kalıcı olarak ücretsiz sunulacak
      Daha sonra temel Flox Catalog’un üzerine eklenen daha güçlü bir özel yazılım kataloğu sunmak istiyoruz
      Kendi çıktılarınızı dağıtmanız ya da Flox içinde değiştirilmiş açık kaynak paket sürümlerine ihtiyaç duymanız halinde, her zaman ücretsiz olan Flox Catalog’u tamamlayacak kendi kataloğunuzu kolayca oluşturabilmenizi planlıyoruz
      Uzun vadede, şirketlerin geniş ve parçalı yazılım tedarik zincirlerini daha iyi yönetmesine yardımcı olacak abonelik ve hizmet biçiminde kurumsal çözümler satmak istiyoruz; şirkete özel araç geliştirme maliyetini şirketlerin birlikte üstlenmesini makul görüyoruz
    • 24 milyon dolar almış olmasına şaşırdım. Buradan 2,4 milyar dolarlık çıkışa giden yolu pek göremiyorum ama bol şans

  • README’deki “Nix’i yeni kullanıcılar için daha kolay hale getirir” tarzı ifadeleri ya da benzerlerini her gördüğümde takılıyorum
    Kendimi oldukça yetkin sayarım ama Nix kullanırken bir kez bile “bu kolaydı” diye hissetmedim
    Nix’in kavramlarını gerçekten seviyorum ama kullanıcı deneyimi berbat. Bu araç bunu çözüyor olabilir, fakat o noktaya gelene kadar neredeyse hiç dokümantasyon olmadan ve çoktan terk edilmiş yöntemler arasında gezinerek ayarlarla durmadan uğraşmak gerekiyor; bu da çok bunaltıcı
    Her hâlükârda Nix’le ilgili bir şey gördüğümde “bunun kolaylaşacağı günü bekliyorum” diye düşünüyorum

    • “Flox, D. E. Shaw Group’ta Nix’in benimsenmesi sırasında başladı ve Nix’i yeni kullanıcılar için daha kolay hale getirerek değerini hızla kanıtladı” cümlesinden bahsediyorsan, bu bana senin yorumunun tersini söylüyor gibi geliyor
    • O cümle Nix’in yeni kullanıcılar için kolay olduğu anlamına değil, Flox’un Nix’i kolaylaştırdığı anlamına geliyor diye okunuyor
    • Tamamen aynı deneyim. NixOS ile epey uzun süre uğraştım ama .nix ya da flakes’e alışamadım
      Temel kavramlar sürekli aklımdan çıkıyordu; her yeni bir şey yapılandırdığımda tekrar bakmam gerekiyordu ve sonunda pes ettim
      Sorun ayıklamak da zor; neyin yanlış olduğunu anlamak için çok belirli komutları ve cehennem gibi bir dosya sistemini kurcalamak gerekiyor
      Kavramı seviyorum ama pratikte çok fazla engel çıkardığını hissediyorum
    • Nix’i seviyorum ve nix deposuna epey paket de katkıladım, ama asla kolay diyemem
      Haskell geçmişim olduğu için daha tanıdık geliyor, ama sözdiziminin kendisi de yeni kullanıcılar için sezgisel değil
    • Kesinlikle katılıyorum. Avantajları görüyorum ama başlangıç öğrenme eğrisi inanılmaz dik
      Rust öğrenmeye benziyor; bu yönüyle eğlenceli de

  • “Öğrenme eğrisi olmadan Nix’in gücünü sunar” türü ürünlerin temel sorunu, arkada hâlâ Nix ve /nix/store olması; Nix de bunu bilerek otomatik temizlemiyor
    Kullanıcı Nix’i gizleyen bir aracı denedikçe eninde sonunda diski dolar; depolama alanını nasıl azaltacağını bilmediği için buna kullanıcı dostu demek zor
    Kullanıcının Nix kurduğunu bilip öğrenme sürecinden geçmesi farklı; bu sayede /nix/storeın ne olduğu ve nasıl yönetilmesi gerektiği hakkında zihinsel bir model kurabilir
    Bu tür alt katman karmaşıklığını nasıl ele almayı planladığınızı merak ediyorum

    • Geri alma ve geçmiş desteği varsa diskin dolması kaçınılmaz. Nix’te genellikle birden fazla GC kökü profillere ve paketlere işaret ettiği için bunlar temizlenemez
      Flox’un ortamları basit sembolik bağlantılar değil; bildirime dayalı bir biçime, içeride de flakes’e sahip, bu yüzden kaldırılabilir ve gerekirse yeniden üretilebilir
      Bu nedenle çöp toplama, nix-env/nix profile kullanmaya kıyasla daha az yıkıcı olur ve eski nesiller daha agresif biçimde temizlenebilir
      Strateji, temizlenen şeyi geri getirebilecek bildirime dayalı ve yeniden üretilebilir bir yöntemi her zaman garanti ettikten sonra; boş alan, yaş, yakın zamanda kullanılmamış olma ve düşük kullanım sıklığı gibi sezgisel ölçütlerle diskin dolmasını önlemek
    • Docker ya da Bazel ile karşılaştırınca nasıl olur diye düşünüyorum
      Tersine, Nix’te bu sorunu hiç yaşamadım. Çöp temizleme yöntemini açıkça anlatıyor ve geride ne kaldığını, neden kaldığını da kolayca inceleyebiliyorsunuz
      Varsayılan olarak etkin olmamasının nedeni, diğer çöp toplayıcılar gibi engelleyici olabilmesi ve herkese uyan tek bir politikanın olmaması
      Sonuçta GC kökü çok fazlaysa bir karar vermek gerekiyor
    • Nix çöp toplama desteği sunuyor
      Bilgisayar kullanırken arka planda akıl almaz derecede karmaşık binlerce şey oluyor; Nix’i soyutlamanın neden özel muamele gördüğünü pek anlamıyorum
    • İş yerinde Bazel ile aynı sorun bizde de var. Birkaç ay geçince geliştirme makinelerinin disk alanı tükeniyor
    • Nix çöp toplamasını her 30 dakikada bir çalışacak şekilde ayarlamak yeterli

  • Yayın için tebrikler. Nix’i gerçekten seviyorum ama onboarding deneyiminin en iyi ihtimalle kötü, en kötü ihtimalle berbat olduğunu da kabul ediyorum
    Bu yüzden onu daha erişilebilir kılmaya yönelik girişimleri memnuniyetle karşılıyorum. Imperative CLI, birçok kişinin beklediği ve rahat hissettiği kullanım biçimine çok daha yakın; bu yüzden iyi bir yön olduğunu düşünüyorum
    Başka yerlerdeki ortamları kullanma sürecini basitleştirme fikrine de büyük ölçüde katılıyorum
    Ancak önemli göründüğü hâlde göremediğim şey IDE entegrasyonu. IDE’yi ortamın içinden komut satırıyla başlatmak birçok iş arkadaşım için sezgisel değil ve bunu birkaç kez gerçek sorunun temel nedeni olarak teşhis ettim
    Gerektiğinde “gerçek Nix”e inme hikâyesinin nasıl olduğunu merak ediyorum. Örneğin Rust cross-compile toolchain’i ayarlayan biraz daha karmaşık bir ortamda uçurumdan düşer miyiz diye endişeleniyorum
    Rust geliştirme örneği olarak, Rust-Analyzer’ın düzgün çalışması için bir flake’e uzun bir shellHook koymam gerekmişti; Flox’ta böyle bir ayarın nasıl yapılabileceğini merak ediyorum
    Bu tür şeyleri soyutlamaya mı çalışıyorsunuz, yoksa öyle değilse Nix bilmeyen bir kullanıcı bunu nasıl keşfedebilir, onu da merak ediyorum
    Kesinlikle imkânsız demek istemiyorum; gerçekten başarılı olmasını istiyorum ama yöntemi henüz net göremiyorum

    • Gerektiğinde “gerçek Nix”e inme kısmını zaten tartıştık ve ek güce ihtiyaç duyulduğunda Nix’in kendisini kullanabilmeyi planlıyoruz
      Şu anki düşüncemiz, belirli alanlarda flake referanslarına izin vermek veya Nix tarzı bir giriş noktası sunmak
      Henüz yayımlanmış ya da belgelenmiş değil; bu yüzden beklemenizi rica ederim
      Karmaşıklığı gizlemek ile yetenekleri açığa çıkarmak arasında gerçekten çok ince bir çizgi olduğu konusunda tamamen katılıyorum

  • Sıradan nix-shell veya nix develop yerine Flox kullanmanın avantajının ne olduğunu merak ediyorum

    • Flox çalışanıyım. Nix araçlarıyla ilişkiden başlarsak, hedef daha kullanıcı dostu olmak
      Nix expression dilini öğrenmeden veya Nix’in iç yapısını anlamadan başarılı olabilmenizi istiyoruz
      Ayrıca bir ölçüde yönlendirme ve cilalama ekledik. Örneğin imperative/declarative karma bir arayüz var; flox install && flox list çalıştırdığınızda değişiklikler TOML’a yansıyor. Buna karşılık nix develop ile Nix expression’ını düzenlemeniz gerekiyor
      nix develop bash shell’e girer, ama flox activate bash veya zsh shell’e girebilir; fish desteği de eklemeyi planlıyoruz
      Ortamları Git ile yönetmeyi Nix araçları gibi destekliyoruz; ayrıca flox push/flox pull/flox activate -r gibi o araçlarla mümkün olmayan ortam paylaşımı biçimleri de ekledik
      Bir hesap oluşturursanız https://hub.flox.dev/mkenigs/default adresinde benim ortamımdaki paketleri görebilir; CLI varsa flox list -r mkenigs/default ile kontrol edip flox activate -r mkenigs/default ile kullanabilirsiniz
      Nix expression dilini bilmeyen birine flake.nix link’i vermekten çok daha kolay sindirilebilir olduğunu düşünüyorum
    • Başka bir deyişle, tek tek mühendislerin temel teknolojiyi ve onunla gelen araçları öğrenmesinin daha iyi olduğunu düşünüyorum
      Flox veya devenv gibi araçların ömrünün sona ermesi, nixpkgs’i düzgün takip edememesi ya da yazılımın çürümesinin birçok yolundan birine maruz kalması gayet mümkün
      Buna karşılık nix develop, Nix Flakes var olduğu sürece kalacaktır ve sonraki yönteme geçiş için migration yolu sunma motivasyonu da olacaktır
      Daha da önemlisi, tüm soyutlamalar sızıntı yapar. Flox CLI daha temiz görünebilir ama sonunda onu etkili kullanmak için Nix öğrenmeniz gerekecek
      Gerekenden iki kat fazlasını öğrenmeye ne gerek var diye düşünüyorum
    • Ya da https://devenv.sh de var

  • Mevcut Devbox projesiyle (https://www.jetpack.io/devbox) nasıl karşılaştırıldığını merak ediyorum
    Flox’ta isteğe bağlı bir bulut çözümü var mı, belirli bir Nix paketi sürümü kurulabiliyor mu, işletim sistemine özgü bağımlılıklar nasıl ele alınıyor, bunları da öğrenmek isterim
    Bu tür araçları 5 yıldır kullanıyorum; Flox’un zaten var olanlara kıyasla ne yeni getirdiğini merak ediyorum

  • Bunu neden normal Nix yerine kullanmam gerektiğini gerçekten anlamıyorum; açıklayabilir misiniz

    • Proje başına yalnızca temiz ve tekrarlanabilir ortamlar istiyorum. Nix’e birkaç kez giriş yapmaya çalıştım ama Nix o kadar çok farklı şey yapıyor ki her seferinde bunaldım
      Bu bana 100 kat daha basit görünüyor
    • Nix’in birçok sorunu çözdüğünü anlıyoruz ve gerçekten de bu kabiliyete yatırım yaptık. Bu yüzden Nix’in kendisine de çok emek verdik
      Ancak Nix, ilk ilkelerden başlayarak çok genel amaçlı olacak şekilde inşa edildiği için öğrenme eğrisi epey dik
      Flox, problem alanını daraltıp özelleşmiş soyutlamalar ve arayüzler sunarak, ilk günden Nix uzmanı olmanız gerekmeksizin Nix’in gücünden yararlanmanızı sağlayacak şekilde basitleştirmeye çalışan bir araç
    • İş arkadaşlarını Nix’e ikna etmektense flox veya devenv’e ikna etmek çok daha kolay

  • Yeniden üretilebilir geliştirme ortamlarıyla çok ilgileniyorum ve iş yerinde de birkaç yıldır geliştirme konteynerlerini gayet iyi kullanıyorum
    Yaklaşık 1 yıl önce Nix’i duydum; başta vaatleri harika olduğu için çok heyecanlandım ama onboarding süreci benim için berbat geçti
    Oluşturmak istediğim geliştirme ortamı net, ama yaklaşımda sürekli bir şeyi kaçırıyormuşum gibi hissediyorum
    Tüm deneyimi iyileştirmeye çalışan yeni bir araç çıktığı için sevindim; denemeye devam edersem bir gün kafama oturmasını umuyorum
    Sizin için Nix hangi anda “tam yerine oturdu”, merak ediyorum

    • Soru için teşekkürler. Bu, Bay Area’ya gelirseniz bira eşliğinde derinlemesine konuşulacak bir konu
      Microservices videosunu hiç izlediniz mi? https://www.youtube.com/watch?v=y8OnoxKotPQ
      O dönemde Facebook’ta geliştirici ürünleri ekibini yönetiyordum ve yerel geliştirmeye uzaktan yetenekler enjekte eden bir proje başlatmıştım
      Binlerce geliştirici cold build için 45’er dakika bekliyordu
      İlk aşamalardan biri tüm yazılım geliştirme yaşam döngüsünü haritalamaktı; amaç, toolchain’in hangi kısımlarını yeniden oluşturmamız gerektiğini anlamaktı
      Videonun sonlarındaki whiteboard’u görünce akla geldiği gibi, ne kadar karmaşık hâle getirdiğimizi görselleştirdiğimiz anda “bizim çalışma şeklimiz bu olamaz” düşüncesine kapılıyorsunuz

  • Nix’i en son kullandığımda flakes konusunda epey kafa karışıklığı vardı
    Bazı öğreticiler kullanın diyordu, başka yerler ise hâlâ geliştirme aşamasında olduğunu söylüyordu; durumun düzelip düzelmediğini merak ediyorum

    • Bence düzeldi. Burada listelenen çözümlerin neredeyse tamamı, hatta belki hepsi, dahili olarak flakes kullanıyor gibi görünüyor: https://news.ycombinator.com/item?id=39696038
      flakes sorununun iki noktadan kaynaklandığını düşünüyorum
      Birincisi, neredeyse 5 yıldır üzerinde experimental etiketi olması; bu yeni kullanıcıların kafasını karıştırıyor ama gerçekte neredeyse her yerde yaygın biçimde kullanılıyor
      Diğeri ise https://determinate.systems/ ile eski Nix kullanıcıları/geliştiricileri arasında havanın kötü görünmesi. Determinate Systems’ın Nix’i kendi çıkarına kullanıp katkıyı geri vermediği yönünde eleştirildiği anlaşılıyor
      Benim anladığım kadarıyla flakes’i Determinate Systems getirdi ve bu yüzden bazıları direniyor gibi
      Sonuç olarak neredeyse herkes flakes’i benimsedi; kullanmayan rehberler büyük olasılıkla eski olabilir
      İlgili bağlantı: https://discourse.nixos.org/t/introducing-flakehub/32044
    • Bugünlerde flakes kullanmayın diye öneren birini bilmiyorum
      “experimental” etiketi, olgunluk ya da hatalardan çok API kararlılığı ile ilgili bir anlama daha yakın
      Belirli durumlarda performans sorunları olabilir ama geçici çözümler var ve kalıcı bir çözüm üzerinde de çalışılıyor
      Yine de evde ve işte flakes’i yoğun şekilde kullanıyorum
    • Not: Yeni CLI ve Flakes’i kademeli olarak kararlı hâle getirme planı https://github.com/NixOS/rfcs/pull/136

  • Dün gece macOS’ta Flox’u denedim; Nix-Darwin’in /run/current-system/sw/bin içinde yönettiği Nix’ten ayrı olarak varsayılan profile Nix kurduğunu ve bu kopyayı /usr/local/bin içine sembolik bağladığını gördüm
    Mevcut Nix kullanıcıları, yani NixOS kullanıcıları ya da Nix’i zaten kurmuş olup Flox’un desteklediği dağıtım paket biçimi bulunmayan başka dağıtımlardaki kullanıcılar için de bir yönlendirme yoktu
    Flox’un Nix için üçüncü taraf bir profil yöneticisi olması nedeniyle kararsız Nix profile manifest biçimi gibi şeylere mi bağımlı olduğunu, yoksa aslında çeşitli Nix sürümleriyle kullanılabilir olup sadece test edilmemiş mi olduğunu merak ediyorum
    Nix tabanlı Flox kurulumunu ileride desteklenecek bir özellik olarak düşünüp düşünmediklerini de bilmek isterim
    Ayrıca fish desteğinin geleceği söylenmişti; activate alt komutunun shell entegrasyonunun Flox kaynaklarında ya da yapılandırmasında gerçekte nerede olduğunu söyleyebilir misiniz
    Resmî fish desteğini beklerken fenv gibi bir şeyle geçici olarak bağlamayı denedim ama kurulu sürümü ve kaynakları tarayınca takılabilecek uygun bir yer pek göremedim

    • https://flox.dev/docs/install-flox/ adresindeki Nix/Generic ve Nix/NixOS sekmelerini kaçırmış olabilirsiniz. Bunun bahsettiğiniz yan yana kullanım senaryosunu karşılayıp karşılamadığını merak ediyorum
      Şu anda fish kullanmanın en iyi yolunun FLOX_SHELL=zsh flox activate -- fish olduğunu düşünüyorum. Takma adları desteklemez ama çoğunlukla çalışacaktır
      Gerçekten kaynağı hacklemek mi istiyorsunuz, yoksa geçici bir çözüm üretmek için yapıyı mı anlamaya çalışıyorsunuz, onu da merak ediyorum
      bash veya zsh olmayan shell’lerde şu civarda hata veriyor: https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827...
      Kendiniz düzeltmeyi denemek isterseniz arka planı daha ayrıntılı anlatmaktan memnuniyet duyarım