What is good etiquette for packages whose functionality collides with another package?


#1

Background

Consider a scenario where we have two packages:

  • lang-specific-tool: runs “specific” tool on .lang files
  • lang-awesome: runs “specific”, “precise”, and “exact” tools on .lang files

For the sake of this conversation, let’s call the lang-specific-tool a standalone package, and the ‘lang-awesome’ package a bundled package (because it is a superset of lang-specific-tool – and potentially other packages).

The Dilemma

Let’s further assume that both packages trigger their actions by listening for the buffer saved event, and that each tool may modify the .lang file they operate on. Consequently, the functionality could collide if both lang-specific-tool and lang-awesome are installed and active at the same time.

Should the lang-specific-tool disable the lang-awesome package? Should lang-awesome disable the lang-specific-tool package? What happens if both try to disable each other?

Ultimately this is a question of etiquette. And I’d like to discuss it here prior to implementing any disabling functionality because I think we need to achieve some level of consensus so there is a convention.

The Proposal

Would it make sense to establish this convention?:

bundled packages are responsible for disabling any standalone packages that might conflict with them; standalone packages should avoid disabling any packages if possible

Let me know your thoughts. Is there another way to think about this problem?


#2

From my point of view as a user:

  1. Any package that silently disables another package is overstepping its bounds
  2. Any package that asks permission to disable another package, to me, is still highly suspect
  3. Any package that asks permission to disable another package that doesn’t explain the following two things is probably going to get classified by me as a variation of #1
    1. What benefit I am going to gain by disabling the other package
    2. What, if any, functionality I will lose by disabling the other package

Personally, the correct course of action for a package that knows it conflicts (or could conflict) with another package is for it to do one of the following:

  1. Fix the conflict
  2. Disable the feature in itself that conflicts when it detects the other package is already installed
  3. Inform the user as part of the installation process or README that feature X conflicts with package Y and give them a configuration option to disable feature X

Disabling another package is like those installers that “offer” to change my home page or my search provider in my browser. I don’t care if I do want to change my search provider … it isn’t the installer’s place to be doing that for me. Likewise, a package should not be changing other packages for me.


#3

I agree with @leedohm on everything. I wonder, though, if this shouldn’t be address at a higher level: Atom itself could tell me that package X knowingly conflicts with package Y, or that package A and B are alternative, and it makes very little sense trying to activate both.

This goes a little beyond conflicts: if two different packages offer very similar functionalities, or perform similar tasks, it may be useful to know in advance.

Maybe packages could declare known conflicts in metadata?


#4

@leedohm you raise great points. Perhaps my proposal should be adjusted to be:

Any package that knows another package conflicts with it should never attempt to disable the package, and should (at most) warn the user of potential conflicts, and provide the user with guidance on corrective action

I do agree with @giorgian that it would be nice if Atom provided a way for packages to declare known conflicts so that at some point in the future, you might be able to address this consistently for all packages within the package manager.


#5

Yes, this proposal is much better.

I think that Atom being able to “detect conflicts” is akin to solving the Halting Problem. I just don’t think it is a realistic expectation in the general case.


#6

Not at all! Of course I didn’t mean that Atom should be able to detect conflicts automatically, that would be next to impossible.
What I had in mind is something like Debian packages: they contain metadata that specifies conflicting packages.
Of course, not all possible conflicts will be known in advance, but if that hasn’t stop Debian people from doing an awesome distro, I don’t see why it should stop Atom people from doing an awesome editor and plugin repository.


Elsewhere I opened a topic about marking packages as safe/unsafe/unknown; what informs both that topic and my replies here is the (to me, at least) obvious fact that packages will be very different in popularity: inevitably, certain packages will end up being installed on most Atom instances, while other packages will be fairly unknown to the general public.

As long as this is beta, it’s in everybody’s best interest for packages to be widely known, so that people can try then and find bugs, with very low barriers to entry. When Atom’s users will be counted in millions, that will inevitably have to change: it’s vital for newly authored packages to be first reviewed by expert users, and only then to be made available to the general public.

This is not hard nor expensive to do: it just requires a single preference, “Allow beta packages” or the like, with known users encouraged to rate packages, report bugs, discuss incompatibilities and the like.

I think that if the author of a package lacks the time or the will to make the package safe and to address possible conflicts, this fact should be somehow known in advance by users; metadata and community rating are the ways to accomplish all this.


#7

I wouldn’t object to that kind of system if that is the way the Atom team goes … but Emacs has a package management system where anyone can put up a package repository and there are repositories that are known to be more wild and others known to be more stable. I would prefer a system more like that than your curated walled garden approach.


#8

I think I would take an even more simplistic approach:

  • Provide package authors some way to flag known conflicts (just an array of package names would suffice)
  • Show a warning if a user has multiple packages known to conflict activated at the same time
  • Allow a user to ignore the warning after it’s displayed once

It’s not a walled garden, it does not require much intelligence in the editor, and it highlights to the user that they might want to take some (manual) action to ensure the package(s) function correctly.


#9

An optional extension to my suggestion above:

  • If two package authors both flagged each other’s package, and
  • If both both packages agree (‘vote’) on which package should be ‘activated’, then
  • Atom could avoid activating the package that has lost the vote, and
  • The package which has lost the vote will not be disabled (it might provide other functionality that does not conflict)

#10

In addition to the existing proposed convention:

Any package that knows another package conflicts with it should never attempt to disable the package, and should (at most) warn the user of potential conflicts, and provide the user with guidance on corrective action

We might want to add another pattern:

Any package which knows that it conflicts with another package and wishes to avoid conflict with that other package may choose to disable itself or prevent its own activation, optionally displaying some status that this has occurred