Package Control: A full-featured package manager

[wbond]

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.

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

[wbond]

[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.

[alexrussell]

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).

[aparajita]

[quote=“sublimator”]

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).

That plugin is great. I love it.[/quote]

This fork is more actively developed: https://github.com/Kronuz/SublimeLint

[alexrussell]

This fork is more actively developed: https://github.com/Kronuz/SublimeLint

Sounds good to me. I never know whether the forks are going to be new/untested stuff waiting for an eventual pull request or an actual more actively developed version.

[wbond]

The main reason I haven’t added a repo for SublimeLint is that I was unable to tell which is the most actively developed and “best.” If there is a general best choice, or a maintain volunteers their version, I’ll add one.

[Anomareh]

After using them both I think the original is just that, and the fork is sort of a + version if you will. They are both actively maintained, I just believe the original is complete in the author’s eyes where as some other people wanted more functionality that the original author wasn’t interested in incorporating.

The original has Python, PHP, Perl and Ruby support where as the fork has added support for JS and Objective-J as well as PEP8 checking for Python.

Which you grab depends on what you’re looking for. Personally I use the fork as I like the PEP8 and JS support.

[aparajita]

The main reason I haven’t added a repo for SublimeLint is that I was unable to tell which is the most actively developed and “best.” If there is a general best choice, or a maintain volunteers their version, I’ll add one.

The Kronuz fork is more active. What is involved in volunteering a version for inclusion?

[wbond]

The Kronuz fork is more active. What is involved in volunteering a version for inclusion?

Just someone indicating they use it and that is seems to be the best and most actively developed version. From the conversation that has happened here is appears that the Kronuz fork is most actively developed, so I’ll add it to the master channel list.

[wbond]

Version 1.1.0 of Package Control was just released for upgrade. Changes include:

• Support for local Git and Hg repositories in addition to zip/.sublime-package downloads

• Fixed Discover Packages command to pull the proper URL from custom repositories

• Improved the handling of upgrades and removal on Windows, reducing the number of Access Denied errors

• Changed the downloaders to try multiple times on timeout since GitHub and BitBucket requests seem to fail fairly frequently

• Package upgrades now copy the complete old version to the Backups folder that is a sibling of the Packages directory

• Fixed the text of the activity indicator during individual package upgrades

Also, the master channel list has been updated to include github.com/Kronuz/SublimeLint.

Thanks for all of the feedback and suggestions, keep them coming!

@sublimator

I very much apologize for causing you to lose work with Upgrade All Packages. This new version should prevent such loss, and should also make it possible for less network-intensive updates via git and hg.

[Anomareh]

Just someone indicating they use it and that is seems to be the best and most actively developed version. From the conversation that has happened here is appears that the Kronuz fork is most actively developed, so I’ll add it to the master channel list.

That’s kind of messed up, but whatever I guess.

[wbond]

[quote=“Anomareh”]

Just someone indicating they use it and that is seems to be the best and most actively developed version. From the conversation that has happened here is appears that the Kronuz fork is most actively developed, so I’ll add it to the master channel list.

That’s kind of messed up, but whatever I guess.[/quote]

I’m certainly open to improving this process. What about the current process do think is messed up?

[Anomareh]

I’m certainly open to improving this process. What about the current process do think is messed up?

One person saying something and acting on it without the repos in question even being looked at.

For one, the Kronuz fork should probably be the aparajita fork at this point as the last month worth of commits have pretty much just been merging his pull requests. Secondly, that fork probably shouldn’t be a fork anymore.

Also I’m not really sure what conversation happened that would affirm the Kronuz fork was the one to go with. aparajita said twice that it was the most actively developed, two people said they weren’t using it or sure about what it actually was, and I gave my impression.

Just seemed rather hasty to me.

[wbond]

[quote=“Anomareh”]

I’m certainly open to improving this process. What about the current process do think is messed up?

One person saying something and acting on it without the repos in question even being looked at.

For one, the Kronuz fork should probably be the aparajita fork at this point as the last month worth of commits have pretty much just been merging his pull requests. Secondly, that fork probably shouldn’t be a fork anymore.

Also I’m not really sure what conversation happened that would affirm the Kronuz fork was the one to go with. aparajita said twice that it was the most actively developed, two people said they weren’t using it or sure about what it actually was, and I gave my impression.

Just seemed rather hasty to me.[/quote]

Point taken, I’ll be sure to be slower before adding repositories that have more than one copy. I did spend a little bit of time looking at the various forks before I added it and also checked out github.com/lunixbochs/sublimelint/network. I also weighed in your and aparajita’s comments. That said, I do think you have a valid point and appreciate you speaking up.

Due to the way that the versioning in Package Control is done, it is actually possible to switch the repository being used for a package at any given time as long as it was pushed after the date the previous repository was pushed.

[Anomareh]

The only reason I really took issue with it is I know what it’s like to want the light version of something and ending up having to go digging around for it. This happens to be one of the occasions that I actually want the heavier version but many a time have I had to either pull apart something to rip off all the stuff I don’t want or go looking for the version where someone has already done it for me.

Personally, I think the ideal solution would be making both versions available, ideally with the fork being split into a new package entirely (SublimeLint+ or something) or being made available as a dev release.

[wbond]

Personally, I think the ideal solution would be making both versions available, ideally with the fork being split into a new package entirely (SublimeLint+ or something) or being made available as a dev release.

That is potentially a good idea for the next version. Right now it is not possible to map the names of individual repositories, just all repositories of a specific name. If I add the ability to map names on a per repository basis, then it would be possible to have both without any changes to the repositories.

Perhaps a better idea that would be clearer to users would be for the fork to rename itself. This would obviously require buy-in by the developer.

It is possible right now to add your own custom repositories to allow someone to use the original, but this doesn’t help solve the discoverability problem for people. It would, however, allow for easy updating.

[aparajita]

My sincere apologies to everyone. I was only looking at the commit histories to see which had been more active recently – whether or not those commits were from me.

For one, the Kronuz fork should probably be the aparajita fork at this point as the last month worth of commits have pretty much just been merging his pull requests.

I don’t want to create yet another fork of the project, nor do I want to be primarily responsible for maintaining it.

Secondly, that fork probably shouldn’t be a fork anymore.

Probably not. I haven’t looked closely to see what the essential differences are between the forks. Ultimately it would be nice if the forks could be unified somehow.

[aparajita]

I actually prefer the original version: it’s responsive, less noisy and seems to have less quirks.

If that’s true, I’ll switch!

What do you mean by “less noisy” and “less quirks”?

[aparajita]

Version 1.1.0 of Package Control was just released for upgrade.

Great work, thank you for making this available.

I want to submit a new package for inclusion in the package repo, how do I go about it?

[Anomareh]

I don’t want to create yet another fork of the project, nor do I want to be primarily responsible for maintaining it.

Heh, you already are You’ve been the only one pushing commits to the fork for the past month. Only difference is you’re sending pull requests instead of just committing.

Probably not. I haven’t looked closely to see what the essential differences are between the forks. Ultimately it would be nice if the forks could be unified somehow.

I don’t think this is possible. Although they seem very similar on paper, internally they are rather different. The original is much stabler and snappier. With the fork everything config wise is quite different.