hercules-ci/gitignore.nix

add way to add additional ignores

Closed this issue ยท 13 comments

add api similar to https://github.com/siers/nix-gitignore#usage

example

  additionalIgnores = ''
    /this
    /that/**.html
  '';

  source = nix-gitignore.gitignoreSource additionalIgnores ./source;

Your goal can already be achieved through cleanSourceWith { filter = filterThisThat; src = gitignoreSource ./source; }.

Reasons you may still need a feature like this:

  • for adding negative rules (inclusions). cleanSourceWith composition doesn't support that, but git does.
  • for using the gitignore rule language instead of Nix's string functions directly.

The interface can mirror the cleanSource interface. It seems we can cover these use cases with a function gitignoreSourceWith that takes a file or string of rules as the first argument. The second argument can be a path or the result of another gitignoreSource somePath call.

It may even reuse the same trick that cleanSource uses to recover the filter function, but to instead recover the set of rules, so it can add negative rules (inclusions) on top of what's in the actual .gitignore files.

However, doing so is unnecessary if cleanSource supports negatives like git. That can probably be done by allowing the filter functions to return extra values besides true, false. The benefit is that negatives will be supported in more places, but depending on how well it can be done, it may turn out to be a bit confusing.

Conclusion:
gitignoreSourceWith can mirror familiar cleanSource api. Doing composition similarly settles the question of whether the real .gitignores should be included or not (not, unless composed). This will keep the interface small: one extra function to cover both use cases.
There's some improvement possible wrt interaction with cleanSource.

Perhaps it's best to do #10 before working on this, unless we do a non-composing implementation of gitignoreSourceWith first.

negative rules (inclusions). cleanSourceWith composition doesn't support that

you are saying that this project doesnt support negative rules
that's bad, because https://github.com/siers/nix-gitignore/blob/master/test.nix#L73 already supports this feature

you are saying that this project doesnt support negative rules

gitignoreSource does already support negative rules, but cleanSourceWith can not merge in any negative rules that weren't in the original .gitignore files. This is a limitation of cleanSourceWith that affects all its usage, regardless of the chosen filter.

What I'm suggesting is to mirror cleanSourceWith's interface, precisely to avoid its limitations, but remaining compact and familiar.

This is fixed now in master?

To resolve this I think we need

  • some way to specify filters using gitignore-syntax strings instead of real files
  • a way to compose those with the current gitignore filter that allows negative rules to work
    • either further improving Nixpkgs' cleanSourceWith
    • or write code to compose and/or modify gitignore filter functions

I think these should be implemented simultaneously, to avoid creating an oversized interface.

I'm not in a hurry, because cleanSourceWith composition is a good alternative if you only need the intersection of filters. PR's welcome ;)

To clarify, there's no way to currently ignore everything in .gitignore and then add your own ignore on top of that such as README.md and the only option at this very moment is using https://github.com/siers/nix-gitignore#usage?

You can do cleanSourceWith { filter = extraFilter; src = gitignoreSource somePath; }, but this repo does not currently expose a function to implement extraFilter using gitignore syntax.

cleanSourceWith { filter = extraFilter; src = gitignoreSource somePath; }

Thank you very much for the quick answer. My specific example of using gitIgnoreSource with developPackage and root instead of src (which I wasn't sure would work is):

{ compiler ? "ghc883" ,
  pkgs ? import ./nix/nixpkgs.nix {},
}:
let
  inherit (import (builtins.fetchTarball "https://github.com/hercules-ci/gitignore/archive/7415c4f.tar.gz") { }) gitignoreSource;
  hpkgs = pkgs.haskell.packages."${compiler}";
  mypkg = hpkgs.developPackage {
    root = pkgs.lib.cleanSourceWith { filter = (path: type:
      ! (builtins.any
        (r: (builtins.match r (builtins.baseNameOf path)) != null)
        [
          "README.md"
          "notes"
          "ops"
          ".ghcid"
          ".dir-locals.el"
        ])
    ); src = gitignoreSource ./.; };
    name = "mypkg";
    modifier = drv:
      with pkgs.haskellPackages;
      pkgs.haskell.lib.disableOptimization (pkgs.haskell.lib.overrideCabal drv (attrs: {
        doCoverage = false;
        doCheck = false; # whether to run tests
        enableLibraryProfiling = false;
        enableExecutableProfiling = false;
        doHaddock = false;
        buildTools = [ brittany
                       cabal-install
                       ghcid
                       hlint
                       hpack
                     ];
      }));
  };
in mypkg

Just a heads up to anybody else landing here searching for errors, it seems something changed between Nix 2.9 and 2.10 in regard to this. If perchance you had .gitignore listed in the cleanSourceWith() routine, the later gitignoreSource() call now throws an error.

@alerque Please make sure all your gitignore.nix references are up to date with master, as we've merged #58 the other day, for running it in pure evaluation mode which did get stricter in 2.10.
If the issue persists, please open a new issue with more details. This issue is a feature request unrelated to your problem.

I realize this issues started out unrelated, but the code proposed in the comment above by codygman has made its way into dozens of repositories (only one of them being mine) and now with 2.10 many of them are failing to build. Since there are several references back here and even much of the code has comments linking back here I thought it be worth pointing out the new stricter requirements and how to adjust.

#61 adds support for extra gitignore rules to gitignoreFilterWith.

Could you give it a try?