Remove Bloop from Project File List

[ZachFontenot]

Bloop file is always present in Home Directory

Hey Bbatsov, love all of your work. I was having an issue with my home directory being indexed on multiple computers, and I couldn't figure out why until I manually went through and checked against all of the projectile-project-root-files, since I checked against the obvious suspects and couldn't find it.

Anyway, the culprit was a .bloop directory in my home directory, so I checked on why this was there. According to the Bloop documentation, this is where the bloop server places its config by default.

This was the most obvious solution to me, which is to remove this by default, since mill and sbt projects are already covered.

---

Before submitting a PR make sure the following things have been done (and denote this
by checking the relevant checkboxes):

• The commits are consistent with our contribution guidelines
• You've added tests (if possible) to cover your change(s)
• All tests are passing (eldev test)
• The new code is not generating bytecode or M-x checkdoc warnings
• You've updated the changelog (if adding/changing user-visible functionality)
• You've updated the readme (if adding/changing user-visible functionality)

Thanks!

[bbatsov]

I haven't used Bloop, so I'm not sure what's the best course of action here. I see it was introduced 5 years ago in Projectile (see #1405). I'm guessing one way to solve this would be to look for both SBT and bloop markers together (if there's also some project-specific Bloop configuration).

Hey Bbatsov, love all of your work.

Thanks for the kind words! 🙇

[ZachFontenot]

I haven't used Bloop, so I'm not sure what's the best course of action here. I see it was introduced 5 years ago in Projectile (see #1405). I'm guessing one way to solve this would be to look for both SBT and bloop markers together (if there's also some project-specific Bloop configuration).

Hey Bbatsov, love all of your work.

Thanks for the kind words! 🙇

Alright, I'll look into how to do that, do you know off-hand of any project configs that currently do this? Or will it need to be a new feature? Also, I'm not sure about why those tests are failing, is that maybe something else that's in Master unrelated to my change?

[LaurenceWarne]

I've run into this before too, as someone who works on sbt/mill projects it makes sense to remove to me as I'd prefer to have those projects recognised as sbt/mill anyway (a small caveat is that projectile appears to support all project types mentioned at https://scalacenter.github.io/bloop/ except pants, so we could add that for full coverage?).

In terms of adding bloop project markers to sbt and friends, I'm not sure it would add much value? That a project is sbt/mill if and only if the project root contains build.sbt/build.sc seems a fairly safe assumption to me, plus the .bloop marker in the project directory would only be present AFAIK if bloop as been run at least once and so wouldn't be present on a newly cloned project anyway.

If the bloop project type would be removed, I think the main (breaking?) change would be that sbt/mill projects start being recognised as sbt/mill rather than bloop since I think the latter has a higher precedence, which would mean the compile/test commands would change (as mentioned in #1405). Though this could be changed e.g. via:

(projectile-update-project-type
   'sbt
   :compile "bloop compile root")

A possible alternate fix where the bloop project type could be kept could be to change the bloop marker file to .bloop/bloop.settings.json, which appears to be present in bloop project directories, but not in ~/.bloop (though I can't find any doc confirming this).

[bbatsov]

@LaurenceWarne I'm fine with whatever you suggest on the topic.

[LaurenceWarne]

I asked on the bloop discord channel, and it sounds like .bloop/bloop.settings.json is fairly safe. Thoughts on changing the marker files for bloop to that instead of deleting the project type @ZachFontenot?

That way I think we don't have a breaking change, and it should hopefully fix your issue. Though as mentioned before I think there is a good argument for removing the project type completely - but runs the risk of breaking someone somwehere's workflow 😅 (https://xkcd.com/1172/).

[ZachFontenot]

Yeah happy to switch it to that, thanks for helping resolve this