search

wbond / package_control

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

[four-point-oh?] Concept for a dependency resolver on package level #1631

Closed LDAP closed 1 year ago

LDAP commented 1 year ago

  1. There's also no concept for a dependency resolver on package level.

    dependencies.json would need to be extended so it can also contain package dependency definitions. It supports libraries only, atm. The repository.json scheme would need to be extended to enable packages to define dependencies upstream in the same way as it is possible for libraries.

    Much effort was taken to disable and reenable all installed/updated/removed packages in one step to avoid possible race conditions. Adding package level dependencies would require a further (massive?) refactoring of the whole "job batching" strategy.

_Originally posted by @deathaxe in https://github.com/wbond/package_control/issues/1628#issuecomment-1428328790_

If we accept that package dependencies are installed after the fact and ST needs to be restarted in some cases (LSP-helpers that depend on LSP), the repository.json scheme must not be updated as far as I can see. This would already suit many plugins since the package dependencies are mostly optional (e.g. providing extra functionality if Terminus or Debugger are available).

I could attempt to provide a PR in this case.

deathaxe commented 1 year ago

the repository.json scheme must not be updated

Even though barely used, plugins can provide dependency/library specification upstream via dependencies: {...} aka. libraries: {...} as an alternative for dependencies.json. With the discussion about adding support to force unmaintained packages to run on python 3.8 via upstream setting in mind it would probably just make sense to also support upstream package level dependencies, optionally.

Libraries are installed/updated during package installation. The same would need to happen for packages with the difference that those need to be disabled before installing or upgrading. As dependencies are not known before a package has been downloaded and extracted, we again end up in disabling and enabling packages nearly one by one, which is the main cause of all the trouble with packages keeping disabled after upgrade or batch install/upgrade operations being rather unreliable. This should not be the outcome of any future change again.

Note: Just try to copy a Package Control.sublime-settings with about 70 packages to a new ST setup and try to let PC 3.4 install everything. You'll need dozens of restarts with dozens of error dialogs before everything is up and running.

Hence a solution would look like:

  1. Getting a list of packages to install,
  2. download them all to a temp dir
  3. resolve dependencies
  4. download dependencies
  5. repeat step 3 and 4 until all packages are downloaded
  6. call PakageDisabler.disable_packages() for all downloaded packages
  7. perform install/update
  8. call PakageDisabler.reenable_packages() for all downloaded packages
deathaxe commented 1 year ago

see also: https://github.com/wbond/package_control/issues/1089