Sublime Forum

PackageControl "batch" mode please?


Rather than individidually selecting/installing packages, it’d be great if we could build a list of packages to install (as in, selecting a pkg just brings us back to the pkg list), and then “finalize” to install the entire list, for those times when we know we need to install a bunch of packages. Having to pull up the PackageControl InstallPackage list each time, then select, then start all over, is inefficient – and if you’re intending to install >5 pkgs or so, painfully inefficient at that.

Willing to provide more UX details if desired, and if this already exists please tell me how to configure it so PkgCtrl doesn’t “drop out” after each install, but lacking that, having a “batch” mode would be a HUGE UX improvement for me, personally, esp. when first installing (and as a contractor, I do that a LOT). Thanks!



BTW, suggested over in another thread an alternative: Allow existing ST (and SM when PkgCtrl enabled) to dump a text list (json or whatever) of all installed pkgs, then if user copies same file into new install, PkgCtrl either automatically reads and installs latest appropriate for all, or a cmd tells PkgCtrl to do same.

The problem with users copying pkg bundles directly is that many corp environments don’t allow bringing in arbitrary binaries, mounting external drives, or even accessing cloud drives. In those cases, a user could still email themselves the text list of their pkgs for initial ST (and SM) setup, c&p the pkg list into a new text file in the proper location, etc. So long as they have a properly-recent ST/SM available to install, they’ll be fine.

As it stands today for those of us working in tightly-controlled environments, there really isn’t a decent approach for batch install. PkgCtrl AdvInstall has most of the needed tech, but requiring it be entered at a prompt (with limited length) is a needless hitch, when PkgCtrl could easily just iterate through a known text file at its leisure (and within any applicable protocol limits) instead, without putting nearly the same UX “burden” on the user. Also, currently, no way to easily get ST to dump an “AdvInstall”-compatible list of pkgs (AFAICT, if one exists, mea culpa, I didn’t know).

Worth consideration, I hope? Thanks in any case!

P.S. Is PkgCtrl plugin source available? If so, I’m more than willing to give a shot at prototyping.



Package control already does this; the Package Control.sublime-settings file lists all of the packages you have installed; when Sublime starts PC will install any packages that are in the list but not installed, or remove any that are installed but no longer in the list.

Presumably along with a list of packages you also have some configuration you want to sync, and that would normally entail syncing your User package, which is where the settings file lives. So as a part of putting your config in place, everything else follows “for free”.



That does indeed seem to be exactly what I wanted, and might be worth documenting better in that role (I certainly didn’t see much mention of that functionality – and explanation-wise, it resonates with how most Vi plugin managers’ lists work as well, so I definitely would have noticed).

I don’t suppose there’s already a PkgCtrl cmd to open that file in an ST view, is there?

That said, it seems to make the whole notion of providing a “shopping list” that much easier to implement, in practice. The site could just display the “cart” as prefs-/json-formatted text (w/ “copy to clipboard” widget) and tell user to copy into that file. Still, totally understand how adding more PkgCtrl site functionality might be too much additional effort, too.

Anyway, thanks muchly for the info, that’s a huge help!



Preferences > Package Settings > Package Control > Settings will open up the settings for the package; the defaults on the left provide details on the settings in general, including the settings that you can use to turn off one or both of the above features (installing missing things or removing orphans).



(slaps forehead) Ugh, I should have known that. Well, thanks anyway!