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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mblaze: fix mcom to use file utility. #94881

Merged
merged 3 commits into from May 31, 2021

Conversation

guillaumecherel
Copy link
Contributor

Motivation for this change

mcom needs the file utility when attaching document with mcom -attach bla.txt.

Things done

I wrapped mcom to add file to PATH.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • 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 nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@guillaumecherel
Copy link
Contributor Author

This is my first PR to nixpkgs. I welcome any comment!

Copy link
Member

@alyssais alyssais left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

The commit seems to be using an email address that isn’t registered to your GitHub account. Is that intentional?

@guillaumecherel
Copy link
Contributor Author

There it is. Thanks for the tips! Ideally, the "full wrapping" should be done for all the other executables in the package, but I don't have time to take care of that right now.

Copy link
Member

@alyssais alyssais left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you squash this into a single commit? And I think your email address might still not be right — see how GitHub doesn’t render commits with your avatar.

@@ -1,11 +1,13 @@
{ stdenv, lib, fetchFromGitHub, fetchpatch, libiconv, ruby ? null }:
{ stdenv, lib, fetchFromGitHub, fetchpatch, libiconv, ruby ? null, makeWrapper, coreutils, file, gawk, gnugrep, gnused }:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe break this long line at 80 or something? And optional arguments (ruby) usually come last.

@@ -26,6 +28,9 @@ stdenv.mkDerivation rec {
install -Dm644 -t $out/share/zsh/site-functions contrib/_mblaze
'' + lib.optionalString (ruby != null) ''
install -Dt $out/bin contrib/msuck contrib/mblow
wrapProgram $out/bin/mcom \
--prefix PATH : ${lib.makeBinPath [ gawk coreutils file gnugrep gnused ]} \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe order them alphabetically? Not a big deal though.

@guillaumecherel
Copy link
Contributor Author

Alright, I think my email is fixed now. I also did the formatting, and wrapped all the executables.

I also squashed my commits into a single one locally, but now my local branch has diverged from my github branch and I can't push anymore. Should I create a new branch an redo the pull request?

@guillaumecherel
Copy link
Contributor Author

I think it's done, all commits squashed into one.

Copy link
Member

@alyssais alyssais left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your patience! We’re getting there!

--prefix PATH : ${lib.makeBinPath [
coreutils file gawk gnugrep gnused less nano
]} \
--set EDITOR nano
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will override the user’s editor choice, which is an impurity we should definitely allow. The only reason I suggested it for testing is that your normal EDITOR would probably not be a full path, and we were emptying PATH. Similarly, we probably shouldn’t include less in the wrapper, because a user might configure a different PAGER. Overall, it comes down to whether something is an implementation detail (like awk) or whether something is a property of the environment the program is running in that should be customisable (like the editor or pager). Does that make sense?


for x in `find $out/bin "(" -type f -executable ")" -or -type l`
do
wrapProgram $x \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should probably only wrap the programs that are shell scripts. The others probably don’t need it, and Oulu feel weird to me to wrap programs that didn’t need it.

It would also be totally fine to decide that the others are out of scope for this PR, and to just concentrate on mcom for now, and fix the others later or not at all. Up to you — depends how quickly you want to get this over with!

@@ -1,11 +1,14 @@
{ stdenv, lib, fetchFromGitHub, fetchpatch, libiconv, ruby ? null }:
{ coreutils, fetchFromGitHub, fetchpatch, file, gawk, gnugrep, gnused, less,
lib, libiconv, makeWrapper, nano, stdenv, ruby ? null}:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conventionally, the comma goes at the start of the line, and then the } on a line on its own:

{ foo, bar
, baz
}:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your review. I'll be away for a week and will get back on this then.

@guillaumecherel guillaumecherel force-pushed the fix/mblaze-needs-file branch 2 times, most recently from a9c7461 to b5796f4 Compare August 21, 2020 14:24
@guillaumecherel
Copy link
Contributor Author

Thanks to you for your careful review and advices.

As you suggested, I switched back to wrapping only the executable mcom for now, removed the EDITOR variable setting, removed the dependencies on less and nano and made the little formatting request. Let me know about anything else.

@zowoq
Copy link
Contributor

zowoq commented Aug 22, 2020

@ofborg eval

@guillaumecherel
Copy link
Contributor Author

I realized that the wrapping the script mcom broke the behaviours of the symlinks to it mrep, mbnc and mfwd. The reason is that mcom's behaviour depends on the value of $0, which normally changes when mcom is called through one of its symlink. The wrapper broke this. I wrapped mcom and its symlinks to fix this.

# url = "https://github.com/leahneukirchen/mblaze/commit/53151f4f890f302291eb8d3375dec4f8ecb66ed7.patch";
# sha256 = "1mcyrh053iiyzdhgm09g5h3a77np496whnc7jr4agpk1nkbcpfxc";
# })
# ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be deleted rather than commented out.

# designed to be run directly or via symlinks such as mrep. Using
# symlinks changes the value of $0 in the script, and makes it
# behave differently. When using the wrapProgram tool, the resulting
# wrapper breaks this behaviour. The following wrappers preserve it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting! The argv0 option to wrapProgram doesn’t fix this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've learned it doesn't work for scripts with shebangs. It does if you remove the shebang, but then you have to explicitly pass it to bash everytime you want to run it…

@guillaumecherel
Copy link
Contributor Author

The master branch now has mblaze updated to version 1.0. Closing this pull request.

@justinlovinger
Copy link
Contributor

@guillaumecherel It looks like mcom still needs file and other binaries wrapped in mblaze 1.0. Would you like to merge the mblaze 1.0 update and re-open this pull request (or open a new pull request to fix mcom off of the latest nixpkgs)?

@guillaumecherel
Copy link
Contributor Author

Indeed, there it is!

@guillaumecherel
Copy link
Contributor Author

It seems like this pull request has stalled even though I believe made the requested changes. Is there anything else to do on my part?

guillaumecherel and others added 2 commits March 22, 2021 09:34
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
@justinlovinger
Copy link
Contributor

@SuperSandro2000 Does this look good to you now? It would be very nice to have a fully working mblaze.

@github-actions
Copy link
Contributor

Successfully created backport PR #125015 for release-21.05.

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

6 participants