Sublime Forum

SublimeText Organization at GitHub!

#1

There’s a growing number of packages, plugins, themes, etc. for Sublime 2. While
the forum’s a fine place to announce new cool stuff, an online repository seems to
be the best way of sharing all of these resources. That’s what SublimeText is for!

Please note this new GitHub organization will only host Sublime 2-compatible
resources.

Naming Conventions for Repositories

In order to keep the organization tidy, we’ve come up with the following simple
rules for repo names:

  • Use CamelCased repo names (that’s what Sublime uses for packages too)
  • Do not append version numbers or any other sort of identifier to the repo name

Examples:

[code]#Good:

MyAwesomeNewPackage

#Bad:

SomePackage-ST2
SomePackage1.0[/code]

Becoming a Member of the Organization

If you want to join the SublimeText organization at GitHub so that you can contribute packages, send an email to:

To: sublimetextorg@gmail.com
Subject: I want access to SublimeText on GitHub
Body: MyGitHubID

Mercurial Users

Don’t panic! We’ll provide instructions to set up Mercurial so you can work
seamlessly with GitHub. There’s some work required to get this up and running,
but it seems to work pretty well. If you want to go ahead and try yourself now,
google “hg-git plugin”.

Process for Moving an Existing Repo into the Organization

a) Simply request for it to be moved here.

b) Create the new repo in the organization. Update the origin remote and push the repo to its new home.

If you’d still like to keep a repo attached to your user account it would be advisable to delete the repo currently attached to your user account, and fork the repo in the organization to take its place. This way it will be more visible to people viewing repos in the org and you will be able to send pull requests along with all the other great things that come with forks.

Minimum Requirements for New Repos

New repos should include a .gitignore file with the following contents:

For people using Git:

*.pyc *.cache *.sublime-project

For people using Mercurial:

*.hgignore *.hgtags *.pyc *.cache *.sublime-project

Other entries can be added as desired but every repo in the org should contain at least the ones shown above.

Old Repository

Packages from the old Google Code repo will not be imported into the SublimeText
org. If you’re a maintainer and you’ve ported one of these, though, just email the
address further up to get access to the org.

Needless to say, feedback’s always welcome!

0 Likes
Plugin Store
Github repo(s) for packages
#2

Awesome! I just forked my LaTeX plugin so it’s now “in the organization”. I also changed the name from the bad “LaTeX-ST2” to the good “LaTeXTools” (it can’t be just LaTeX or it will conflict with the collection of snippets adn syntaxes tha comes with ST2).

If it’s OK, I’ll now work off of that and delete my private repo.

0 Likes
#3

I believe at some point it will make sense to upload all of the packages shipped with the editor to the org. That way they could be improved by the community, Jon would be able to include them in the next release, and the standard collection of packages would evolve faster. For instance, in your case, it seems that it’d be a good idea to include your stuff in the LaTeX package. For now, though, LaTeXTools should work just fine. We’re still working out the details of the org, anyway…

0 Likes
#4

I fully agree, but of course it’s for Jon to decide. The LaTeXTools approach (add to the default facilities without interfering) is a bit awkward, but it gets the job done for now. These are exciting times for sure!

0 Likes
#5

Guillermo,

I have some stuff to contribute to the GitHub repo. Also, I would be willing to help manage the GitHub repo as well if you’d rather be focussing on the info site? Oh, and I need access to it! :wink:

Lemme know…

0 Likes
#6

Hey Greg,

That’s great! What’s your username on GitHub? I don’t have much time left for this, and Anomareh can’t either, so it’d be very helpful to have more admins.

0 Likes
#7

If you want to join the SublimeText organization at GitHub so that you can contribute packages, send an email to:

To: sublimetextorg@gmail.com
Subject: I want access to SublimeText on GitHub
Body: MyGitHubID

0 Likes
#8

I’ve sent an email for me to join :smile:

I have a few plugins to get uploaded!

0 Likes
#9

There may be another thread on this topic somewhere else, so please forgive me if this has already been discussed.

What are the protocols/best practises for incorporating individual commands (aka, plugins, extensions, etc.) into our own packages folder? There are a lot of new commands being developed (fantastic! So much more community involvement than there ever was with E) but they’re popping up in a variety of ways such as individual repos, gists, zip downloads and the like.

What I’d like to know is, should we be encouraging people to include individual commands (such as wbond’s excellent sublime_alignment, ajpalkovic’s excellent new goodies and also dom111’s plugins) in a broader package (say Text or Source or whatever) which is how Textmate is organised? Or is the flexibility and granularity of having commands (or small related suites of commands) in their own package preferred? I can see pros and cons in both approaches.

It would be great if some of these new commands could be placed in the community repo on Github and packaged up in a consistent, standard way, thereby (hopefully) encouraging forking and collaboration. As a great example, I really like how Will (wbond) has packed up sublime_alignment complete with a great readme and prebuilt keymaps. It just works.

0 Likes
#10

That’s something I’ve been thinking about for quite a while now, but I don’t see any satisfactory solution… Without a proper package manager supporting versioning, name conflict resolution, etc., it’s going to be a pretty messy arrangement whichever way you approach it. I don’t know of any light-weight editor that sophisticated with this regard (maybe jEdit?).

In my view, Sublime would ideally be able to use the system’s Python —as opposed to an embedded one—, so packages could conceivably be managed through PyPI. I don’t know whether this is technically possible, but since the infrastructure’s in place already, it looks like the easiest solution to this problem. However, requiring users to download and install both Sublime and Python would raise the entry bar for many users, so it probably goes against Jon’s priorities.

Creating a full new package for every plugin seems to be overkill. I think grouping small plugins in a “Plugins/Text/Source” package is the best way to go at the moment… Unfortunately, I don’t think Mercurial or git (most plugins if not all are hosted either at Bitbucket or GitHub) let you clone single files from a repo. And I don’t think anybody would like to blindly download all the plugins in the org.

So assuming this was the preferred way to deal with loose plugins, I see two compatible options:

  1. We create a Plugins repo in the GitHub org off of which everyone can work
  2. Plugin developers use the system that suits them best and provide a “Plugins.sublime-package” file for download. Sublime will copy the files to the Packages/Plugins folder on its own.

This won’t solve any of the main problems, but at least there’d be a consistent way of obtaining plugins…

With regards to creating .sublime-package files, you might want to take a look at:

bitbucket.org/guillermooo/aaapa … 0/setup.py

I put together a very hackish distutils command (spa) that will collect the files and create the “.sublime-package” for you. But the code might be considered a criminal offense in many countries.

0 Likes
#11

Personally, what I think what would be best is if we could define a plugin in a folder. I could do something like create a ClipboardHistory repo, and in the top level was a file called init.py or something like that. The advantage is that 1) I can use multiple files in the plugin, and 2) To install the plugin, I can just clone the entire repo into my packages folder (I don’t just have to manually download one file). I personally think 2 would be a HUGE win.

So, instead of User/clipboardHistory.py, I would have User/ClipboardHistory/init.py

0 Likes
#12

Hi AJ,

I’ve probably misunderstood, but plugins can be stored in any folder under %APPDATA%\Packages can’t they? They don’t need to be stored in %APPDATA%\Packages\User. I’ve cloned wbond’s Alignment plugin/package/command into %APPDATA%\Packages\Alignment. Nothing needs to go in User.

I have to admit I’m a bit confused as to the distinction between a ‘plugin’ vs a ‘command’ vs a ‘package’.

0 Likes
#13

[quote=“guillermooo”]Creating a full new package for every plugin seems to be overkill. I think grouping small plugins in a “Plugins/Text/Source” package is the best way to go at the moment… Unfortunately, I don’t think Mercurial or git (most plugins if not all are hosted either at Bitbucket or GitHub) let you clone single files from a repo. And I don’t think anybody would like to blindly download all the plugins in the org.

So assuming this was the preferred way to deal with loose plugins, I see two compatible options:

  1. We create a Plugins repo in the GitHub org off of which everyone can work
  2. Plugin developers use the system that suits them best and provide a “Plugins.sublime-package” file for download. Sublime will copy the files to the Packages/Plugins folder on its own.

[/quote]

With strong editorial this seems to be a good compromise. By editorial I mean someone or the community should decide on what is generic and broad enough in appeal to go in the generic “Plugins/Text/Source” package, and what is esoteric enough to go in its own package.

0 Likes
#14

[quote=“charlesroper”]Hi AJ,

I’ve probably misunderstood, but plugins can be stored in any folder under %APPDATA%\Packages can’t they? They don’t need to be stored in %APPDATA%\Packages\User. I’ve cloned wbond’s Alignment plugin/package/command into %APPDATA%\Packages\Alignment. Nothing needs to go in User.

I have to admit I’m a bit confused as to the distinction between a ‘plugin’ vs a ‘command’ vs a ‘package’.[/quote]

I had tried to use folders in the User package, but not as a separate package. I’ve since moved all my plugins into a separate package (and github repo) (github.com/ajpalkovic/SublimePlugins). Thanks.

0 Likes
#15

Quite a while ago I had tried creating a zip file with a filename .sublime-package and it didn’t seem to work with ST2. I just saw your message @guillermooo, so I will try out your code.

I do think that having every little command in its own package is a good thing. What would be useful is some way through ST2 to discover and select packages to install/update. I’m relatively new to python programming, so I don’t know what the current best practice is, but something like sublime_easy_install would be awesome.

I like the suggestions about the repo names for packages being CamelCase, however for discoverability I’ve added the work “sublime” to each repository/package name. This github organization should help some. I’ve also considered setting up a website for plugins. Perhaps it could pull metadata from the github organization and present it in a nice search-engine-friendly way.

To potentially further complicate the situation, I’ve also been spending a lot of time on a package I intend to sell for a small fee. Right now I think I’d like to have a little more friction between someone just downloading it on Github and not ever paying, but I would like to keep with the ST model and allow for an extended trial period. Perhaps this is something I’ll just need to work out on my own.

0 Likes
#16

HELPPP!!!

As of yesterday, I can no longer push to the SublimeText/LaTeXTools repo! This is a problem, as there are a couple of urgent fixes I need to apply.

I noticed that yesterday I was added to the “developers” team, and that I have access to 5 repos… but NOT to LaTeXTools. Can someone (guillermoo) please fix this ASAP!

I like the idea of having a single org for SublimeText plugins, but if this becomes too much of a hassle, I will have to fork the plugin to a repo that I maintain directly.

M

0 Likes
#17

Hi Marciano,

I have next to no idea how to use the org features at GitHub. I’ve tried my best, but I believe too many people have access to the repo now. You should try to talk to barneywilliams (Greg Williams). He did the initial setup and is more familiar with how it works. Let me know whether I can do anything else, though.

0 Likes
#18

Thanks—Greg already replied to an email I sent him via github. Hopefully he will straighten things out…

0 Likes
#19

Actually, whatever you or Greg did worked—I am now able to push again.

I think this has to do with the creation of a “Developers” group. Up until this afternoon, I was a member of the Developers group, but LaTeXTools was not a repository “controlled” by Developers. It now is.

Again, I have access back, so whatever you/Greg did, Thanks!!!

0 Likes
#20

Hi,

Just joined the party with github.com/SublimeText/TrailingSpaces

0 Likes