Add nix package and environment files

[imincik]

The main goal of this PR is to demonstrate some interesting features which Nix can provide to devs and users and get a feedback.

What does this PR do?

Add Nix files which will provide some Nix super powers to GDAL project.

1. Launch development environment containing all build dependencies using single command
2. Launch user environment containing CLI and Python from any Git branch, tag or revision
3. Other unique Nix features

Instructions

• Install Nix
  (learn more about this installer)

$ curl --proto '=https' --tlsv1.2 -sSf \
    -L https://install.determinate.systems/nix \
    | sh -s -- install

• Launch GDAL development environment (run from root source code directory)

$ nix develop

Welcome to a GDAL development environment !
Build GDAL using following commands:

 1.  cmake \
       -DCMAKE_INSTALL_PREFIX=/home/imincik/Projects/osgeo/gdal/code/app \
       -DUSE_CCACHE=ON
 2.  make -j16
 3.  make install

Run tests:

 1.  make quicktest
 2.  make test

Note: run 'nix flake update' from time to time to update dependencies.

Run 'dev-help' to see this message again.

• Launch GDAL user environment containing GDAL CLI and Python environment

# test this PR
$ nix develop github:imincik/gdal/nix#user

# once PR is merged
$ nix develop github:OSGeo/gdal#user

OR

# once PR is merged
$ nix develop github:OSGeo/gdal/<TAG/BRANCH/REVISON>#user

Welcome to a GDAL user environment !
Run GDAL CLI:

 1.  gdalinfo --help
 2.  ogrinfo --help

Run Python interpreter:

 1.  python -c 'import osgeo; print(osgeo)'

Note: run 'nix flake update' from time to time to update dependencies.

Run 'user-help' to see this message again.

• Install GDAL package

# test this PR
$ nix profile install github:imincik/gdal/nix#gdal

# once PR is merged
$ nix profile install github:OSGeo/gdal#gdal

OR

# once PR is merged
$ nix profile install github:OSGeo/gdal/<TAG/BRANCH/REVISON>#gdal

More about Nix and this idea in My FOSS4G Tartu talk

[rouault]

• Is it customary that Nix specific files end up in upstream repositories ?
• How can we ensure that this won't rot up over time? Nobody in the core team AFAIK has expertise on Nix

[hobu]

I'm not enthusiastic about this PR at all. The project doesn't maintain Debian dkpg files, conda forge yml configuration, or homebrew config inside the main repository. Why should we start with Nix? This PR doesn't add any CI to verify that it even works.

As @rouault said, build configurations rot over time, and the people who would maintain it are not core GDAL devs. What's more difficult is what is GDAL supposed to do with our maintenance branch strategy in relation to Nix config? Backport everything? 🤮

Where are users supposed to submit bugs about GDAL's Nix config? GDAL repo I guess according to this PR, but what if the issue is really a Nix or additional dependency's issue? It's related to GDAL's config, but it isn't going to be fixed or adjudicated here.

[imincik]

• Is it customary that Nix specific files end up in upstream repositories ?

Yes, this makes a sense if they provide some additional value. Like the dev and user environments + ability to run a program directly from git.

• How can we ensure that this won't rot up over time? Nobody in the core team AFAIK has expertise on Nix

I would add a CI test, which can run on weekly schedule, to test the package and other features. package.nix as implemented in this PR is very close to what we have in nixpkgs, but can be simplified.

I apologize, I wanted to submit this PR as a draft.

[imincik]

Thank you for feedback.

I'm not enthusiastic about this PR at all. The project doesn't maintain Debian dkpg files, conda forge yml configuration, or homebrew config inside the main repository. Why should we start with Nix?

I understand. The difference between Nix and all other package managers are the features it can provide.

For example, ability to run or install a program straight from git in any revision. This is a very unique feature and can work only if nix files are present in repo.

nix run github:<OWNER>/<REPO>/<REVISION>#<PROGRAM>

OR

nix profile install github:<OWNER>/<REPO>/<REVISION>#<PROGRAM>

There are many other unique features which Nix can provide. That's the reason why it can't be directly compared to other package managers.

This PR doesn't add any CI to verify that it even works.

Yes, CI job should be added. It can run weekly.

[dbaston]

What advantage does this provide over the the Docker containers provided for developers (https://gdal.org/development/dev_environment.html#docker) and users (https://gdal.org/download.html#containers) ?

[imincik]

I changed this PR to a draft.

My main intention with this PR is to demonstrate some interesting features which Nix can provide to devs and users and get a feedback.

[imincik]

What advantage does this provide over the the Docker containers provided for developers (https://gdal.org/development/dev_environment.html#docker) and users (https://gdal.org/download.html#containers) ?

1. All software runs natively is some kind of virtual shell environment (like Python virtualenv, but for all software). This means less complexity comparing to container.

2. Nix environment is reproducible (very near to bit-to-bit). Containers are usually repeatable at most.

3. Nix environment is always automatically updated to the exact version specified in current git revision. This helps with troubleshooting, debugging or testing (for example when running git bisect.

4. Much easier testing of development versions. Just ask the user to run

nix run github:<OWNER>/<REPO>/<GIT-COMMIT-OR-BRANCH>#<PROGRAM>

nix shell github:<OWNER>/<REPO>/<GIT-COMMIT-OR-BRANCH>#<SHELL>

5. Much better control over whole dependency tree and dependency customization options comparing to containers.

6. And very fast initiation of whole dev environment using single nix develop command. No software except Nix is needed to start hacking.

[imincik]

This PR doesn't add any CI to verify that it even works.

@hobu , CI job added.

[rouault]

(Travis CI failure unrelated. Broke on master too due to upgrade of the image by the provider)

[rouault]

@imincik We discussed that topic in today's monthly GDAL meeting maintainer and there's a general lack of enthusiasm about including Nix specific files in GDAL upstream. As @hobu mentionned, this goes against the practice of all other existing packaging systems, and while Nix has certainly its own strong points compared to other solutions, that doesn't entirely justify making an exception for it. Especially since there would be duplicated maintenance of the recipe inside GDAL and the one at https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/gdal/default.nix , which seems to be a quite tedious approach for the people that would have to maintain them.

[imincik]

Thanks for your time and feedback and I am closing this PR.