Sublime Forum

Package Control: A full-featured package manager

#4

Bandwagon!

Also it’d be sweet if there were an option like “convert all the crap you downloaded off of github into actual things tracked by this package manager” (maybe come up with a snappier name). Right now I’m going one at a time.

0 Likes

#5

Thanks @adzenith! Right now you can “upgrade” packages you’ve manually downloaded. I will add a command to automatically upgrade all upgradable packages, which should get you where you want to go.

0 Likes

#6

Sorry, it seemed like overkill to have a repo for 1 file.

0 Likes

#7

yah, no offense taken. Idk, it doesn’t seem like there is a great way. I have sublime running on 5 computers of mine now and syncing multiple plugin repos would have sucked.

0 Likes

#8

You could break them all out into their own repos and then make them all submodules of your SublimePlugins repo.

0 Likes

#9

Version 1.0.7 has been rolled out and your ST should automatically upgrade the next time you start it. Changes include:

  • Installation of packages in a thread to prevent hanging the editor for big packages or slow connections

  • An activity indicator for all remote operations

  • Reduced parallelism for GitHub and BitBucket repositories to help prevent URL timeouts

  • A new Upgrade All Packages command

  • Some work on making package removal on Windows a little more robust

  • The Upgrade Package command no longer lists packages that can be reinstalled

0 Likes

#10

Excellent! I was going to ask about this. Thanks!

0 Likes

#11

How do you do that?

0 Likes

#12

I just want to say this is the most awesome thing! Thank you for all your hard work.

Looking forward to a more packages in the list.

0 Likes

#13

Whoa!!!
Great plugin that work great and look very polished, thanks for your work.

0 Likes

#14

As I said on Twitter, I bloody love this package - so useful for me! But just so as I’m clear, are all the packages that can be installed grabbed from their repositories or a copy that you have made? Are the versions in the Package Manager always going to be the latest?

Cheers again

0 Likes

#15

This is brilliant and I’ve already expressed how awesome it is :smiley:

One thing I do keep experiencing is an error when trying to upgrade SublimeCodeIntel:

Package Control: Error downloading package. URL error The read operation timed out downloading https://nodeload.github.com/Krounz/SublimeCodeIntel/zipball/mster.

Strange… I ran the upgrade option again and it installed!

0 Likes

#16

Upgrade All Packages will upgrade every package that shows up in the list when you run Upgrade Package. Upgrade Package will show all packages it recognizes the name of, even if you installed them manually or through a vcs. I hope that wasn’t too confusing.

0 Likes

#17

It depends on what kind of repository is used. All packages coming from GitHub or BitBucket will always be the latest version, and are always pulled from master, or tip, respectively. For a custom repository JSON file (like at sublime.wbond.net/packages.json) you have to manually update the JSON and package files. I do this so that I can control the version numbers, and what platforms Tortoise is available for.

All of the repositories are pulled on the fly from sublime.wbond.net/repositories.json. This allows for adding a new repository for all users without anyone having to upgrade their version of Package Control. For instance, about 12 hours after I launched Package Control I added the SublimeCodeIntel repository since it seems pretty popular.

0 Likes

#18

[quote=“jbrooksuk”]One thing I do keep experiencing is an error when trying to upgrade SublimeCodeIntel:

Package Control: Error downloading package. URL error The read operation timed out downloading https://nodeload.github.com/Krounz/SublimeCodeIntel/zipball/mster.

Strange… I ran the upgrade option again and it installed![/quote]

With Package Control 1.0.6, I did all requests to GitHub and BitBucket in parallel, and I started noticing that their APIs seems to be rate limiting stuff and causing connections to fail. In 1.0.7 (the latest as of right now) I only run one downloader per domain at a time to help prevent rate limiting issues. It seems like there are fewer issues now, but occasionally I still have seen problems. I think I’ll add a setting and feature to retry downloads a few times to help get around the unpredictable nature of the APIs. With the new activity indicator and since everything is threaded, this shouldn’t be a big deal performance wise, and will probably be a much nicer user experience.

0 Likes

#19

[quote=“sublimator”]Note that while Sublime will load settings files in nested folders of packages it won’t do the same for python files. It loads only $Package/*.py.

I don’t know how submodules work exactly but that’s something to consider.[/quote]

Ah good point. Submodules probably won’t work then :confused:

0 Likes

#20

Impressive plugin. Finally an easy way to install plugins. But unfortunately this solution isn’t perfect and I need to make a bug report.

The problem is that this plugin is making SublimeText2 build 2101 for Windows7 to crash every-time is downloading from web and I press the ALT key on the keyboard to switch to other application.

Here is the output of the crash report:

Problem signature:
Problem Event Name: APPCRASH
Application Name: sublime_text.exe
Application Version: 1.0.0.1
Application Timestamp: 4e42829f
Fault Module Name: sublime_text.exe
Fault Module Version: 1.0.0.1
Fault Module Timestamp: 4e42829f
Exception Code: c0000005
Exception Offset: 0003fa82
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
go.microsoft.com/fwlink/?linkid= … cid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

0 Likes

#21

Are you using the 32bit or 64bit version of Sublime Text?

0 Likes

#22

[quote=“sublimator”]
So it could nuke commit history and development branches. Ouch.

You could take a look at how PackageSetup.py works.

package_metadata_file = os.path.join(package_dir,
            'package-metadata.json'

Seems you are making a package-metadata.json on installation. Maybe looking for the existence of that would be a good determinant for whether a package gets included in UpgradeAll.[/quote]

So this is certainly an interesting issue. When doing development on the package manager I experienced some issues with using the Installed Packages directory where PackageSetup overwrote changes to my plugins. Unfortunately there is no indication that there is any backup system, although I see there is something now. Because of that I abandoned any use of the Installed Packages directory other than the initial download and installation of Package Control. I looks like I may be able to use PackageSetup.py to perform the upgrade of zip files for me and take care of backing up files. That said, I don’t know how much use those backups are since there is no indication they exist, and then once found would require a diff from the edited version to the pristine version to actually yield anything useful to the user. It does not appear that the pristine package files for the backed up files are saved, making the diff impossible and the backups more or less useless. It is possible I just misunderstand part of what is going on here.

In terms of wiping you VCS files, yes that would happen. However, I also fail to see how it would not happen with PackageSetup.py. I ran into issues with this while testing Package Control and never came up with a completely satisfactory solution. If you are tracking a package via Git, but then request it via Package Control, the downloaded .sublime-package (zip) would not have the git metadata, thus you would lose the commit between versions if you were to commit any changes. Thus is didn’t seem all that useful to explicitly exclude VCS metadata from removal. All of this leads me to believe that the best situation is for Package Control to use Git, SVN or Mercurial when such a working copy is found. For Git I think the best solution would be git pull --rebase, for SVN a simple svn update and for Mercurial hg pull.

All of that said, the behavior you are looking for, to upgrade only packages that have been installed via Package Control, happens automatically whenever ST starts up. The Upgrade All Packages command is basically a convenience command for a user to upgrade/change all of their downloaded packages to things that are tracked by Package Control. This can also be done manually by running Upgrade Package and selecting each package. When you do that, the text for each package indicates the exact action that will happen, including what the new and old versions are. Perhaps I should rename Upgrade All Packages to Upgrade/Overwrite All Packages?

I think these changes sounds like they would solve the problems you are experiencing.

0 Likes

#23

I think a way around sublimator’s problem is to have an ‘ignored packages’ setting like Sublime does itself. That way you could add to your User settings any packages you don’t want Package Control to manage.

Also, a feature request. I could add this myself to me own repo list but I thought I’d put it up as a request for everyone else’s benefit. Can you add github.com/lunixbochs/sublimelint to your master package list? It’s a useful plugin, and is really stable for me (although does rely on a local PHP installation if you want PHP linting, maybe that makes it not a candidate).

0 Likes