Package Control

The Sublime Text package manager. Visit packagecontrol.io for installation instructions, a list of available packages and detailed documentation.

License

Package Control is licensed under the MIT license.

All of the source code (except for package_control/semver.py), is under the license:

``` Copyright (c) 2011-2020 Will Bond will@wbond.net

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ```

package_control/semver.py is under the license:

``` Copyright (c) 2013 Zachary King, FichteFoll

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ```

Issues

Problem with "Package Control.sublime-settings" hierarchy/ team settings

opened on 2023-03-17 15:47:43 by DavidBrieden

I work in a small team with Sublime Text and would like to set up an environment for team settings for package control.

The idea is to define global settings that apply to the whole team and store them in the Sublime folder under Data\Packages\Default. This folder will then be version controlled. In the folder under Data\Packages\User every single user can overwrite his own settings.

We would like to do the same for packages. We already have a global "Package Control.sublime-settings" in the default folder. Basically this already works, when starting Sublime these packages are installed successfully.

The problem now is when we make a change, i.e. when we delete or add packages: Here the "Package Control.sublime-settings" is completely copied into the user folder, and completely overwritten. If now a change is made to the "Package Control.sublime-settings" in the default folder, Package Control does not notice this change, because there is already an own file in the user, which overwrites everything.

Is there a solution for this problem?

Package Control bails out in Sublime if system uses non-English language

opened on 2023-03-13 22:30:09 by mdziczkowski

Environment

OS: Debian 11 Sublime version: build 4143

Issue description

After installing Package Control in Sublime and trying to use it, I recieve the message that I need to set system variables related to language (LANG=, LC_CLANG=, etc.) to english (in case if it's set other ways) or it won't work.

Setting the mentioned variables (with messess up in displaying of the content with dialectical characters of my language) and launching then Sublime doesn't have an effect and I still get the message

Expected behaviour

Normal work of Package Control in Sublime

[four-point-oh?] Coordinated 3.3 ⇾ 3.8 upgrade of packages with plugins

opened on 2023-02-13 09:24:09 by LDAP

With the upcoming PC4 release, packages with plugins such as LSP (@sublimelsp) or SublimeLinter (@kaste) are going to switch to the Python 3.8 plugin host (see Discord discussion).

One problem is the coordinated upgrade of the "main package" and it's plugins (LSP-helpers, SublimeLinter-adapters): Upgrading the main package to 3.8 breaks all plugins that are not yet ready to update and vice-versa. This is especially difficult because some plugins are unmaintained or maintained by different members of the community.

My vague solution (inspired by the poetry package manager):

• As already proposed in #1628 plugins should declare their dependency to the main package and the version that is required. (In the channel so that this can be influenced for unmaintained packages?)

• Plugins should declare the required python version similar how they declare their supported ST version. (In the channel?)

• Similarly to python package managers (e.g. poetry), when installing a new package (for example a 3.3 plugin) check if all requirements can be fulfilled and possibly downgrade dependencies (main package and its plugins) after asking the user for permission. Example: LSP and LSP-helper are 3.8, user installs LSP-helper2 which is 3.3 ⇾ PC asks for permission and then downgrades LSP and LSP-helper to the latest 3.3 version and installs LSP-helper2.

• On update, PC builds a dependency graph and updates plugins only if the whole component in the dependency graph can be updated.
• Optionally: Ask the user if packages should be "Updated anyway"
• Optionally: Ask the user if the plugins that do not provide a 3.8 version should be disabled

It is questionable if this is worth the development effort. Also, there may be simpler solutions, maybe (parts of) an existing python package manager can be reused?

[four-point-oh?] Unload packages that depend on a plugin that is updated

opened on 2023-02-12 15:21:42 by LDAP

When updating a dependency (e.g. LSP) all plugins (e.g. LSP-* helpers) that depend on LSP break.

Preferred solution:

• Plugins (LSP-* helpers) that depend on another plugin (LSP) declare that dependency.
• On update, Package Control unloads all plugins (LSP helpers) that depend on the plugin (LSP) that is updated. Then updates the plugin and then reloads all dependencies.

This should fix the issue that ST needs to be restarted after an update. Bonus: LSP does not need explicitly to be installed because Package Control knows about the dependency.

Fix client side basic auth

opened on 2022-08-15 20:27:43 by deathaxe

This PR fixes two bugs related with basic authentication:

1. The http_basic_auth setting is not cached by PackageManager and therefore not passed to downloaders.
2. Basic authentication doesn't work for WinINetDownloader

As a result users with numerous custom repositories might quickly hit rather low API rate limits.

[four-point-oh] Reduce expensive github API calls

opened on 2022-08-15 17:04:49 by deathaxe

TL;TR: Is a release's date field used for anything else than determining when a package was modified?

State Of The Art

Currently, client.download_info() makes an API call for each tag/release of a package or library.

https://github.com/wbond/package_control/blob/4e585fb656c5a0da03bd010bb9533fb055c7ab10/package_control/clients/github_client.py#L72-L74

This means theoretically up to 100 API calls per package/library!

Even a dependencies.json repository with least required / most popular libraries causes PC to quickly hit default GitHub API rate limit after a couple of libraries.

... all of that just to delete the date field from releases, finally!

date of most recent release seems used to fill last_modified field of a package however (not library). Am I right it to be required for packagecontrol.io (only)?

Proposal

We could modify providers to explicitly make an API call for the most recent release only (or the branch for branch based releases) to reduce API calls significantly by ommiting implicit API calls for each release, just to determine the date field.

This would limit PC to invoke 2 API calls per package/library. One for the history, one for the date of the most recent release.

It should save some bandwith and improve crawling performance significantly.