fsprojects / fsprojects/Paket

'ignore' for paket.dependencies

Open
#2,054 1 comment 3 reactions 1 assignee View on GitHub

@enricosada is already working on this.

Since Jan 24, 2018.

enhancement spec UX
Dominant language
F#
Stars
2.1k
Forks
528
Avg merge
1d 12m
Merged PRs (30d)
54

Description

Several of the projects I work on involve modifying and restoring project files to a stable state and paket making modifications to these project files breaks all of the tests. Typically I use git to discard the changes after paket upgrade (the context where I encounter this issue the most), but being able to list the directories that I don't want paket to search through would be ideal.

I think a convention like

ignore /testdata/
ignore /test-data
ignore test-projects/

where ^ are all dirs, paket won't search that dir and all of its children and

ignore /experiments/lab01.fsproj

will ignore that specific project

and maybe even

ignore /samples/amazing.sln

will ignore all projects in that particular solution (this might be a bad idea)

open questions
  • is it worthwhile to include a more complicated ignore syntax similar to git's ? (this probably isn't worth the effort)
  • should there be a way of listing multiple dirs together in a group, perhaps like TOML's arrays? (I'm not sure this is a good idea)
  • under what circumstances should warnings be emitted? e.g. when a dir or file doesn't exist, are there any circumstances when this should cause a failure state?
  • should unix path standards be enforced universally? or should a case invariant search be used on unix where the closer match is ignored? or should the os standard be used and users get a warning on unix when the path couldn't be found but the case invariant search finds a match?

(you can assign this to me)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.