Four point oh #9261
Four point oh #9261
Conversation
1. rename dependencies.json to libraries.json 2. update scheme versions 3. drops repositories of scheme 1.x as those support ST2 only. 4. drops libraries, which support ST2 only. 5. drops packages, which support ST2 only.
The `sublime_text` key is optional as of PC 4.0.0-beta.9
Rename dependency to PyPI package name to avoid future naming conflicts.
Note: Required name mapping to ensure backward compatibility is supported
as of PC 4.0.0-beta.9
Rename dependency to PyPI package name to avoid future naming conflicts.
Note: Add list of required "libraries", to ensure "lxml" is also installed.
Note: Required name mapping to ensure backward compatibility is supported
as of PC 4.0.0-beta.9
Rename dependency to PyPI package name to avoid future naming conflicts.
Note: Required name mapping to ensure backward compatibility is supported
as of PC 4.0.0-beta.9
Rename dependency to PyPI package name to avoid future naming conflicts.
Note: Required name mapping to ensure backward compatibility is supported
as of PC 4.0.0-beta.9
Rename dependency to PyPI package name to avoid future naming conflicts.
Note: Required name mapping to ensure backward compatibility is supported
as of PC 4.0.0-beta.9
Note: Opt-in to python 3.8 as it is a pure python library.
Rename dependency to PyPI package name to avoid future naming conflicts.
Note: Required name mapping to ensure backward compatibility is supported
as of PC 4.0.0-beta.9
Rename dependency to PyPI package name to avoid future naming conflicts.
Note: Required name mapping to ensure backward compatibility is supported
as of PC 4.0.0-beta.9
Rename dependency to PyPI package name to avoid future naming conflicts.
Note: Required name mapping to ensure backward compatibility is supported
as of PC 4.0.0-beta.9
Rename dependency to PyPI package name to avoid future naming conflicts.
Note: Required name mapping to ensure backward compatibility is supported
as of PC 4.0.0-beta.9
Note: Opt-in to python 3.8 as it is a pure python library.
This commit ... 1. renames tokens: dependency => library dependencies => libraries 2. adjusts scheme versions to 4.0.0 3. drops `load_order` from libraries 4. drops tests for presence of `sublime_text` and `platforms` keys from release tests, as those are optional as of PC4.0-beta.9 5. drops duplicate library vs. package name checks, as libraries are installed independently to Libs/ as of PC4.0 6. adds `python_versions` type and value checks. 7. verify new libraries are not named like renamed legacy dependencies.
This commit adds `Binary` and `Git Formats` to the list of default packages.
This commit adds `Binary` and `Git Formats` to the list of default packages.
1. sort urls alphabetically 2. reformat patterns to use more of available space 3. disallow `#` (start of anchors) and `?` (start of parameters) in user and repository names 4. move (?<!\.git) to ensure not to accept something like https://github.com/repo/user.git/tree/master
Now that arm64 is supported it is very valid to have both x32 and x64 to specify arm64 is not supported.
To support validation and completions via LSP-json, Package Control ships json schemas for channels and repositories. This commit allows them to be explicitly assigned without tests failing via - "$schema": "sublime://packagecontrol.io/schemas/channel", - "$schema": "sublime://packagecontrol.io/schemas/repository",
Ship libraries for python 3.8 directly from pypi.
Remove repository of scheme 1.2 as no longer supported.
Dropped package.json is missing "details" or "base" entries for more about 8 years and thus has never been crawled. As such, drop that questionable thing.
Add name field to prevent unintended package renaming due to changed repository URL.
Sync with github.com/packagecontrol/channel
Least supported version by PC4+ is ST3143. Hence no requirement to specify lower bound "3000".
|
Note that in previous changes (PR's that have been abandoned) I've seen mistakes in migrating existing package from external repositories into this one. For instance, I remember seeing some cases with build steps (and therefore fully defined packages) getting migrated into "simple" entries in the registry. There is a high likelihood of breaking at least several package entries this way, and the PR is very large and time consuming to review. Just as a general warning that those migrations need very careful review before we move forward with this. |
|
A relevant merge commit is 9e808d5. It merges all/many commits with package migrations into four-point-oh. A candidate may be https://raw.githubusercontent.com/JesseTG/ribosome-sublime/master/packages.json (d41feca). This one is somewhat confusing or broken already, as it seems to require a build-step, but the external package.json still just points to a fixed tag's worktree snapshot. PC would certainly not install the created sublime-build file. Erlyman: https://raw.githubusercontent.com/Mendor/sublime-erlyman/master/packages.json contains url-based release, just pointing to latest tag's source archive. CodeComplice: https://raw.githubusercontent.com/spectacles/CodeComplice/master/packages.json also just points to tag's archives. sublime-elfinder: defines url downloads for ST2 (irrelevant) and tags for ST3, which don't exist, in https://raw.githubusercontent.com/thinkv/sublime-elfinder/master/packages.json. Hence migrated to branch-based release. All other commits seem to point to tag based or branch based releases, only. |
Convert to an asset based release to install sublime-package file from Github releases' assets.
|
These are not overly popular packages and it wouldn't be the first time packages have been in the registry for years that are simply impossible to install or use on current versions of Sublime Text and PC. In a way I'm not even so worried about breaking them: if someone complains there is an opportunity to get it fixed. If I'm going to help in reviewing this I'm going to have to find a way to break this down... GitHub's PR UI won't work on a changeset this large. I guess the first worry has to be to get the schema tests to pass? |
|
Usually, such large changesets require that we see and review the scripts that generated them. One after the other, e.g. "drop all packages that have a version <3000". If we then agree that this is useful step, @braver -- the people with commit rights -- runs the script locally and merges. Esp. dropping is problematic as we actually want to keep track of the used names. (Which we already have to do in the workspace.json.) Instead marking them tombstoned/removed: datetime is in the long run preferrable. There is always a risk to loose the workspace.json at some point, relatively unlikely that we use the registry history (this repo) as a whole. |
|
Well, the changeset's size and its easy diff is just a result of its age.
😕 Not sure, what this means, but everything basically just were manual steps. The initial change was just to drop all ST2-only packages which are of absolutely no interest or value since PC does not run on ST2 anymore. That's also the reason why reserving their package names has little value. It's rather unlikely those to be ressurrected 15 years after EOL of ST2. Despite migration of packages from external repositories, this PR just continued to add changes from master every once in a while. |
|
After having checked 2 jsons it doesn’t seem too bad… I’ll be able to get through that eventually. The migrations of external repos is a bit more worrisome, but worth the effort. I don’t have a lot of time these days though. Is it doable to handle the deletions first in a separate PR? Note sure how easy your work is to separate (and then keep in sync with master… although master doesn’t see that much action). Anyway, as long as the tooling doesn’t choke on this we’ll get it done eventually. |
|
The deletions itself are not the problem, but the conflicts they cause with master. I therefore don't intend to put any effort in separating them. FWIW, this PR should be merged not before old packagecontrl.io site is dropped. Hence there's probably no reason to hurry. |
|
Good point, and sounds like a plan. It’s not as bad as I feared.. bit intimidating set of changes but doable if I don’t want to check everything in one evening 🙂 We should notify the authors we will remove their personal repository. Especially for those still active in the community I’m sure they won’t mind, but they need to be made aware of that change for if they ever want to make a change or publish something new. |
|
How and where should we backup the old tombstoned names? |
Co-authored-by: Koen Lageveen <[email protected]>
3 participants
This PR prepares package_control_channel for Package Control 4.0 by...
This PR is frequently synced with this repo's master branch and https://github.com/packagecontrol/channel.
It contains all current ST3+ packages and libraries.
As many as possible packages have been migrated from external repositories to this one, to reduce attack surface of uncontrolled 3rd-party registries.