Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

bitscope: refactored to expose to nixpkgs-lint #33834

Closed
wants to merge 1 commit into from

Conversation

vidbina
Copy link
Contributor

@vidbina vidbina commented Jan 13, 2018

Motivation for this change

The linter (nixpkgs-lint) was not able to find the bitscope packages
because I forgot to recurseIntoAttrs the bitscope suite set. Furthermore, I inherit the
meta and name attributes from the package builder helper. This fixes
a naming problem since the name of the derivation was formerly set to
the attrs.toolName which didn't postfix the version, whereas nix
packages are required to adhere to the ${PACKAGENAME}-${VERSION}
pattern.

In order to keep the produced FHSEnv binary's name short and sweet and produced it with a versionless name and subsequently merged the versioned-name into the resulting derivation.

Not sure if I'm doing some weird 馃挬... if so, please yell at me so I can fix that and developed a good mental association from preventing me from doing the same in the future 馃槈.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

The linter (nixpkgs-lint) was not able to find the bitscope packages
because `recurseIntoAttrs` was not applied to the suite's set.

The name supplied to `buildFHSUserEnv` produces a binary that
corresponds to the binary names in the deb packages (e.g.: bitscope-dso,
bitscope-chart, bitscope-logic, etc), however; this name does not
constitute a valid nixpkgs name. Valid nixpkgs names satisfy the
`/(.*)(-[0-9].*)$/` pattern, therefore a valid name is merged into the
derivation produced by `buildFHSUserEnv`.
@bjornfor
Copy link
Contributor

Applied to master (b986078).

I think it's a bit weird that the store path (still) lacks a version number.

@bjornfor bjornfor closed this Jan 14, 2018
@vidbina
Copy link
Contributor Author

vidbina commented Jan 14, 2018

Oh shoot. In the buildFHSUserEnv call I set the name attribute to toolName which probably explains the pathname. After the derivation is produced, I override the name to include the version. I did this to ensure the produced bin for the FHS user env was equal to toolName. I couldn't find anything on producing a FHS env through buildFHSUserEnv where I could specify the name and the destination as is possible with writeTextFile.

I though about using a writeTextFile call to set the name and destination of the binary to whatever I want and then, inside that script, fire up the FHS env, but felt that was jumping through too many hoops for something that should be simple.

How would you have tackled this?

@bjornfor
Copy link
Contributor

Like this: #33889

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants