Conversation
khunt-tiltfive
left a comment
There was a problem hiding this comment.
Hope you don't mind a couple of comments inline. I'm not familiar with Nix, so I've not considered that side of things.
(Disclaimer - I work for Tilt Five, but my comments here don't represent an official position or any kind of endorsement).
|
My comments have been resolved, thank you. Cursory inspection looks ok, but I'm not qualified to comment on nix things. |
|
Ah, it seems like OfBorg refuses to build/test unfree packages? |
|
@ofborg eval |
nixos/modules/hardware/tiltfive.nix
Outdated
There was a problem hiding this comment.
| with lib; |
There was a problem hiding this comment.
There's a bunch of mkXXX calls in there. Why is this with lib; a problem? Should it be nested somewhere deeper? Should I use lib.mkXXX explicitly?
There was a problem hiding this comment.
with is an anti-pattern too ingrained in old code. Indeed I am cleaning up this mess, and it is hard as hell.
Why is this with lib; a problem?
withworks in a similar manner of#include <>from C language, bringing to the scope of your code a whole bunch of things you are not using. This is not so harmful in Nix because it uses lazy evaluation, however it can be a pain for static analysis, and can be worse if you accidentally invokes a functionality from it.withworks in unexpected ways when used more than once.- its scoping rules are obscure: Scoping is unintuitive nix#490
Should I use lib.mkXXX explicitly?
Yes.
Another less verbose alternative is to substitute from with lib; to inherit (lib) mkXXX mkXXY mkXXZ . . .;
(Usually @SuperSandro2000 prefers the explicit lib. usage, but I have no strong opinions between the options above.)
There was a problem hiding this comment.
Another less verbose alternative is to substitute from
with lib;toinherit (lib) mkXXX mkXXY mkXXZ . . .;
where you need to maintain a list of used functions which is also not that great.
There was a problem hiding this comment.
| dest=$out/opt/tiltfive/control-panel | |
| pushd opt/tiltfive/control-panel | |
| mkdir -p $dest/data | |
| cp -r data/* $dest/data/ | |
| mkdir -p $dest/lib | |
| install -Dm755 lib/* $dest/lib/ | |
| install -Dm755 control_panel $dest/ | |
| popd | |
| dest=$out/opt/tiltfive/control-panel | |
| pushd opt/tiltfive/control-panel | |
| mkdir -p $dest/data $dest/lib | |
| cp -r data/* $dest/data/ | |
| install -Dm755 lib/* $dest/lib/ | |
| install -Dm755 control_panel $dest/ | |
| popd |
There was a problem hiding this comment.
I spersonally find the version with whitespace more readable. Is there a concrete style recommendation to avoid newlines in this case?
There was a problem hiding this comment.
nope.
but using two white lines makes no sense
There was a problem hiding this comment.
Do not parameterize pname
There was a problem hiding this comment.
nixpkgs $ grep -r '{pname}.desktop' | wc -l
90
This seems to be a fairly common pattern in nixpkgs. Is there a concrete style recommendation against this?
There was a problem hiding this comment.
This seems to be a fairly common pattern in nixpkgs.
That doesn't mean anything since there is lots of code which wasn't touched in a good amount of time and should be updated.
There was a problem hiding this comment.
Right, but what is the reason to not do this? I'll gladly change things around, but I'd prefer to know what is the reasoning behind this so that I can then explain the same thing to others :).
There was a problem hiding this comment.
pname could be changed with a prefix which does not break with rec but with finalAttrs. Also it increases code complexity and pname does not change often.
There was a problem hiding this comment.
This seems to be a fairly common pattern in nixpkgs. Is there a concrete style recommendation against this?
90 occurrences in a codebase of 80k+ packages? This is not "fairly common".
Right, but what is the reason to not do this?
- it creates a useless dependency link, making static debugging a little more difficult.
- sometimes
pnameis not perfectly parameterizable. E.g. the GitHub repository ofopenmsxisopenMSX/openMSX. What we should do? Pass it under a obfuscated combination of string splitting? - being effectively a constant, using
pnamemakes no real difference to understand the code. It is just harder to read and conveys nothing useful.
There was a problem hiding this comment.
This seems to be a fairly common pattern in nixpkgs.
That doesn't mean anything since there is lots of code which wasn't touched in a good amount of time and should be updated.
| description = "Tilt Five™ Glasses SDK"; | ||
| homepage = "https://docs.tiltfive.com/index.html"; | ||
| # Non-redistributable. See: license_sdk_en.txt, 2.1.2. | ||
| license = with licenses; unfree; |
There was a problem hiding this comment.
| license = with licenses; unfree; | |
| license = licenses.unfree; |
| in | ||
| { | ||
| options.hardware.tiltfive = { | ||
| enable = mkEnableOption (lib.mdDoc "tiltfive driver and service"); |
Tilt Five™ Glasses are an AR headset.
This packages its driver (control panel, service) and SDK. It also implements a NixOS module which installs the driver.
Description of changes
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Fixes: #235734
Fixes: #235736