4 ms·

It would be nice to have a shorthand value that means "evaluate this pure function exactly the same way regardless of the 'system' parameter", which would be he

It would be nice to have a shorthand value that means "evaluate this pure function exactly the same way regardless of the 'system' parameter", which would be helpful for completely architecture-less packages (such as interpreted scripts).

pxc 3y ago
Which deps they pull in is still determined by system because their interpreters are in the dependency closure and what arch Perl is built for affects that Perl package's hash, etc.
pmarreck 3y ago
But as the other person said, you're still building in assumptions in that case, which is bad (from the perspective of the whole philosophy of the Nix design choices). Because the script assumes that the script runner (which is also compiled to a certain CPU and OS!) will work when given the script as input, for example- and it is not guaranteed to. If you include the OS and CPU arch, it is FAR MORE guaranteed to (although perhaps, not 100% provably). Perhaps you haven't dealt with enough Python packages that make assumptions about the availability and state/version of underlying OS-level libraries (and Python itself: See the transition from versions 2 to 3 as an example of this chaos) to understand how important it is to control for assumptions. What you gain in convenience today, you pay tenfold for as "interest" later (this is thus definitely one aspect of the "tech debt" problem).
- seabass-labrax 3y ago
  I certainly have experienced my fair share of architecture-dependant Python horror stories, and I agree with your philosophy of convenience as a kind of loan against tech debt! However, if I package a Python script that appears not to use any system libraries or features (maybe I even wrote it myself), I would define the build for any architecture. One reason for doing this would be for when $DISTRO declares that they will now support a new architecture. What packages would then be expected to require patches? If existing packages were marked as 'all', those can reasonably be expected to succeed and should cause noisy errors if they don't. Conversely, packages which were explicitly marked for specific architectures (even if that is all the architectures that the distribution supported when they were created) can be expected not to work on the new architecture without modification. This does of course require the packager to actually know the difference between using the keywords and just marking every known architecture. And to be fair, what I was originally advocating for in my comment was more like Debian's 'any' wildcard, which is not quite as strong as the assertion that the package is completely architecture-independent. I would say that a specific tag for architecture-independent builds actually improves the situation: explicitly acknowledging the assumption that exotic architectures will never be an issue. Of course, as your sibling comment mentions, the interpreter is still part of the closure in Nix, so maybe this is incompatible with the existing choices made in the Nix ecosystem.

pxc 3y ago

Which deps they pull in is still determined by system because their interpreters are in the dependency closure and what arch Perl is built for affects that Perl package's hash, etc.

pmarreck 3y ago

But as the other person said, you're still building in assumptions in that case, which is bad (from the perspective of the whole philosophy of the Nix design choices). Because the script assumes that the script runner (which is also compiled to a certain CPU and OS!) will work when given the script as input, for example- and it is not guaranteed to. If you include the OS and CPU arch, it is FAR MORE guaranteed to (although perhaps, not 100% provably). Perhaps you haven't dealt with enough Python packages that make assumptions about the availability and state/version of underlying OS-level libraries (and Python itself: See the transition from versions 2 to 3 as an example of this chaos) to understand how important it is to control for assumptions. What you gain in convenience today, you pay tenfold for as "interest" later (this is thus definitely one aspect of the "tech debt" problem).

seabass-labrax 3y ago
I certainly have experienced my fair share of architecture-dependant Python horror stories, and I agree with your philosophy of convenience as a kind of loan against tech debt! However, if I package a Python script that appears not to use any system libraries or features (maybe I even wrote it myself), I would define the build for any architecture. One reason for doing this would be for when $DISTRO declares that they will now support a new architecture. What packages would then be expected to require patches? If existing packages were marked as 'all', those can reasonably be expected to succeed and should cause noisy errors if they don't. Conversely, packages which were explicitly marked for specific architectures (even if that is all the architectures that the distribution supported when they were created) can be expected not to work on the new architecture without modification. This does of course require the packager to actually know the difference between using the keywords and just marking every known architecture. And to be fair, what I was originally advocating for in my comment was more like Debian's 'any' wildcard, which is not quite as strong as the assertion that the package is completely architecture-independent. I would say that a specific tag for architecture-independent builds actually improves the situation: explicitly acknowledging the assumption that exotic architectures will never be an issue. Of course, as your sibling comment mentions, the interpreter is still part of the closure in Nix, so maybe this is incompatible with the existing choices made in the Nix ecosystem.