Sublime Text’s packages are now on GitHub: github.com/sublimehq/Packages. Note that they will not work with any version of Sublime Text older than the current dev build, 3092.

If you wish to make any changes to these and test them locally, the simplest way is to clone the repository, and then symlink the package(s) of interest into your Packages folder, e.g., on OSX:

git clone https://github.com/sublimehq/Packages.git
ln -s `pwd`/Packages/Python ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/Python

After you’ve finished, keep in mind that you’re now overriding a default package, and when Sublime Text updates to a new version, unless you pull the latest changes from the repository, you’ll run the risk of having an out of date package.

On Windows, rather than fiddling around with symlinks, the simplest approach would likely be to download the Portable version, and clone the repository directly as a subdirectory of ‘Data’.

This is awesome, I’m so excited to see what the community brings to them!

Yay!

Any chance you could give some love to Vintage?

Awesome! I cannot express how much I appreciate this!

Now we have a little problem, this repository github.com/SublimeTextIssues/De … ges/issues list organized issues with these packages. Someone has an idea on how to merge the two? There aren’t many options.

1. Move the repository github.com/sublimehq/Packages and replace the content with the open-sourced packages. [the community will lose privileges in the target repository which is not good for organiing stuff (close duplicated, invalid reports, tagging stuff)
2. Close/hide the “issues” feature of github.com/SublimeTextIssues/DefaultPackages
3. Some other idea?

Having all the packages in one big repository will cause too much noise.

For example, I have no interest in many of the packages and because of the noise I won’t subscribe for issue notifications.

With each package in its own repository I can subscribe to only what interests me without the noise.

Deployment and bundling the packages for releases?

Create a tooling project and release policy for packages. A policy like: when a package is ready for release tag it. Semver won’t work, but something similar. Then the tooling project can have a script that uses the github api to grab the latest tagged release for all packages and creates the .sublime-package’s for each release and whatever else needed.

Yeah, I’m also for splitting the packages into their own repos. Laravel does this via a bash script.

Also I don’t know what the best way is to manage both the issues and the packages. We could either have sublimehq privileges or vice-versa.

The main Packages repository could also be superproject and use submodules. Each package in its own repository would be a submodule in the superproject. So you could clone the superproject and run submodules update to get whatever the latest versions of each package are.

I don’t think I’d ever use the superproject so it’s a question of is having a super useful, oppose to a script that packages all the releases to be bundled with ST.

With a package in its own repository there’s no need for symlinks. A straight forward git clone into the local packages directory will do.

With the issues, issues are labelled by package, so porting those to each package repository would be nice. Surely there are scripts out there that can do this.

Just a thought… The “sublimehq” account isn’t an org, so there are no decent permissions on it.

Here is a crazy idea: why not give admin permission to Jon on existing organization? This way, he will still have issues gathered in one place, no need to do any migration or whatever.

As far as packages: +1 vote for repository / language.

Then, sublime could include a onAfterUpdate trigger that will allow running a git pull to update all packages.

If I could, I would.

Organization

[quote=“iamntz”]Here is a crazy idea: why not give admin permission to Jon on existing organization? This way, he will still have issues gathered in one place, no need to do any migration or whatever.
[/quote]

That would mix community packages with default packages and I wouldn’t want that. Instead, I would rather rename the old organization (to something like “SublimeTextCommunity”) and allow Jon to register a new org under the name “SublimeText”. I’m not sure if github properly sets up redirects for the old urls in this case, but I suppose it does.
Jon, if you would like this to happen, please contact me or Guillermo. (We should think of a process of notifying current SublimeText org team members of this change, preferrably before the rename.)

Existing DefaultPackages issues repository

For the “issues” issue I posted github.com/SublimeTextIssues/Core/issues/892 two days ago, which proposes to move the DefaultPackages repository under Jon’s control and then letting him force-push his repo over our few Markdown documents. Problem with that: We would lose issue access and could not manage it anymore, unless Jon adds us as contributers, which currently includes write access to the whole repo (not sure if he would want that).

One Repo per language

Regarding one repository per language, I think there is a serious flaw in that concept: Default packages depend on one another, notably HTML and family. Since these dependencies are not linear (i.e. there is no hierarchial structure, all are on the same level), once can not simply move them to submodules without breaking otherwise atomic commits.
Otherwise I agree that splitting is more convenient for projects that stand on their own (own issues, easy to fork/clone, ability to promote different contributors for selected packages).

Maybe someone knows a solution for this?

No license

Another concern I have about the repo currently is that there is no lincese.

So glad to see this happening - will make keeping language defs up to date.

I opened an issue on github about replacing the JS defs all together.

github.com/sublimehq/Packages/issues/5

[quote=“FichteFoll”]

[quote=“iamntz”]
One Repo per language[/quote]

Regarding one repository per language, I think there is a serious flaw in that concept: Default packages depend on one another, notably HTML and family. Since these dependencies are not linear (i.e. there is no hierarchial structure, all are on the same level), once can not simply move them to submodules without breaking otherwise atomic commits.
Otherwise I agree that splitting is more convenient for projects that stand on their own (own issues, easy to fork/clone, ability to promote different contributors for selected packages).

Maybe someone knows a solution for this?
.[/quote]

Dependencies. Ah, dependencies.

One monolithic repository or lots of little ones, dependencies are still an issue.

A maintainer who has a dependency on another project still needs to monitor changes and developments to the dependency. Only, the monolithic repository is going to make harder. Because to monitor a dependency a maintainer now needs subject themselves to notifications for changes to all the things, every pr, issue, every comment, commit, merge. People won’t do it. It becomes harder to monitor the things of interest.

Package dependency management is the only real solution. It may not be liked, it may not ever be done, it’s a good and solid solution.

Even a poor mans dependency management. Throw a sublime-package.json into every project.

{
    "sublime/json-syntax",
    "requires": {
        "sublime/shell-syntax": "~1.0.0"
    }
}

Have the tooling project I mention earlier deal with it. Semver all the way baby. Let version numbers go to 11.

Ideally the package bundler tool would use the github api and pull down the latest tags and do version resolving.

Or the tooling project can have a hardcoded release.json file which explicitly defines the tagged versions for the latest ST release, and dependencies just need to be monitored by maintainers.

I want to fork the SQL package and work on a T-SQL syntax. Is there an easy way I can do this with the current package layout? Will I just have to make a new repository from scratch and copy the SQL package into it? If I do that, is there an easy way I can merge in upstream changes to the SQL syntax? I’m not the most proficient person with git so if anybody has a solution for this use case, I would be greatly appreciative.

@Nalin: fork the official repo, create the language there, commit, submit pull request.

@iamntz: that’s kinda avoiding the question. I suspect you didn’t read it properly.

@Nalin: git subtree should allow you to filter only commits for the SQL package but since the repo isn’t that old you likely won’t get much out of that. Merging upstream changes also wouldn’t be that easy this way, or at least I don’t know how to tackle it.
If your fork isn’t that different from the original I suggest writing you modification in a way that includes the original syntax and defines prototypes for inclusion.