If you mean the NixPkgs repo on the auxolotl account then I would just refer to that as the Aux NixPkgs fork. We will be doing away with it eventually, no reason to rename it.
3 Likes
what will the replacement be called?
Just Aux Packages seems fine
3 Likes
This is, of course, assuming we use standard naming - I think there aren’t any problems with the OS having a different name from the rest of the subprojects, specially since “using NixOS as your system” and “using Nix as a way to package stuff and manage dev environments” are pretty distinct experiences. Not many distros other than NixOS and Guix System are named after their package manager, after all. (Though obviously, not many package managers other than Nix and Guix are distro-agnostic)
1 Like
On why ‘Aux’ isn’t a great choice: plenty of search hits from ‘ps aux’ being a common linux command. Those are going to pollute many sane searches attempting to find Aux
2 Likes
generally speaking it is good for the “brand” to have a consistent identity. Google Photos, Google Maps, etc. Not “Photo Wizard”, “Maptastic”, etc.
I hope we get both auxolotl.org and .com!
I see this as an absolute win because I have so many times forgotten whether a website was .org or .com and so I enter in the wrong tld. If we can just have one redirect to the other that could prevent an easy way to typosquat! : D
1 Like
Maybe it wasn’t a problem for you, but I can confirm it was/is a problem me and others. I would have paid a good bit of money to be able to type 6 extra chars and have better search results.
When I have a deadline, and I can’t find what I need, it matters. It matters to my client, my professor, the members on robotics team counting on me to get the code fixed by the next match, and to my own sanity. Nix is the only, and I mean only, tool that I have browser bookmarks for, because the SEO is so bad I can’t find those pages again without bookmarks.
Oh I 100% agree. I mean the github CLI is gh, WebAssembly is wasm, I have a tool called Archaeopteryx and the CLI is archy. Abbreviations are important too. Its just the stackoverflow tag, the name of the github repo, the website name, etc.
For some reason while I’m a mild fan of having the OS name be separate from Aux/Nix, I’m very much not a fan deviating from terminology like “package”, “derivation”, and “attr”. I think its because reservior makes me ask “woah, is this a functionally new concept? (Like how inheritance is different from traits)”. ThingamajigOS, I just say “Oh, its an OS, and thats its name. Got it.”
People probably wouldn’t know what to assume about reservior without reading a definition. So it adds friction compared to auxpkgs which I’d guess people probably would know how to use even without reading any docs.
3 Likes
that’s fine by me then
nb. I have setup search “bang expressions” like !np to search nix packages, !no to search module options, etc I find these help me navigate the documentation quickly.
1 Like
I know this (long, of course) thread is mostly about naming… but I specifically want to call out a desire to separate these entities. Right now there’s entanglement between nix lib, nixpkgs lib, the nixos module system, and of course the packages and services that use them.
It makes (or made) sense as a monorepo that can be versioned as a single revision, while at the same time creating some challenges for other separate repos that effectively had to pull in all of nixpkgs.
I’m sure there are discussions elsewhere with ideas about splitting these up technically, and the idea that potentially some common base can still be shared across various forks. I’m only just getting started in this discourse (first post!). For this thread, I just want to reinforce that clarity in naming things will help them be understood as distinct concepts.
In lix, we had a whole similar discussion on disambiguating all the things and stages that get loosely called “a derivation” and there’s a fierce will to fix that mess in documentation
7 Likes
Absolutely agree.
And welcome to the forum!!
You may find this thread on breaking apart NixPkgs interesting: Musings on a monorepo versus developer oriented distribution
1 Like
This point is well worth not glossing over. Having a long-form name is fine, but you need to consider an actually portable short-form which works in abbreviations for cli, combination into sub-names, and indeed typing into URL bars. “Aux” is great for that - the long-form is excellent, but please do not retire the aux.computer domain for example.
2 Likes
I was thinking it would be good to have “auxolotl” be the community space name that ties everything together. Aux for short, with the implicit pun of “auxiliary Nix”. The aux.computer domain would redirect to auxolotl.org when we have updated branding and a better homepage that is able to flesh things out more.
1 Like
Makes sense. I would also recommend styling the name use to call out the two forms. For example:
AUXolotl
AUX
olotl
Dependent on context.
1 Like
Not a huge fan of the casing although I understand the intent. I wonder if it’s even necessary though. I feel like having “Aux” on the pages and auxolotl as the space names may be enough for people to get it.
1 Like
The styling does not have to be done with casing - that was just intended as example. Other examples could be differences in font weight or colour.
4 Likes
Honestly, we should just drop the aux and go with olotl, it’s unique and only requires a few removals to become lol. 
(this is a joke please don’t kill me )
5 Likes