adding nixpkgs test workflow

[AtilaSaraiva]

Hello again!

As mentioned in my comment at issue #45, it is possible to add a new workflow that actually tries to build deepwave with nix. This should help avoiding problems the nixpkgs derivation having tests fail with each PR.

[ar4]

Nice! Thank you for doing this.

I have never used Nix before. On this line you specify a version of Deepwave. In the example on the Nix wiki they don't specify a version, but do specify a source. Is there an advantage to specifying a version?

The Actions documentation seems to use the syntax on: [push, pull_request] to specify multiple triggers.

Version 3 of the GitHub checkout Action is available. Is there a reason to prefer v2.4.0?

Interestingly, the testing seems to take longer with this Nix approach. The regular Action only takes about 26 minutes to run all of the tests, but the tests take 37 minutes in this Nix Action. It seems to be installing a recent version of GCC (11.3), so poor optimisation is probably not the cause.

[AtilaSaraiva]

No problem!

Maybe the wiki is outdated, but now there is a need to specify the version, look what happens when I don't:

$ nix-build
error: attribute 'version' missing

       at /nix/store/8lvs5f6qw3p7rj8rjg293y353qac9qyq-n147730f80lz7smljqxjzyfch62imgix-source/pkgs/development/interpreters/python/mk-python-derivation.nix:30:28:

           29|
           30| { name ? "${attrs.pname}-${attrs.version}"
             |                            ^
           31|
(use '--show-trace' to show detailed location information)

you can always put version="master"; though.

As for the syntax of the github actions and the checkout version, I simply copied the example config from the install nix workflow haha, I will abide by your suggestions. I'm quite new to writing workflows.

As for the speed of the job, I have no clue why it is slower. As a wild guess, I figure that this could be happening because python has optimizations turned off by default on nix, to ensure reproducibility. On my machine it is quite fast specially because it can use multiple cores, and I'm confident that the derivation (the default.nix file) is optimized to close to maximum performance without taking the python optimizations into account. I will check how we could enable those to test if there is a significant performance increase. but do keep in mind that the optimized python will have to be compiled. Another thing that could be happening is some sort of I/O bottleneck since idk how optimized for nix this ubuntu image is, but there isn't a nixos base image for github actions for us to test.

[ar4]

I also don't have a lot of experience writing workflows :-) Ah, yes, you're probably right about the speed being related to reproducibility. We probably don't need to worry about it, but I was just curious about why it was slower. Thank you again for doing this. I'll make sure that it passes before making the next release.

[AtilaSaraiva]

I'm pushing a test commit for us to investigate the possibility of using a optimized python. However, this could even take longer because of the python compilation. One alternative is to use cachix-action to cache the python build between workflow runs, I can even pin a nixpkgs revision so that it doesn't change the python derivation too often.

For us to use the cachix-action workflow we can follow this tutorial: nix.dev/tutorials/continuous-integration-github-actions. For it to work a cachix account can be created (it would be better for you to do that part), and a auth key should be added to the repository secrets, then I'd only add the cachix config.

This usage of the cachix even has the potential of reducing the time taken to download dependencies since they will be shared between workflow runs.

[ar4]

Pytest reports how long it took to run the tests, so I think we should be able to see if the optimised Python ran them faster, even if the overall Action takes longer (due to the Python compilation). If the tests do run faster, so we have solved the mystery, then I think we can probably go back to just using Nix's default Python. A few minutes longer to run the Action is not a problem, and reproducibility is probably a good idea. What do you think?

[AtilaSaraiva]

Yeah, I agree, it is nice to have the reproducibility stuff to ensure that if the tests pass here they will pass for everyone with nix.

[ar4]

It looks like it took 43 minutes to run the Nix Action with the optimised Python, so not any faster, but interestingly I see that in your run of the regular Action the tests also took 44 minutes, so maybe something else has changed recently that is causing it to run more slowly (since the tests ran consistently in around 26 minutes in the few commits since I last changed the code), such as some other package being updated or GitHub switching to slower instances.

[AtilaSaraiva]

Interesting, so mistery solved haha. I will drop the last commit then for us to rollback to the reproducible build of python.

[ar4]

I slightly increased the tolerance for that test (from 1e-8 to 5e-8) and now it passes, so have merged it. Thank you again.

[AtilaSaraiva]

No problem whatsoever! Thank you for being so nice about this whole thing, maintainer and dev relationships are not always this cool, haha.

[ar4]

Hello @AtilaSaraiva

In response to some users having difficulty with the way Deepwave was previously distributed, which involved code being compiled on their system, I have now switched to using GitHub Actions to precompile the code into shared/dynamic libraries that I now distribute. I hope that this will avoid problems for most users. I am not sure how this affects your Nix package, though. If you have any questions about how it works, or suggestions on how to improve it (including how it could be made easier for you to maintain the Nix package) please let me know.

[AtilaSaraiva]

Hey! Oh I will to check it out, it might be fine if I post process these bonaries, are u compiling for linux? If yes then I might be able to make it work.

…

On Thu, Jul 27, 2023, 08:33 Alan Richardson ***@***.***> wrote: Hello @AtilaSaraiva <https://github.com/AtilaSaraiva> In response to some users having difficulty with the way Deepwave was previously distributed, which involved code being compiled on their system, I have now switched to using GitHub Actions to precompile <https://github.com/ar4/deepwave/blob/master/.github/workflows/build.yml> the code into shared/dynamic libraries that I now distribute. I hope that this will avoid problems for most users. I am not sure how this affects your Nix package, though. If you have any questions about how it works, or suggestions on how to improve it (including how it could be made easier for you to maintain the Nix package) please let me know. — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHBHMNIDMCICRYF6UPHN46TXSJNZDANCNFSM54BQ2F2A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ar4]

It currently compiles shared/dynamic libraries for Linux (x86_64 and CUDA), Windows (x64_64 and CUDA), and MacOS (x86_64 and ARM64).

[AtilaSaraiva]

I might be able to do something, but it would be cool if there was a way to optionally build the package in the old way. Em qui., 27 de jul. de 2023 às 07:18, Alan Richardson < ***@***.***> escreveu:

…

It currently compiles shared/dynamic libraries for Linux (x86_64 and CUDA), Windows (x64_64 and CUDA), and MacOS (x86_64 and ARM64). — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHBHMNJLJRPQGQJMAKWH2WTXSJTB5ANCNFSM54BQ2F2A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Átila

[ar4]

The way that I build it at the moment is to enter the src/deepwave directory and call the compiler using the commands in https://github.com/ar4/deepwave/blob/master/src/deepwave/build_linux.sh . I then return to the base directory and run `pip install .`. Is it possible to do that with Nix? If not, could the Nix package instead just run `pip install deepwave` to use the precompiled code from PyPI, or would that not match the Nix philosophy?