Restrict TOML

[deathaxe]

This commit restricts external TOML package to ST builds before 4198.

Installing it on later builds overrides bundled TOML syntax and causes compatibility issues with syntaxes extending it. At least Python throws errors due to different sublime-syntax versions. Jinja2 and other packages may also be affected.

[github-actions]

Package Review

Channel Diff

Removed (none), changed TOML, added (none).

Review for TOML 2.6.0

No failures

1 warnings:
- '.sublime-syntax' support has been added in build 3092 and there is no '.tmLanguage' fallback file
    File: TOML.sublime-syntax


For more details on the report messages (for example how to resolve them), go to:
https://github.com/packagecontrol/st_package_reviewer/wiki

[braver]

Many language packages exist that are alternatives to default languages. Even python and JS have several alternatives. Perhaps a version of this TOML package can be made that doesn't interfere so much, e.g. by a change to its scope name?

@jasonwilliams perhaps you can help find a solution and avoid having to effectively delist the package?

[deathaxe]

Actually, bundled TOML was a fork of this package in the first place.

However context structure has finally changed, significantly, which is always likely to cause incompatibiliteies with extending syntaxes.

Bundled TOML is less eager with regards to illegals, but otherwise superior.

Of course we can keep it available, and just let it fail.

I just noticed it due to inheritance error messages in console, caused by TOML package being installed.

[braver]

Similarly if you install the Typescript package you used to be in for a rough ride. Although there the version is also restricted these days. With Microsoft I don't really care what happens with their packages, but with individual authors like this example, we kind of have to tread that line where I feel they should be the primary owner of their entry. At the same time most packages are effectively abandonware (and I don't even mean that in a derogatory way, I totally understand that providing something free of charge also comes with it being free of burden and responsibility), so it's also kind of our responsibility (ie. if this package was submitted today, as is, we would reject it).

So let's say I approve of the proposed change here, but I want to give the original author the normal 2-ish week to respond and come up with an alternative approach. Knowing also of course that we're not deleting the package, so any adjustments can also be made at a later time.