search

wbond / package_control

The Sublime Text package manager
https://packagecontrol.io
4.8k stars 814 forks source link

Do not rename a package if it is also available in another channel #1373

Closed evandrocoan closed 11 months ago

evandrocoan commented 6 years ago

I use a private channel, but it suffers from the renaming's added to the main Package Control public channel. For example, see:

  1. https://github.com/wbond/package_control_channel/pull/7206 Removed "previous_names": ["BBCode"], from "BBCode Syntax"

When I add a new package on the private channel with name ABC and there is a renaming on the standard Package Control Channel saying ABC should be named CDF, my package ABC package on the private channel, which is non related to the package ABC on the Standard Channel, gets renamed from ABC to CDF.

FichteFoll commented 6 years ago

I'm not sure we can make this distinction reasonably.

evandrocoan commented 6 years ago

I think that would be enough:

  1. To detect that there is 2 channels
  2. That on channel 1 there is a renaming from ABC to CDF
  3. That on channel 2 there the the package named ABC with no renaming.

Then Package Control should should either:

  1. Or do not rename the package on this situation
  2. Or ask the user something like: image

``` sublime.yes_no_cancel_dialog( """ There is a package on channel 1 named `ABC` which was renamed to `CDF`. But there is also the package `ABC` on the channel 2 with no reamings. Which channel do you prefer to follow? """, "Rename it", "Do not rename" ) ```


But I think would be better to keep track from which channel the package was installed. Then if it the package was installed from the channel 2, but the renaming is from the channel 1, then do not rename the package. Only rename it, if it was installed from channel 1 and there is the renaming on channel 1.
evandrocoan commented 6 years ago

There is already the package file package-metadata.json with some info about the package. That file could also note from which channel does the package come from. And this data could be used to sort out this kind of situation.

evandrocoan commented 6 years ago

I just implemented on my fork some simple form of check for it https://github.com/evandrocoan/PackagesManager/commit/f277a08fd6693738b6f10ac5b438d06c856207b3

It will not rename the package if the package-metadata.json URL's differ. For example, Package Control wants to rename ABC to BC, but URL for the BC homepage is http://bc.com while the URL for the ABC homepage is http://abc.com. Then, it will not rename the packages.

This workflow, imposes that the package cannot change its name and homepage URL at the same time.

Related to:

  1. https://github.com/wbond/package_control/issues/890 Handling Packages that Override Built In Packages
  2. https://github.com/wbond/package_control/issues/1230 [Feature Request] allow adding a Git Repository that contains multiple packages as root folders

This fix Package Control installing packages as D Programming Language when the default package as D from https://github.com/sublimehq/Packages is installed by Package Control. Because D Programming Language has on its previous_names, the package name D.

deathaxe commented 11 months ago

Both packagecontrol.io and Package Control client merge all channels into one. Trying to track origin of each package would cause significant extra complexity just for this single purpose with various additional hard to handle edge cases.

It is probably instead a better step to update default channel and drop previous_names which reached a certain age - maybe 2-3 years. After that period it should be safe to expect all clients have been updated.