nix-installers
oil
nix-installers | oil | |
---|---|---|
5 | 238 | |
85 | 2,760 | |
- | 1.1% | |
6.7 | 9.9 | |
3 days ago | 6 days ago | |
Nix | Python | |
- | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
nix-installers
-
The Determinate Nix Installer
If you install it from the community RPM installer, it works as they have SELinux support added: https://github.com/nix-community/nix-installers
-
nix won´t install on Fedora 37
I tried to install the Nix package manager on my Fedora 37 machine. Having read about some issues with installing Nix with the install script on Fedora and other OS, using Selinux, I chose install via "nix-installers" rpm-packe (https://github.com/nix-community/nix-installers/issues/16). Unfortunately, I get warnings about created uids throughout the install process not being in the scope of `SYS_UID_MAX 999`. Furthermore, after rebooting the computer, I end up with a flickering black screen instead of on my (Gnome) Desktop environment.
-
how do you get selinux to work with nix without disabling it?
Looks like you already found u/adisbladis legacy installers and opened a feature request for Silverblue support. Your best bet would be to start learning how SELinux policies work and see if you can adapt those for the way that you've set up Silverblue, or to see if you can modify the RPM builder to accommodate Silverblue by putting the Nix store under /var and bind mounting it onto /nix, like those other instructions floating around do.
-
I would like to see more cli apps avaliable as flatpaks
There's work to add nix to silverblue via community packaging: https://github.com/nix-community/nix-installers/pull/8
-
Hacking Anything with GNU Guix
I think nonguix also uses equivalent machinery for its Steam package: https://gitlab.com/nonguix/nonguix/-/blob/master/nongnu/pack...
Maybe there are docs on repurposing that someone more familiar with nonguix can point to.
Apparently there is an rpm-ostree-friendly RPM build of Nix that can be used to install Nix on Silverblue as well: https://github.com/nix-community/nix-installers/pull/8
It includes some code to get around the group/user management quirks that some other commenters have noted b0rked the Guix installer, so perhaps it gives an outline of how to install Guix on Silverblue for a hacker who'd like to try it :)
oil
-
POSIX.1-2024 Is Published
Is it an array of strings because it's a "simple command"? Or does it behave like an assignment? You get two different answers depending on how you look at it.
The bottom line is that assignment builtins are special and they don't follow the normal rules of simple commands. Shells have differed, but POSIX decided on this awhile ago.
---
This is all of course mind numbing trivia that has no real reason for existing ... YSH fixes it, and it's now pure native C++, no more Python.
YSH Doesn't Require Quoting Everywhere - https://www.oilshell.org/blog/2021/04/simple-word-eval.html (Oil was renamed to YSH since this blog post was written)
Simple Word Evaluation in Unix Shell - https://www.oilshell.org/release/latest/doc/simple-word-eval...
In YSH you can tell just by looking it's a single string or an array.
ls $a # identical to ls "$a"
-
New Programming Langauge Makes Bash Scripting Easier
Oils is a different approach to this - the base “OSH” language is pretty much identical to bash, and then you can incrementally opt in to more checks and QOL improvements.
The key selling point is that you never have to totally rewrite your existing bash scripts - there’s an incremental upgrade path.
https://www.oilshell.org/
-
Elvish, expressive programming language and a versatile interactive shell
While I don't agree with most of your analysis - in particular for the second example, I'd invite you to read its explainer that goes into much more depth (https://elv.sh/learn/scripting-case-studies.html#update-serv...) - I think you might be more interested in the Oil Shell project, which is trying to chart a smooth upgrade path from bash: https://www.oilshell.org
I think we simply can't say for sure which path is better for the future of shells, and I'm quite excited by the fact that different projects are exploring different directions. I will just stick to the path I find best and won't try to convert you :)
-
The life and times of an Abstract Syntax Tree
Some related references (on a somewhat messy wiki page) - https://github.com/oilshell/oil/wiki/Compact-AST-Representat...
Feel free to add others
-
Autoconf makes me think we stopped evolving too soon
will prevent almost all of the "silent footguns".
YSH has strict:all and then a bunch of NEW features.
There's been good feedback recently, which has led to many concrete changes. So your experience can definitely influence the language! https://github.com/oilshell/oil/wiki/Where-To-Send-Feedback
-
Basic Things
Regarding writing tools/tests/benchmarks in bash+Python, vs. writing tools in your main language:
I think we might eventually concede that something Debian-like is the “standard development environment” (at least for server side stuff, i.e. not iOS apps)
In this case, bash+Python is a non-issue. It works extremely reliably. That’s actually why I use it! Everything else seems to break, or it’s really slow (node.js is a very common alternative).
- Microsoft conceded this back in ~2017, by building Linux into their kernel with WSL, and providing Ubuntu on top
Yes bash + Python is a disaster on Windows (I have scars from it), but Microsoft agrees that the right place to solve that is in Windows :-)
- Every CI system runs Debian/Ubuntu
- Every hosting provider runs Debian/Ubuntu
- Every online dev env like gitpod.io provides Debian/Ubuntu
This is somewhat related to remote dev envs: https://lobste.rs/s/ucirlx/lapdev_self_hosted_remote_dev
One vision for https://www.oilshell.org/ is that the CI environment is the dev environment is the hosting environment.
Everything is just an equal node in a distributed system. BUT it’s more git like, in that you explicitly sync and work “locally”, wherever that is. You don’t have the network chatter and flakiness of “the cloud”.
Oils has a very large set of monotonically increasing properties too - https://www.oilshell.org/release/0.21.0/quality.html
All that is bash+Python that is run on every commit, and it’s extremely good at catching bugs and perf regressions.
I’m skeptical that any project has that level of quality automation written in pure Rust or Zig. More likely it’s a bunch of cloud services with YAML.
Also a bunch of “hard-coded” toolchains that you can’t script with bespoke code. Like some shell commands in your package.json, which is just a worse way of writing a shell script.
Our quality process is all self-hosted, in the repo, and runs on both Github Actions and sourcehut - https://www.oilshell.org/release/0.21.0/pub/metrics.wwz/line...
bash and Python runs perfectly on Github Actions and sourcehut, with zero change. Containers also do.
(Although we need to unify the CI and release, because the release runs on 2 different real hardware machines, while CI is cloud only.)
Also, a main point Oils is that bash now has another highly compatible, spec-driven implementation – OSH. Having 2 independent implementations is something newer languages don’t have.
(copy of lobste.rs comment)
-
The secret weapon of Bash power users
in your bashrc to enable it. I've used it for probably ~18 years now.
It also works with https://www.oilshell.org/ since we use GNU readline. Just 'set -o vi' in ~/.config/oils/oshrc
-
Pipexec – Handling pipe of commands like a single command
No other shell does that.
But I didn't know it was called MULTIOS until now. (I guess that's read "mult I/O's"? I have a hard time not reading it was multi-OS :) )
It seems a bit niche to be honest, but it's possible to support in Oils.
---
Oils also uses Unix domain sockets already for the headless shell protocol
https://github.com/oilshell/oil/wiki/Headless-Mode
We could do something like dgsh, but so far I haven't seen a lot of uptake / demand. Every time it's mentioned, somebody kinda wants it, and then it kinda peters out again ... still possible though.
I think flat files work fine for a lot of use cases, and once you add streaming, you also want monitoring, more control over backpressure/queue sizes, etc.
-
Show HN: Hancho – A simple and pleasant build system in ~500 lines of Python
which works well. You don't have to clean when rebuilding variants. IMO this is 100% essential for writing C++ these days. You need a bunch of test binaries, and all tests should be run with ASAN and UBSAN.
---
I wrote a mini-bazel on top of Ninja with these features:
https://www.oilshell.org/blog/2022/10/garbage-collector.html...
So it's ~1700 lines, but for that you get the build macros like asdl_library() generating C++ and Python (the same as proto_library(), a schema language that generates code)
And it also correctly finds dependencies of code generators. So if you change a .py file that is imported by another .py file that is used to generated a C++ header, everything will work. That was one of the trickier bits, with Ninja implicit dependencies.
I also use the Bazel-target syntax like //core/process
This build file example mixes low level Ninja n.rule() and n.build() with high level r.cc_library() and so forth. I find this layering really does make it scale better for bigger projects
https://github.com/oilshell/oil/blob/master/asdl/NINJA_subgr...
Some more description - https://lobste.rs/s/qnb7xt/ninja_is_enough_build_system#c_tu...
-
Re2c
This is sort of a category error...
re2c is a lexer generator, and YAML and Python are recursive/nested formats.
You can definitely use re2c to lex them, but it's not the whole solution.
I use it for everything possible in https://www.oilshell.org, and it's amazing. It really reduces the amount of fiddly C code you need to parse languages, and it drops in anywhere.
What are some alternatives?
nixos-config - General purpose Nix configuration for macOS / NixOS with starter templates, step-by-step guides, and more ✨
nushell - A new type of shell
nix-installer - Install Nix and flakes with the fast and reliable Determinate Nix Installer, with over 2 million installs.
fish-shell - The user-friendly command line shell.
guix-notes - This repo has moved to https://gitlab.com/pjotrp/guix-notes Notes on Guix
elvish - Powerful scripting language & versatile interactive shell
xmake-repo - 📦 An official xmake package repository
xonsh - :shell: Python-powered, cross-platform, Unix-gazing shell.
dotfiles - Nix-managed dotfiles for macOS and WSL
PowerShell - PowerShell for every system!
nix-portable - Nix - Static, Permissionless, Installation-free, Pre-configured
FaceFusion - Next generation face swapper and enhancer