package_control icon indicating copy to clipboard operation
package_control copied to clipboard

Store dependencies in a different folder than Data/Packages

Open FichteFoll opened this issue 11 years ago • 4 comments

Things will probably get messy over time when packages start using dependencies more frequently and it will be harder to keep track. This is not high priority but meant for future reference.

There is no technical reason for the dependencies to be located next to actual packages, because their directories are added to sys.path anyway, and it leads to

  1. confusion in that it's not easy to tell if a folder is a dependency or a package just from looking at its name
  2. possible name conflicts that won't be possible if dependencies were separate
  3. hacky or maybe unwanted interaction from dependencies with Sublime Text since it will treat them as normal packages (possibly an unintended feature) and thus allowing the normal package files, making things even more confusing

While the latter could as well be a feature, you explicitly declare dependencies to not be used for this purpose and I don't think they should be treated the same either.

FichteFoll avatar Dec 22 '14 19:12 FichteFoll

An update on the situations, 1.5 years after the initial release:

  1. At this moment, I have 13 dependencies installed in my Packages folder. That is already enough to unnecessarily pollute this technically "packages-exclusive" directory.

  2. Has happened already, see https://github.com/wbond/package_control_channel/pull/4986 and especially https://github.com/wbond/package_control/issues/1028.

  3. Iirc @wbond made a dependency for configuration of Go-related packages that defines resources which interface with Sublime Text. If we place dependencies in a Packages sub-directory (e.g. Packages/_dependencies_, normal resources will still be detected and loaded by Sublime Text (all currently known) except for Python plugins. Those would have to be placed in the dependency root though and to my knowledge no dependency does this. I would also probably not have accepted a dependency which did this in the first place and increasing the nesting level will actively prevent this from happening.

    As such, the only downside of storing all dependencies in one package is not being able to disable a single dependency when uninstalling but all at ones. Since all known resource files besides color schemes and themes (not suited to be used in dependencies) can be hot-reloaded, this doesn't appear to be a blocker however.

    If resource interfacing was not a requirement, moving dependencies to a sub-folder of Data (i.e. next to the Packages folder) seems like a safer solution.

FichteFoll avatar May 25 '16 01:05 FichteFoll

@wbond do you have anything positive or negative to say about this suggestion?

FichteFoll avatar Sep 20 '16 12:09 FichteFoll

I'm not opposed to the idea of moving the dependencies into something like Packages/_deps/.

The challenges with this are:

  1. Updating code to install to new location
  2. Writing code to move existing dependencies
  3. Testing <- the largest amount of work

wbond avatar Sep 20 '16 13:09 wbond

Just for the record, Sublime Text 3.0 (and a couple dev builds earlier) shipped with a new Lib folder in the data folder, i.e. $DATA/Lib/python3.3, that is included in sys.path immediately after the stdlib.

FichteFoll avatar Sep 15 '17 14:09 FichteFoll