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

symfony-cli: add missing compilation flags #206149

Merged
merged 1 commit into from Dec 16, 2022

Conversation

charlycoste
Copy link

@charlycoste charlycoste commented Dec 14, 2022

Description of changes

I noticed that version displayed by the symfony-cli command line is always dev :
Capture d’écran du 2022-12-14 23-21-09

whereas official binaries from symfony-cli repository says 5.4.19, for instance.

Capture d’écran du 2022-12-14 23-48-45

I tried to figure out why and it’s actually due to some differences on compilation flags between official build and the current NixOS nix expression.

I tried to get closer of the official way, but without adding a build date to keep reproducibility.

I also added a simple check to be sure that the command can run.

Things done
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 23.05 Release Notes (or backporting 22.11 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
    • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
  • Fits CONTRIBUTING.md.

@drupol
Copy link
Contributor

drupol commented Dec 15, 2022

Hi, thanks for this!

Question, do you think it would be possible to use go realaser and have reproducible builds ?

@charlycoste
Copy link
Author

charlycoste commented Dec 15, 2022

Hi, thanks for this!

You are welcome.

Question, do you think it would be possible to use go realaser and have reproducible builds ?

I would not bet it. I don’t think it’s a kind of software with reproducibility in mind. But the truth is I can’t tell because I never used it. Anyway, I would prefer relying on nixpkgs’ buildGoModule as you already did and as suggested in the documentation

@drupol
Copy link
Contributor

drupol commented Dec 15, 2022

I would not bet it. I don’t think it’s a kind of software with reproducibility in mind. But the truth is I can’t tell because I never used it. Anyway, I would prefer rely on nixpkgs’ buildGoModule as suggested in the documentation

They do it on their side in the Github Action file: https://github.com/symfony-cli/symfony-cli/blob/main/.github/workflows/releaser.yml

@charlycoste
Copy link
Author

Just because they do that doesn't make them build in a reproducible way. Note they also add a build date… :p

@drupol
Copy link
Contributor

drupol commented Dec 15, 2022

Just because they do that doesn't make them build in a reproducible way. Note they also add a build date… :p

Fair enough ! I validated this PR, all good for me then.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-in-distress/3604/58

@SuperSandro2000 SuperSandro2000 merged commit 46c5a83 into NixOS:master Dec 16, 2022
ldflags = [
"-s"
"-w"
"-X main.version=${version}"
Copy link
Contributor

Choose a reason for hiding this comment

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

Are not these two different flags?

Suggested change
"-X main.version=${version}"
"-X" "main.version=${version}"

Copy link
Author

Choose a reason for hiding this comment

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

I don’t really know if it should be considered as two different flags. If we wanted to add something like main.channel it would result in :

ldflags = [
  "-s"
  "-w"
  "-X"
  "main.version=${version}"
  "-X"
  "main.channel=${channel}"
]

instead of :

ldflags = [
  "-s"
  "-w"
  "-X main.version=${version}"
  "-X main.channel=${channel}"
]

I really don’t know what is the best for NixOS

Copy link
Contributor

Choose a reason for hiding this comment

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

The question is whether it works if you run it in shell.

The stdenv.mkDerivation does not really support lists by default so currently, it will end up being run like go install "-ldflags=-s -w -X main.version=x.y.z -X main.channel=foo":

flags+=(''${ldflags:+-ldflags="$ldflags"})

But in the future, when we switch to structured attributes, it would be good if arguments would be properly split.

postInstall = ''
mv $out/bin/symfony-cli $out/bin/symfony
'';

# Tests requires network access
doCheck = false;
checkPhase = ''
$GOPATH/bin/symfony-cli
Copy link
Contributor

Choose a reason for hiding this comment

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

When overriding checkPhase, you should also provide runHook preCheck and runHook postCheck. See https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/missing-phase-hooks.md for more info.

Though, in this case, it might be better to use passthru.tests instead of replacing checkPhase so that it can be verified it works outside of the build environment (in a cleaner environment, more representative of actual users’ systems). And also so that we can re-instate doCheck when we manage to fix it.

passthru.tests.version = testers.testVersion {
package = finalAttrs.finalPackage;
};

Copy link
Contributor

Choose a reason for hiding this comment

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

@jtojnar I can provide an updated PR but I would need more info on this.

Copy link
Contributor

Choose a reason for hiding this comment

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

What info do you mean?

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