Add flag to select which project

[ndmitchell]

If a stack file lists multiple projects there should be a way to pick which projects are actually run.

[pepeiborra]

While on this, please add another flag to exclude a project.

[ndmitchell]

Sounds like a good idea.

[barrucadu]

I've just come across this, and it would be pretty handy.

[ndmitchell]

I'm unconvinced this is valuable. Adding an exclude rule in .weeder.yaml is pretty easy. When this ticket was first opened certain projects took 3Gb RAM to be processed and a meaningful amount of time - that's no longer true. My inclination is to say run weeder on everything, and suppress the entire projects if you don't care about them. Or does that stop you from doing something that is useful?

[pepeiborra]

Can Weeder ever crash on a project ? If the answer is yes or I don’t know, then this is still valuable.

[ndmitchell]

It's meant to never crash under any circumstances. Naturally, I'm sure there are bugs, but if they get reported they'll get fixed.

[ndmitchell]

Closing in the absence of a concrete use case - please reopen if one pops up.

[pbrisbin]

Bringing this over from a comment left in #41:

I think this would be valuable in the case where you want to isolate the output to a given package temporarily, most likely because you're working on that package right now and you want to use weeder as part of verifying your work.

It's true using weeder just to verify you didn't introduce an issue is fine via exit-code, but seeing what that issue actually is is difficult in a large project's output:

= Package hubspot-form =
No warnings

= Package frontrow-jobs =
No warnings

= Package school-admin-mailer =
No warnings

= Package db-test-helpers =
No warnings

= Package text-assets-build =
No warnings

= Package text-assets-common =
No warnings

= Package teacher-daily-mailer =
No warnings

= Package school-lead-mailer =
No warnings

= Package build-math-standards =
No warnings

= Package fancy-api =
No warnings

= Package school-report-generator =
Did you see me?

= Package data-gen =
No warnings

= Package school =
No warnings

= Package asana =
No warnings

= Package fr =
No warnings

= Package teacher-mailer =
No warnings

= Package frontrow-app =
No warnings

= Package fr-slack-api =
No warnings

= Package frontrow-types =
No warnings

= Package sendgrid-client =
No warnings

= Package roster-management =
No warnings

= Package frontrow-entities =
No warnings

= Package badge-awarder =
No warnings

= Package aws-xray-client =
No warnings

= Package merge-map =
No warnings

Ignored 845 weeds (pass --show-all to see them)

To actually satisfy this use-case via the config would require adding excludes for everything else, running weeder, then removing them. Doable, but an option would be way better at not much cost IMO.

[ndmitchell]

So you want an option to pick only a subset of projects? e.g. --project=name? No requirement to exclude projects?

[pbrisbin]

Correct.

To me, it seemed natural that weeder [DIR, ...] would expand and operate on {DIR}/**/package.yaml, which would work equally well for a directory of packages or a single package's directory.

But keeping the unnamed DIR argument as a way to locate the stack.yaml (which, I think, is its actual intent) and providing a separate --project= (or --package=) option is fine with me as well.

[ndmitchell]

Happy to accept a patch for this as I'm guessing it won't be too hard to do. Alternatively, I'll likely get to it at some point in the future.

[jwoudenberg]

I've another use case for this:

We've got a repository containing multiple Haskell projects in a single Stack project. We're using Shake to drive stack build. It builds each project only when any of the Haskell files in it have changed.
Weeder requires all projects to be built. This has two disadvantages:

• Change any Haskell file, and Weeder will require all Haskell projects to be rebuilt, rather then just the Haskell project you changed a file in. This in inefficient.
• With shakeShare option set we'll somehow need to define a dependency on all Haskell intermediary build products.

[ndmitchell]

@jwoudenberg - wow, using one of my other projects to get me to improve a different one. Tricksy 😝

[jwoudenberg]

Haha 😄, it only works because you maintain so many cool projects!

[ndmitchell]

Weeder 2.0 is being developed at https://github.com/ocharles/weeder so I suggest you go see if that fixes your issues.