wbond
Feature request: freeze a package to given version
As mentioned in this support thread. The most straightforward use case is to allow reverting a new regressing version (empower users, drop the pressure off maintainers).
A suggestion of an implementation would be to handle specified "frozen" versions by skipping if same as required over here, otherwise re-installing the specified required version. We could start off with a simple (documented) setting to allow freezing a given package to a given version.
Later on, we can add a new command to (re-)install a package with a given version. The command will: (1) "force install" package with given version, (2) store the frozen version (in settings?).
#825 is about dependencies only and a different beast, although it sounds similar at first.
Since it's now 2018, and some changes are upon us with PYPA doing the great work they are doing, maybe we can revisit this and implement a sort of lockfile/venv for PC, where every package could have it's own isolated environment and we rely on pip and friends to do the dependency management where possible?
Some of our options:
- https://github.com/pypa/pipenv
- https://github.com/sdispater/poetry
- https://github.com/ofek/hatch
From a use-case standpoint, I personally want to be able to easily start including wheels as deps for all supported operating systems, so that I can use optimised libraries to build top-of-the-line extensions that will leave VSCode in the dust ;)
@asfaltboy The plugin_host is a single Python environment, so it won't be possible to make an isolated environment for packages.
If anyone is keen on trying to make it so Package Control can install packages off of pypi and manage dependencies and wheels, etc, I'm not going to stop work on it. Of note, it seems many packages are dropping support for Python 3.3 since the non-Sublime-Text install base for that version is pretty small. All that said, just making it so packages can be locked to a single version would be a massively smaller undertaking.
Unfortunately I don't have time for open source so much these days because of prioritizing my personal life. If I see someone starting to make some contributions to PC and having a solid understanding of the mechanisms and goals of the project, I'd be happy to giving them contributor access.
This issue seems to have morphed into #825 . In that issue I wrote about my experiment to vendor deps as @wbond suggested for my package Requester. Would love to hear what anyone thinks about it.
In the same vein as what @asfaltboy is saying, I think ST is second-to-none in terms of core functionality. But the difficulty of vendoring deps for packages, on top of the fact that outside ST Python 3.3 is sort of dead, is the only thing holding package developers back from building truly awesome packages and leaving VSCode in the dust =)
