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