Re-enable use without flakes

[jacg]

The shell.nix flake-compat shim was removed, because I thought nobody would need it, and that it was unnecessary noise. Turns out I was wrong.

[jacg]

@gonzaponte could you please check whether this works for you?

[gonzaponte]

Remind me, what should I do with this? I ran nix-shell, which took me to the configured shell, but I don't see a difference with the regular shell.

[jacg]

It should provide you with all the dependencies that you need to develop and run the code. Given that you've already got most of this stuff by other means, you won't notice much difference, apart from the versions (maybe) and the locations, which should all be in the nix store, in the shell.

If you hadn't installed just yet, it should be available now. If you didn't have clangd before (for LSP in your IDE), it should be available now. If you were using a different version of Geant4, it should now be configured to use the 'correct' one.

Oh, and the compiler is clang, so all those annoying gcc shadowing warnings disappear even before #12 :-)

Furthermore, if you have direnv, it should automatically switch the environment when you enter/leave the directory, and when you change to a commit which has a different set of dependencies.

[gonzaponte]

Hmm. I am pretty sure I had just and clang before. After I had run nix develop when you first told me to. Does this make sense?

[jacg]

Yes. nix develop is, sort of, the new nix command equivalent of nix-shell.

You said that your OS was too old to have a modern Nix, so you couldn't use flakes. The shell.nix that was added here gives you (at least) two things:

1. nix-shell as an alternative for nix develop
2. The ability to use direnv (without flakes).

[gonzaponte]

direnv still tries to use the flake:

>>> direnv allow
direnv: loading ~/path/to/nain4/.envrc
direnv: using flake
environment:655: use_flake: command not found

[jacg]

Which is hard to believe, given that in the .envrc that comes with that commit, there is no use_flake!

$ git show 9004e59:.envrc
if nix flake show &> /dev/null; then
  use flake
else
  use nix
fi

[gonzaponte]

I almost forget about this. Is there anything I can do to debug?
On a fresh shell, I do:
setup nix, which runs:

if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
  . '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh'
fi

eval "$(direnv hook bash)"

then cd nain4 and I get the output of my previous comment.

[jacg]

Well, first of all, show me the output of cat .envrc.

[jacg]

And direnv --version.

[gonzaponte]

As you say, there is no use_flake

if nix flake show &> /dev/null; then
  use flake
else
  use nix
fi

direnv version 2.21.2

[jacg]

echo use nix | cat > .envrc and see what happens. Hopefully you'll be asked to direnv allow.

[gonzaponte]

$ direnv allow
direnv: loading ~/path/to/nain4/.envrc
direnv: using nix
warning: Git tree '/path/to/nain4' is dirty
direnv: export +AR +AS +CC +CMAKE_INCLUDE_PATH +CMAKE_LIBRARY_PATH +CMAKE_PREFIX_PATH +CONFIG_SHELL +CXX +DETERMINISTIC_BUILD +G4ENSDFSTATEDATA +G4LEDATA +G4LEVELGAMMADATA +G4NEUTRONHPDATA +G4PARTICLEXSDATA +G4RADIOACTIVEDATA +G4SAIDXSDATA +G4_DIR +G4_EXAMPLES_DIR +GETTEXTDATADIRS_FOR_BUILD +HOST_PATH +IN_NIX_SHELL +LD +LD_LIBRARY_PATH +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_BUILD_CORES +NIX_BUILD_TOP +NIX_CC +NIX_CC_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_CFLAGS_COMPILE +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_LDFLAGS +NIX_STORE +NM +OBJCOPY +OBJDUMP +PYTHONHASHSEED +PYTHONNOUSERSITE +PYTHONPATH +QMAKE +QMAKEMODULES +QMAKEPATH +QT_QPA_PLATFORM_PLUGIN_PATH +RANLIB +READELF +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +TEMP +TEMPDIR +TMP +TMPDIR +XML_CATALOG_FILES +_PYTHON_HOST_PLATFORM +_PYTHON_SYSCONFIGDATA_NAME +__structuredAttrs +buildInputs +buildPhase +builder +cmakeFlags +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +mesonFlags +name +nativeBuildInputs +out +outputs +patches +phases +preferLocalBuild +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~PATH ~XDG_DATA_DIRS

but no errors.

[jacg]

I suspect that use flake ends up calling use_flake, though I can't immediately find solid evidence for it.

In which case, the puzzle is why it's gone down that branch, if you claim that you cannot use flakes on your system. What happens when you do nix flake show?

direnv allow [...] but no errors.

And now that shell should have all the flake-specified dependencies available.

Anyway, we still need to get the general .envrc working. The other hypothesis is that your direnv is so old that use_flake hasn't been added to its standard library yet ... yup:

• Your version was released on 2020-05-08: https://github.com/direnv/direnv/releases/tag/v2.21.3
• use_flake was added on 2021-11-08: https://github.com/direnv/direnv/blame/b51ab1216b22df689243d5cc665154ca24282cbe/stdlib.sh#L1266

[gonzaponte]

$ nix flake show
warning: Git tree '/path/to/nain4' is dirty
git+file:/path/to/nain4
├───devShell
│   ├───aarch64-linux: development environment 'G4-examples-devenv'
│   ├───i686-linux: development environment 'G4-examples-devenv'
│   ├───x86_64-darwin: development environment 'G4-examples-devenv'
│   └───x86_64-linux: development environment 'G4-examples-devenv'
└───packages
    ├───aarch64-linux
    │   ├───default: package 'geant4-11.0.4'
    │   └───geant4: package 'geant4-11.0.4'
    ├───i686-linux
    │   ├───default: package 'geant4-11.0.4'
    │   └───geant4: package 'geant4-11.0.4'
    ├───x86_64-darwin
    │   ├───default: package 'geant4-11.0.4'
    │   └───geant4: package 'geant4-11.0.4'
    └───x86_64-linux
        ├───default: package 'geant4-11.0.4'
        └───geant4: package 'geant4-11.0.4'

your direnv is so old that use_flake hasn't been added to its standard library yet

Yes, this I knew. When I started working on this we discussed it, and that's why you opened this issue (IIRC).

[jacg]

Ah, I understood that you couldn't use flakes¹ because your Nix was too old, because your OS was too old.

But, if it's direnv that's too old ... then install a newer direnv with Nix.

Footnotes

1. which is clearly not the case, given the output of nix flake show ↩

[gonzaponte]

The latest release of direnv for my OS (Ubuntu 20) is older than the one required for use_flake.

[jacg]

nix shell/build/install nixpkgs#direnv ... as discussed here.

[gonzaponte]

Nix is still black magic to me.

install is not a recognized command. shell and build did work and I can now sort of have version 2.32.3.

[jacg]

Mea culpa: it should be nix profile install, not nix install. My excuse is that I don't ever use it, because I don't think it should exist, because it's mutates state, and the whole point of Nix is to avoid mutating state.

[gonzaponte]

That works completely fine. Thanks! Hopefully I will get around to update my OS as well...

[jacg]

update my OS

One of the great joys of NixOS is that OS upgrades don't cause the terror and anguish that they do on other OSes. On NixOS, an OS upgrade is just a switch to a different declaration of what your system should look like. If you don't like the new one, or it's broken in some way, it's completely trivial to go back to the previous one. All because it doesn't modify any state at all, it merely reifies declarations. With other OSes and package managers, when you install or uninstall something, you modify the state: in general, in complex systems such as OSes, it's impossible to undo such modifications completely.

Yes, you can, for example, uninstall a package after having installed it, but it's pretty unlikely that you have returned to exactly the same state as you had to start with. Do this lots of times, and your OS is one huge, unreproducible mess.

Pre-nix, I was reluctant to try new packages, because I had been burned so many times by install-uninstall breaking something that worked before. With nix, nix shell nixpkgs#whatever installs whatever in this shell only. Exit the shell, and there is no trace of it left. Even whole system upgrades can be rolled back, guaranteed. Everything is isolated from everything else that it doesn't depend on explicitly: you cannot accidentally break A by installing B. You can have multiple versions of things installed and they cannot interfere with eachother. When you work on different projects which have different and even conflicting dependencies, this is a huge boon, especially if direnv-enabled.

In the long run, it's well worth the pain it takes to get started with Nix.