When writing a shebang script, you expect your path to be relative to
the script, not the cwd. We previously handled this correctly for
relative file paths, but not for expressions.

This handles both -p & -E args. My understanding is this should be
what we want in any cases I can think of - people run scripts from
many different working directories. @edolstra is there any reason to
handle -p args differently in this case?

Fixes NixOS#4232

Fixes NixOS#10395.

Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>

Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>

…' into more-nix-shell

It is unclear to me why this worked when not in a VM test, but the
explanation would be in the part of nix-shell we're getting rid of
with the devShell attribute.

I'm sick of receiving an email about this every 30 minutes.

Forgot to include `config-expr.hh` in two places

Use a meson "generator" to deduplicate `.gen.hh` creation

Co-Authored-By: Qyriad <qyriad@qyriad.me>

…tatus-check

Remove the Hydra status check workflow

Package the Nix CLI with Meson

Remove reference to check-hydra-status

…-in-tarballs

…tarballs

Support hardlinks in tarballs

Ported from NixOS/nixpkgs#326172

Co-authored-by: Emily <vcs@emily.moe>

Remove unused InstallableFlake::getFlakeOutputs()

This refactoring allows the symbol table to be stored as something
other than std::strings.

…tring-view

SymbolStr: Remove std::string conversion

The move assignment was implicitly generated and used in

    src/libstore/build/goal.cc:90:22:
       90 |             this->ex = std::move(*ex);

Clang warns about this generated method being deprecated, so making
them explicit fixes the warning.

Progress on NixOS#5638

There are still a global fetcher and eval settings, but they are pushed
down into `libnixcmd`, which is a lot less bad a place for this sort of
thing.

Continuing process pioneered in
52bfccf.

…-flake-settings

No global settings in `libnixfetchers` and `libnixflake`

Fix warnings and optimize includes

On some systems, previous usage of `match` may cause a stackoverflow
(presumably due to the large size of the match result). Avoid this by
(ab)using `replaceStrings` to test for containment without using
regexes, thereby avoiding the issue. The causal configuration seems to
be the stack size hard limit, which e.g. Amazon Linux sets, whereas most
Linux distros leave unlimited.

Match the fn name to similar fn in nixpkgs.lib, but different
implementation that does not use `match`. This impl gives perhaps
unexpected results when the needle is `""`, but the scope of this is
narrow and that case is a bit odd anyway.

This makes for some duplication-of-work as we do a different
`replaceStrings` if this one is true, but this only runs during doc
generation at build time so has no runtime impact.

See NixOS#11085 for details.

It was complaining *a lot*, with dozens of MB of logs.

Fix stackoverflow during doc generation

…ettings

Remove unused `operator<=>`'s that darwin can't generate

- Fix eval cache not being persisted in `nix develop` (since NixOS#10570)
- Don't attempt to commit cache transaction if there is no active transaction, which will spew errors in edge cases
- Drive-by: trivial typo fix

Known behavior changes:

- `MemorySourceAccessor`'s comparison operators no longer forget to
  compare the `SourceAccessor` base class.

Progress on NixOS#10832

What remains for that issue is hopefully much easier!

…arator

Remove `comparator.hh` and switch to `<=>` in a bunch of places

packaging: Set darwinMinVersion to fix x86_64-darwin build

…gsSep

... initial empty strings.

The tests pass, which is encouraging.

The buggy version was previously renamed to
dropEmptyInitThenConcatStringsSep

… docs

These are non-critical, so their behavior is ok to change.
Dropping empty items is not needed and usually not expected.

…attr

The empty attribute name should not be dropped from attribute paths.
Rendering attribute paths with concatStringsSep is lossy and wrong,
but this is just a first improvement while dealing with the
dropEmptyInitThenConcatStringsSep problem.

Bug not reported in 6 years, but here you go.

Also it is safe to switch to normal concatStringsSep behavior
because tokenizeString does not produce empty items.

The sigs field is produced by tokenizeStrings, which does not return
empty strings.

…ot empty

…ty not feasible

I don't think it's completely impossible, but I can't construct
one easily as derivationStrict seems to (re)tokenize the outputs
attribute, dropping the empty output.

It's not a scenario we have to account for here.

… not empty

…not be empty

(System) features are unlikely to be empty strings, but when they
come in through structuredAttrs, they probably can.
I don't think this means we should drop them, but most likely they
will be dropped after this because next time they'll be parsed with
tokenizeString.

TODO: We should forbid empty features.

…atures do not render as empty strings

…rgs are never empty

…hould not be empty

…ributes with empty names

Empty attributes are probably not well supported, but the least we
could do is leave a hint.
Attribute path rendering and parsing should be done according to
Nix expression syntax in my opinion.

…e not empty

…"" "" "" build

Garbage in, error out. Experimental CLI. Zero derivations given.

…rsion is not empty

The law has nothing to do with this, although I do feel like a
badass when I mess with the config.
I'm a conf artist.

…enizeString are not empty

…as already harmed

Considering that `value` was probably parsed with tokenizeString
prior, it's unlikely to contain empty strings, and we have no
reason to remove them either.

It's still wrong, but one step closer to correct.
Not that anyone should use "" or "." in their PATH, but that is not
for us to intervene.

... but if they are, I'd like to see at least a hint of it so that
I'd know to fix it.

It's usually harmless, if it occurs at all.