It's not linguistically correct for Nth to be used with a binary number, right? It's not like we would say 0b10nd, would we?
I mean, I get the intent with Debian's post, and I think it's fun! I'm more curious if there's other suffixes to use for this kind of thing when it's not base10
100000th is syntactically correct. That it's semantically binary rather than decimal is the joke.
> I'm more curious if there's other suffixes to use for this kind of thing when it's not base10
No, of course not ... why would there be?
We don't say oneth, twoth, or threeth, we say first (1st), second (2nd), and third (3rd). For all other digits and numbers not ending with 1, 2, or 3 we use th. So zeroth (0th), tenth (10th), hundredth (100th), hundred thousandth (100000th). Stick 0b in front and it's 0b100000th.
Do you? I think they're referring to these packages[0].
For me `nixpacks plan .` seems to generate a plain old pip (or poetry) install. The problem with the python packaging ecosystem is that since the start, in order to figure out which dependencies a package has, we needed to run arbitrary python code (setup.py). I can write a package in 5 minutes that declares its deps with `random.choice`. If you're installing from pypi.org, then there's no reproducibility guarantee. Though, I know nothing about Nix or how it works, so maybe you're changing pip's index-url somewhere else..
You are correct in that Nixpacks uses the languages own package manager instead of installing all dependencies with Nix using tools like node2nix, cargo2nix, or poetry2nix. This was a choice as the main problems Nixpacks aims to solve are with system dependencies and getting an environment where your app can install and build with as little configuration as possible. While continuing to use the same tooling that app authors are likely using locally (e.g. npm, pip, cargo). We have found that nixifying all possible deps often creates situations where the app author must know that Nix is being used under the hood and modify their app accordingly. Nothing against these tools, but using them didn't provide the experience we set out to have. If a user of Nixpacks wants to override the install command to `do_something && npm install`, they should be able to without worrying about how it affects the Nix store.
However, any Nix package can be installed, including from python-packages.nix, and we are planning on allowing more Nix config and customization in the future.
Indeed, it's a compromise. Something I can't figure out though is if you make any attempt to remove unnecessary nix packages for the final image, i.e. in cases where a (language-)package has a native module built from source, can you generate a final image without gcc present?
There are a couple of sneaky ways this could possibly be done, but wondered if you explored any of them.
Having just written up some thoughts on how you could do it I realize they wouldn't work, because I imagine you're presenting a "standard"/FHS-esque view of the filesystem to the non-nix packages, i.e. they expect a `/usr/lib/libssl.so` to exist. Whereas Nix's ability to strip away runtime-unnecessary packages comes from packages only ever using explicit absolute references to each other.
I guess a "third way" might involve using e.g. pypi2nix, bundix, node2nix and the like.
I mean, I get the intent with Debian's post, and I think it's fun! I'm more curious if there's other suffixes to use for this kind of thing when it's not base10