wbond / packagecontrol.io Goto Github PK

There is no mention for the package to be in alphabetical order on the https://sublime.wbond.net/docs/developers site, it should be added.

Also, mentioning the included tests should help to remove most failing commits from the pull request queue since users/dev will (hopefully) test their modifications before committing/pushing.

(Sorry that I'm opening so many issues but I consider this as a shared todo list and it will certainly help once someone decides to take on all or most of them.)

I have my package in channel.json. Pushed some code and created a new tag for my package. Pushed tag ti github and nothing happens in channel.json.

When is https://sublime.wbond.net/channel.json updated? evey hour, night or the next push to this repo?

Would be nice if this info was explained in a "Update Packages" section here;
https://sublime.wbond.net/docs/developers

Add documentation about how to uninstall Package Control

Add some documentation about how every file in a repo is downloaded by every user. Thus package developers shouldn't host a bunch of images in their repo. We should do some testing to see if they can reference an image from one branch in the readme of another.

Since this is a core feature of Package Control on ST3 it should be mentioned in https://sublime.wbond.net/docs/developers and not only on the forum and the issue tracker.

sorry wrong repo

https://packagecontrol.io/docs/submitting_a_package

There is an issue with the way the markdown parser on the website handles lists.

This is the original, on GitHub:
https://github.com/p3lim/sublime-toxin#options

On the website, the list is not displayed as a list:
https://packagecontrol.io/packages/Theme%20-%20Toxin

I'm aware that by proper markdown syntax, I should probably add a newline before the actual list, but GitHub handles it gracefully. This might be an issue with the Markdown parser you're using, not the website itself, but should still be considered a bug.

(Originally submitted at the wrong repo here: wbond/package_control#912)

In the dependency docs, at least the example-repository.json link points to the wrong lines, likely because the master branch has been updated since.

There are two ways to solve this:

1. Point to the file version of a certain commit (e.g. latest as of writing). When viewing a file on github ina branch, press y for that.
2. Always update the links in case something changes.

While usually both solutions require an update of the links to work perfectly,
2 has the advantage in that new information will always be displayed, just not always exactly where the highlight is, and 1 has the advantage of always pointing to the right lines.

The same probably applies to other github references on other pages.

If you run view-source on the website, you'll see that there is an excessive amount of whitespace being generated on each li element, after the a tag.

I've had this issues for as long as the new design exists actually, but never reported it iirc.

Basically, when I open a url such as https://packagecontrol.io/docs/submitting_a_package#Step_7, the page is not scrolled. Or rather, it seems to get scrolled very shorly and then immediately scrolled back to the top. I have to press ctrl+l, enter to jump to the correct location.

There's a problem with the download counter for packages that have been renamed. The overall counter restarts at zero once a package is renamed, while the statistics for the individual operating systems work as desired.

wbond/package_control#976

Right now the implicit vs explicit versioning scheme is not evident to anyone who has not worked on the guts of PC.

Add docs about package event helpers for package developers

In addition to #8, we should encourage developers to try installing a package via Add Repository before adding it to the main channel.

https://sublime.wbond.net/packages/SublimeCodeIntel is showing 2.0.2-st3 when it should be showing 2.0.2.

I can't to visit https://packagecontrol.io/.I come from China!

When hovering the Linux badge. See attached screenshot:

I have two versions of SublimeLinter available, 1.7.2+1 for ST2 and 3.0.25 for ST3. I would like the ST3 version to display on https://sublime.wbond.net/packages/SublimeLinter, but the ST2 version is displaying. It used to display the ST3 version, not sure what happened.

Getting NXDOMAIN. Can you please renew the domain?
Cheers

Many packages use the Theme - Themename or Color Scheme - Schemename conventions for their packages, but some don't.

Should we mention this in the docs?

(Source: wbond/package_control_channel#3408)

Improve the purge documentation and add a section to check and see if PC is disabled.

I practically can't use the binding, even though I'm used to it from ST.

I think it should be possible to just prevent the event from propagating when it was processed to focus the search panel, since you'll rarely need that binding exactly when you are browsing the package listing. There are ofc bindings where this would not be an option, e.g. "ctrl+tab".

From wbond/package_control#921

I set a search keyword pc in firefox which evals to https://sublime.wbond.net/search/%s. I can enter pc in the locationbar and I'm redirected to to https://sublime.wbond.net/search/ (which I do when I just need to go to the site), but clicking any navigation button does not work then. The location changes but no contents are loaded.

Bare email addresses are turned into links prefixed with the GutHub url prefix.
I tried to remedy the problem by creating a specific mailto: link but it is still prefixed incorrectly.

https://raw.githubusercontent.com/davidolrik/sublime-rsync-ssh/master/mailto:[email protected]

Example is taken from here https://packagecontrol.io/packages/Rsync%20SSH

So, this is the same issue as reported at wbond/package_control#875, but it was really annoying for me for probably a year, which is why I finally decided to create an issue. I remember mentioning this at some point but probably only in a "by the way" clause.

Basically, what seems to be happening is that after a certain delay a "search" gets triggered for live preview and the search box is set with the text the search was issued with as the reply is received, which results in the following:

1. Any text input entered between the submission of the "current" text value and the receival of the server's reply is just lost since it's replaced with the initial text of the search query.
2. The caret is always put to the end of the input (and selection is cleared).

Certain timing is necessary to trigger 1. so that the text is entered during that short time frame.

Example show casing both cases:
As explained in the referenced issue, type "abc", then select all text using ctrl+a and type 123.
If I am fast enough I get asd23 or asd3 in the input field.

Similarly to #25, if the repository url changes (either repo name, author name or organization) PC will not be able to pick up the new package. While I think the crawler should be able to follow redirects, we should mention this at least somewhere in the docs.

Source: wbond/package_control_channel#3667

I use a couple @name literal code sequences in my readme for CSScheme and the markdown converter seems to auto-link these to twitter profiles - even in backticked code segments.

It seems to be including seconds fraction which is breaking some readers.

We are actually pretty late with this, but it was brought up in wbond/package_control_channel#2067.

Anyway, some docs/tips for how too migrate to the new schema (e.g. remove your old custom packages.json, do not switch from explicit to implicit versioning ...) would surely help.

Opinions?

I'm kind of lost why it doesn't work, but apparently the crawler can't find valid semvers on my CSScheme repo, even though there are.

https://packagecontrol.io/packages/CSScheme
https://github.com/FichteFoll/CSScheme/tags
https://github.com/FichteFoll/sublime_packages/blob/master/package_control.json#L30-L43

I suspect it's the "tags": true & "tags": "st2-" setup.

When opening the url to a package that has been renamed or merged into another package, you just get a 404. I suggest either setting up a redirect or displaying a special page that shows what happened (e.g. "was renamed to xy" (with link) ).

We should really have one

Please see: wbond/package_control_channel#3844

If a package provides a pre-release version, it should be treated separately since PC has a specific option for that. I think of displaying both, the latest stable and the latest pre-release version, only if the pre-release is higher than the latest stable.

from @randy3k on wbond/package_control#918:

In my package page: https://packagecontrol.io/packages/UnitTesting
The appveyor badge is not correctly shown (while the travis badge does not have any problems).

My appveyor badge url: https://ci.appveyor.com/api/projects/status/9nnjlnj6tetbxuqd/branch/master?svg=true

I suspect it is related to the ?svg=true options in the url.

Example:

https://sublime.wbond.net/packages/InsertDate Usage > Screenshot > "Settings"

This is supposed to be a relative link to the settings section. The renderer, however, does not add the anchors from headers to the source and relativates the link to https://raw.githubusercontent.com/FichteFoll/sublimetext-insertdate/master/#settings, which is just wrong.

I mentioned this in the earlier days of dependencies, but there currently is no way to find out which dependencies are available (and for which platform/st version) besides checking https://github.com/wbond/package_control_channel/blob/master/repository/dependencies.json or https://packagecontrol.io/channel_v3.json manually.

Windows users seems to run into error 12057 a fair amount due to poorly configured proxy servers. We should create a docs page that Package Control can direct users to so they can change their internet settings.

It should have info similar to http://www.genopro.com/ssl/, but I'd rather put it on the Package Control site so we don't have to worry about that page going away.

As you know, GitHub allow you to use the three back-ticks followed by a syntax name such as ````json` which then changes the highlighting to be JSON specific.

This is really handy to see, so would it be possible to add this to the README which gets rendered on the package page?

Often times I want to browse a package's source code and search for it using the package listing. Then, every time a plugin author has set a different homepage I have to go to the issues link and then to the main repo which is kind of annoying.

(I don't know a single situation where I personally wanted to go to a site's "homepage" instead of the repo to check the source code.)

Add docs about dependencies for package developers

Github has a nice Watchers/Star gazers/Forks/Pull-requests statistic which usually indicates how much community activity you have for a particular package (in addition to the trend of installations)

I believe github api exposes these counds in the repo endpoint (except stargazers and pulls, which are available in the stargazers endpoint and the pulls endpoint . Also, both these APIs don't require authentication

It would be nice to see this data in a each package's page (or perhaps even in the homepage - as widgets for in each stat)

https://packagecontrol.io/browse/popular

I'll use this ticket as a place to draft the process for reviewing packages. It will be updated over time when I feel like it. Eventually this should be added to packagecontrol.io.
This will allow us to introduce potentially more helpers to the process and can also serve as a checklist for experienced reviewers (such as myself) in case I forget something.

It is assumed that you know about the repository.json file format. See example-repository.json.

Reviewing a package addition to the default Package Control channel

1. Review the pull request.
   1. Check if the tests are passing. If they are not, make the PR author aware of the issue and potentially link to the error line on travis-ci. Beware that there may be scenarios where the tests are incomplete, so always review the changes briefly by yourself.
   2. Check if there are no commits that modifiy an entire file and have 1000+ lines changed. It will completely mess up the history. Request the PR author to fix this by squashing/reverting/opening a new PR.
   3. As of Package Schema 3.0.0, branch-based versioning is not accepted anymore for new packages. They must use tags, even for multi-branched releases for separate ST2 and ST3 versions. There is an example for this in the example-repository.json file.
   4. Confirm that the user who authors the pull request has push access to the repo he wants to add. For an organization, check if the user is part of that organization or check if he pushed commits to the repo.
      If he does not have access, see if the repo's owner has given permission to adding the package to Package Control's default channel or get his acknowledgement in the pull request by mentioning him.
   5. Confirm that the package satisfies our package naming policies.
2. Review the package.
   1. Read the Readme and assure that you somewhat understand what it does. If there is no readme or you don't understand it (e.g. it's written in a language you don't understand), ask the PR author to add a readme, translate it to English (if the package has an international audience) or ask for an explanation.
   2. Search for similar or duplicate packages on https://packagecontrol.io/. If there are any, see below for the "similar packagejs) exist(s)" section. Be smart in your search terms or remember adding a similar package previously.
   3. Check that the repository has correctly formatted semantic version tags with the appropriate prefix specified in the PR. If "tags": true, both no prefix and v will be recognized currently. (wbond/package_control#887)
   4. Check for specific files in the repository:

      1. *.pyc, *.cache binary files are auto-generated by Sublime Text and stored in the same folder in ST2. Unless the package does not ship the .py source files, request the author to remove those files.

      2. The .no-sublime-package file should only be used if really necessary since it complicates overriding and modifying packages locally. Such a file is needed if

         • The plugin code loads binary Python modules.
         • The package executes binaries included in the package itself using the subprocess module.
         • The package runs scripts included in the package using an external application, such as node.
         • A bug in Sublime Text prevents a certain feature to work if in archived state. (none known currently)

         It is not needed for bundling Python modules. Relative imports work in both ST2 and ST3 (although differently for ST2 in the package's root folder). If a module uses numerous absolute imports to import parts of itself (grrr) and an addition to sys.path is necessary, this should also work if the package is archived. TOTEST.

      3. package-metadata.json should not be present! Ask the author to remove it.

      4. If messages.json is present, check if it is correctly formatted (i.e. valid JSON, uses correct keys, specified files actually exist). (docs)

      5. Python plugins that use ST's API must be in the root folder of the repository, otherwise Sublime Text will not find them.

   5. If a package defines no Python plugins, it is generally compatible with all OSes. ST2&3 compatability may depend but is usually the case. Point out if the pull request's requirements are too restrictive.
   6. Optionally, review the source code of Python plugins.
      1. TODO
         major: close all (file) handles; check if the package considers being an archived package on ST3; check if package satisfies its install requirements compatability-wise (does the code work on ST2/3? Windows? does it perhaps work on more than specified?); try to guess if a plugin is taxing on performance
         minor: don't hardcode forward slashes for file paths; point out general flaws in code or give tips
3. If package is a dependency:
   1. TODO

Reviewing a package change in the default Package Control channel

Generally the same steps as for when adding a package apply, except that you don't need to review the package since it has already been done when it was added. However, there are a few additional things to consider in certain situations.

• For a repository rename, check if the old repository url redirects to the new. If it does not, mention that github has a feature that allows renaming a repository that adds 301 redirects and preserves issues and pull requests.
• For a user rename, check that the old user (or repo) url http://github.com/OldFichteFoll redirects to the new user or repo url. This confirms that it was indeed a user rename and not a different user.
• For a package rename (change of name attribute in package data), check that the old package name was added to the previous_names list.

Similar package(s) exist(s)

TODO

Cleaning up old pull requests

TODO

cc @wbond, @joneshf

Since I'll be away from 27th thru 8th it sounded like a good idea to do that now.

If you search for "insertnum" you don't find https://packagecontrol.io/packages/Insert%20Nums.

If you search for "color sublime" you do find https://packagecontrol.io/packages/Colorsublime, but it's on page 5 (which is a different issue; it should be way higher since both word matches are in the name).

Since there is no established standard for package names, even though they should be PascalCase for compatability with Python importing, the website could be a bit smarter in that regard.
I suspect it won't be that easy.

Could not find a version that satisfies the requirement pybars==0.0.5 (from versions: 0.0.1, 0.0.2, 0.0.3, 0.0.4) No matching distribution found for pybars==0.0.5

Only version 0.0.4 is available... (https://pypi.python.org/pypi/pybars)

(https://github.com/wbond/packagecontrol.io/blob/master/setup/requirements.txt#L13)

Should include:

• change the name field
• add previous_names array
• re-order package if necessary (and even cut into new file)
• Make sure that the package itself does not have hard-coded references to its old package name