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

Patches are applied twice if buildFromSDist is enabled #290

Open
johnhampton opened this issue Apr 1, 2024 · 6 comments · May be fixed by #291
Open

Patches are applied twice if buildFromSDist is enabled #290

johnhampton opened this issue Apr 1, 2024 · 6 comments · May be fixed by #291
Labels
case for tests Things we must automate testing of

Comments

@johnhampton
Copy link

The haskell-flake is trying to apply patches twice. The issue seems to be in the new buildFromSDist implementation. Setting buildFromSDist to false resolves the problem. For a reproduction, visit https://github.com/johnhampton/haskell-flakes-double-patch.

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
    flake-parts.url = "github:hercules-ci/flake-parts";
    haskell-flake.url = "github:srid/haskell-flake";
  };
  outputs = inputs@{ self, nixpkgs, flake-parts, ... }:
    flake-parts.lib.mkFlake { inherit inputs; } {
      systems = nixpkgs.lib.systems.flakeExposed;

      imports = [ inputs.haskell-flake.flakeModule ];
      perSystem = { self', pkgs, config, ... }:
        {
          haskellProjects.default = {
            settings = {
              logict = {
                # buildFromSdist = false;
                patches = [ ./nix/patches/logict.patch ];
              };
            };
          };
        };
    };
}
error: builder for '/nix/store/2mbwfyxq1jvqiz3cq52dn8r9za3fia06-logict-0.8.1.0.drv' failed with exit code 1;
       last 10 log lines:
       > source root is logict-0.8.1.0
       > setting SOURCE_DATE_EPOCH to timestamp 1711982133 of file logict-0.8.1.0/test/Test.hs
       > warning: file logict-0.8.1.0/test/Test.hs may be generated; SOURCE_DATE_EPOCH may be non-deterministic
       > Running phase: patchPhase
       > applying patch /nix/store/r335m619yhwcqr0flp4ad9s6kihqqz3w-logict.patch
       > patching file logict.cabal
       > Reversed (or previously applied) patch detected!  Assume -R? [n]
       > Apply anyway? [n]
       > Skipping patch.
       > 1 out of 1 hunk ignored -- saving rejects to file logict.cabal.rej
       For full logs, run 'nix log /nix/store/2mbwfyxq1jvqiz3cq52dn8r9za3fia06-logict-0.8.1.0.drv'.
error: 1 dependencies of derivation '/nix/store/bp67yaxnr421c3whglrdgvy4a7dy03hx-haskell-flakes-double-patch-0.1.0.0.drv' failed to build
@srid srid added the case for tests Things we must automate testing of label Apr 1, 2024
@srid
Copy link
Owner

srid commented Apr 1, 2024

Oh man, buildFromSdist is causing problems once again 😔 cc @roberth

(I'm travelling; will be a while to look into this further)

@srid
Copy link
Owner

srid commented Apr 1, 2024

I haven't looked into this in detail, but I suspect that a short-term fix would be to eval appendPatches after buildFromSdist (just as we do with removeReferencesTo):

# HACK: buildFromSdist must apply *last*
# cf. https://github.com/srid/haskell-flake/pull/252
# In future, we can refactor this as part of https://github.com/srid/haskell-flake/issues/285
# NOTE: removeReferencesTo must apply *before* buildFromSdist, because the
# later appears it fuck up the former otherwise.
impl = lib.attrsets.removeAttrs cfg.impl [ "buildFromSdist" "removeReferencesTo" ];
fns = lib.attrValues impl ++ [ cfg.impl.buildFromSdist cfg.impl.removeReferencesTo ];

@srid srid linked a pull request Apr 2, 2024 that will close this issue
@roberth
Copy link
Collaborator

roberth commented Apr 2, 2024

#291 lgtm; see comment there.

Maybe also make sure that buildFromSdist is not used when the source is already a tarball and therefore presumably an sdist?

@srid
Copy link
Owner

srid commented Apr 3, 2024

#298 should also fix this for your particular repro, but I believe we still need #291 if someone were to apply patches on a local package (is that an use-case we should support?).

@johnhampton
Copy link
Author

johnhampton commented Apr 3, 2024

#298 appears to resolve my issue. I'm unsure about when to use buildFromSdist. I don't foresee patching local packages, but would I ever want to enable buildFromSdist for a remote package with packages.*.source pointing to a GitHub repository?

If fixing buildFromSdist isn't possible, it would be helpful to show an error or warning when both buildFromSdist and patches (or any other invalid option) are enabled together.

@roberth
Copy link
Collaborator

roberth commented Apr 7, 2024

#291 if someone were to apply patches on a local package (is that an use-case we should support?).

Might be useful as an escape hatch if the local build needs to be different from the packaged build for some (bad) reason.

@srid srid changed the title Patches are applied twice Patches are applied twice if buildFromSDist is enabled May 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
case for tests Things we must automate testing of
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants