Keeps mentioning "linter" needs to be installed, even when using atom-ide-ui

[Gert-dev]

The package keeps requesting that the linter package be installed, but it also works fine with atom-ide-ui, which provides a compatible linter.

Admittedly, atom-ide-ui is deprecated, but in theory other linter implementations can arise, so it is not strictly necessary to install this package.

Perhaps an alternative would be to check if the atom-ide-ui package is installed via the Atom API, and not show the warning if it is, though that would likely not work for future packages implementing the same API.

Another way would perhaps to keep the check, but allow disabling it in the options.

[mallardduck]

Per the request @BradCrumb, I actually unpublished my fork of this package. There is discussion in AtomLinter/issues/3 about this and they made it seem like they would be more active potentially. However since that time they haven't been active. 🤕

So I'm highly reconsidering just publishing my own fork and going my own direction with it. The only reason I haven't is because @Arcanemagus offered to take the phpstan linter under the AtomLinter org. This was discussed here: AtomLinter/pull/8

But since all of this hasn't been activated on yet i'm getting frustrated. I'm now feeling like I switched back to the upstream one and removed mine from APM way to quick.

[mallardduck]

At this point I think I'll give it until Wednesday and if there's no movement upstream then I'm going to republish mine. If it comes to that then I will certainly make resolving this issue a top priority.

[Arcanemagus]

Another way would perhaps to keep the check, but allow disabling it in the options.

Note that if you let linter install, but leave it disabled it will stop bugging you about it since it's only checking that it is installed, not enabled.

It looks like if you want to add the check here you could run through the names from PackageManager::getAvailablePackageNames(). Unfortunately the correct solution still hasn't been implemented in Atom itself: atom/apm#387.

[mallardduck]

Looks like we're a day past the 'deadline' so I'm gonna go ahead and republish my version to APM once I've addressed this issue.

[mallardduck]

So it seems that the package utilizes the atom-package-deps for the dependency management. So rather than this being something I can directly control, it seems that this behavior is manged by that. If it allows me to do a: "needs linter, or atom-ide-ui" then we're set. So if that package doesn't support an "OR" for the dependency I'm not sure how to manage this?

[Arcanemagus]

Unfortunately it currently isn't possible directly with that package. You can see some discussion about that in steelbrain/package-deps#24.

Like I already said currently you'll need to implement the check here if you want to do that.

[mallardduck]

@Arcanemagus
When I first read that comment my assumption was that I would have to forego using: steelbrain/package-deps. I appreciate the confirmation on that. Unfortunately, this means I'm gonna have to mark this as a wont-fix since solving that problem is over my head.

---

Longer answer:

It seems like a better solution would be for steelbrain and crew to reconsider supporting this as it's clear Atom hasn't added support and likely wont. It feels like it'd be a lot of extra work to try and solve this problem myself when package-deps solves 85% of it. Especially since the end goal is to make this package more interoperable with one that's no longer maintained like atom-ide-ui.

As @Gert-dev points out, there could be other linters that this conflicts with. However right now linter is essentially the de facto one; so it's not a problem until it becomes one in the future. This also seems like a larger community issue than just my fork of a linter - since this could affect any linter provider.

If joefitzgerald doesn't want to solve this in Atom core and steelbrain doesn't want to solve it in package-deps - this is a problem I will certainly fail at too. I'm just a PHP dev trying to maintain my IDE setup with enough JS skills to hack my way thru most issues.

[mallardduck]

steelbrain is open to the idea - as such I will be resolving this the moment the feature is implemented in package-deps