Sublime Forum

SublimeText Organization at GitHub!

#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

#21

Might be a need for another plugin here. We might need something to display all the current keybindings and where they are sourced from. I can see where conflicts can arise by chance.

An example that I like is gnu screen, if you remap keybindings in your .screenrc, the help screen reflect the default + your mods.

0 Likes

#22

Not trying to be difficult , but I am missing the point of the organization. I like the idea of a registry of plugins (ala wbonds json file) but I do not see the benefit in having 19 admins (that do not know each other) for these 20 odd repos.

0 Likes

#23

[quote=“slestak989”]Might be a need for another plugin here. We might need something to display all the current keybindings and where they are sourced from. I can see where conflicts can arise by chance.

An example that I like is gnu screen, if you remap keybindings in your .screenrc, the help screen reflect the default + your mods.[/quote]

I could not agree more, I’ve no clue how to pull it off though. There is no automatic way of doing this as far as I know, you could do it manually but somebody has to keep looking for new bindings in that case.

0 Likes