[four-point-oh?] Use sublime-package.json for dependencies instead of dependencies.json

[LDAP]

Similar to how VSCode bundles all metadata in a package.json we could use sublime-package.json for dependencies instead of an extra dependencies.json.

Edit: I would be happy to provide a PR

[deathaxe]

We will still need to support dependencies.json for backward compatibility. I can follow the idea, but why adding another set of complexity to the code for just nothing? sublime-package.json is not a standard as well.

[LDAP]

I like the idea of having one file that describes the package. (would have even expected a PluginName.sublime-package instead of a .python-version file)

This was more meant to be a discussion question.

[deathaxe]

sublime-package extension is already reserved for zipped packages/plugins. Not sure how it should be used for something else without causing conflicts. I guess the point of .python-version was to find a defacto standard name for a very small easy and quickly to parse single-purpose metadata file. Gathering everything together in a huge json file means all stakeholders need to load and parse it (just to read a single number), which may easily add up to significant load.

[LDAP]

sublime-package extension is already reserved for zipped packages/plugins.

Well, that was a bad example for a file extension. Just meant something like PluginName.sublime-someextension to be in line with the sublime-commands, sublime-settings and such.

Gathering everything together in a huge json file means all stakeholders need to load and parse it (just to read a single number), which may easily add up to significant load.

Right, sublime-package.json can get comparably large.