New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zed Package Manager #90

Merged
merged 22 commits into from Mar 6, 2014

Conversation

Projects
None yet
2 participants
@TheKiteEatingTree
Contributor

TheKiteEatingTree commented Feb 24, 2014

Package Manager that's mostly done. Main thing it needs is documentation. Examples of extensions can be found here: https://github.com/TheKiteEatingTree/zed-extensions

To install those extensions you have to use the raw.github urls:

A few things I'm unsure about:

  • The functions are all callable from the sandbox.
  • UI prompts sometimes dismiss instantly. Not sure if that's something I did wrong or something in the ui prompt code.
  • /config/default/zpm/installed.json doesn't seem to be read-only in the configuration project.
  • I added some code in sandbox.js to console log messages from the webview.
  • update error handling - An extension could be broken if there's an error during an update. But it should fix itself by updating again. I didn't consider this too big of a deal, but I should fix it at some point.
  • uninstall error handling - An extension could get removed from user.json but not be uninstalled. Could still uninstall it later. Or it could fail to delete some files that could then only be removed manually.
@TheKiteEatingTree

This comment has been minimized.

Show comment
Hide comment
@TheKiteEatingTree

TheKiteEatingTree Feb 24, 2014

Contributor

Let me know what you think or want changed. I figured I'd post the pull request now to get more feedback before I start the documentation.

Contributor

TheKiteEatingTree commented Feb 24, 2014

Let me know what you think or want changed. I figured I'd post the pull request now to get more feedback before I start the documentation.

Show outdated Hide outdated app/config/default/mode/installed-extensions.json
{
"modes": {
"installed-extensions": {
"name": "Zed Search Results",

This comment has been minimized.

@zefhemel

zefhemel Feb 24, 2014

Member

This should probably be something different.

@zefhemel

zefhemel Feb 24, 2014

Member

This should probably be something different.

@zefhemel

This comment has been minimized.

Show comment
Hide comment
@zefhemel

zefhemel Feb 24, 2014

Member

First of all: super cool! I've played with it, and OMG, it works :-)

So here are some thoughts:

  1. I'm thinking what the policy should be regarding putting Zed features in the sandbox vs outside of it. Specifically: is ZPM core enough for it to be a Zed "core" feature, or should it live in the sandbox entirely? Currently, it's a bit of a mix, part of it is inside part of it out. I think it can be refactored to 100% inside of the sandbox (by adding a few extra APIs to the sandbox API, like full access to the config file system and a HTTP API -- currently there's http cache, but it's kind of useless). Another approach is to put it fully in the core and not in the sandbox at all. I think we should settle on one or the other, but not a mix. What do you think? I'm perhaps leaning to putting it 100% into the sandbox, so it can upgrade itself.
  2. More minor: I think the ZPM installed extensions screen should also have a "Install new extension" command.
  3. "Executable" locations in the ZPM installed extensions page should pop out a bit more, maybe we can put brackets around them and then we can, later on, create a custom ACE highlighter to highlight them to make clear they're "buttons". Note to self: there should also be a "click" handler for modes, so you can make something happen when the user clicks a region in the document (like: do the same thing as pressing "Enter").
  4. Minor: after installing an extension, the file list of the config project doesn't reload.
  5. Perhaps we should put extensions under a prefix, like: /ext/*

Regarding your questions:

UI prompts sometimes dismiss instantly. Not sure if that's something I did wrong or something in the ui prompt code.

I'm pretty sure this is a bug in the prompt code, I've seen this happen too, I'll look into it, probably has to do with the event I'm listening to.

/config/default/zpm/installed.json doesn't seem to be read-only in the configuration project.

If I remember well, files only available in the static file system (so: hardcoded in the Zed app) show up as read-only, as soon as you put a version on the "user layer", that is: write to the file, which ends up on syncFS, it becomes writable again. I'm uncertain about whether we should force this installed.json file to be read-only, and if it should be under /default or /user/, I think it should be under /user/installed.json. I think this makes it clear it's specific to the user, while /default/* is shared between everybody.

I added some code in sandbox.js to console log messages from the webview.

One thing that's on my todo list is to add a zed::log document with log messages from various sources (including the sandbox), this is a good first step. One thing that is useful for you now, probably is the Sandbox:Show command, which will pop over the webview that hosts the sandbox for ~10 seconds, so you can right-click and get the JavaScript console.

Again, awesome work!

Member

zefhemel commented Feb 24, 2014

First of all: super cool! I've played with it, and OMG, it works :-)

So here are some thoughts:

  1. I'm thinking what the policy should be regarding putting Zed features in the sandbox vs outside of it. Specifically: is ZPM core enough for it to be a Zed "core" feature, or should it live in the sandbox entirely? Currently, it's a bit of a mix, part of it is inside part of it out. I think it can be refactored to 100% inside of the sandbox (by adding a few extra APIs to the sandbox API, like full access to the config file system and a HTTP API -- currently there's http cache, but it's kind of useless). Another approach is to put it fully in the core and not in the sandbox at all. I think we should settle on one or the other, but not a mix. What do you think? I'm perhaps leaning to putting it 100% into the sandbox, so it can upgrade itself.
  2. More minor: I think the ZPM installed extensions screen should also have a "Install new extension" command.
  3. "Executable" locations in the ZPM installed extensions page should pop out a bit more, maybe we can put brackets around them and then we can, later on, create a custom ACE highlighter to highlight them to make clear they're "buttons". Note to self: there should also be a "click" handler for modes, so you can make something happen when the user clicks a region in the document (like: do the same thing as pressing "Enter").
  4. Minor: after installing an extension, the file list of the config project doesn't reload.
  5. Perhaps we should put extensions under a prefix, like: /ext/*

Regarding your questions:

UI prompts sometimes dismiss instantly. Not sure if that's something I did wrong or something in the ui prompt code.

I'm pretty sure this is a bug in the prompt code, I've seen this happen too, I'll look into it, probably has to do with the event I'm listening to.

/config/default/zpm/installed.json doesn't seem to be read-only in the configuration project.

If I remember well, files only available in the static file system (so: hardcoded in the Zed app) show up as read-only, as soon as you put a version on the "user layer", that is: write to the file, which ends up on syncFS, it becomes writable again. I'm uncertain about whether we should force this installed.json file to be read-only, and if it should be under /default or /user/, I think it should be under /user/installed.json. I think this makes it clear it's specific to the user, while /default/* is shared between everybody.

I added some code in sandbox.js to console log messages from the webview.

One thing that's on my todo list is to add a zed::log document with log messages from various sources (including the sandbox), this is a good first step. One thing that is useful for you now, probably is the Sandbox:Show command, which will pop over the webview that hosts the sandbox for ~10 seconds, so you can right-click and get the JavaScript console.

Again, awesome work!

@zefhemel

This comment has been minimized.

Show comment
Hide comment
@zefhemel

zefhemel Feb 24, 2014

Member

Just want to reference the issue this is resolving: #84

Member

zefhemel commented Feb 24, 2014

Just want to reference the issue this is resolving: #84

@TheKiteEatingTree

This comment has been minimized.

Show comment
Hide comment
@TheKiteEatingTree

TheKiteEatingTree Feb 25, 2014

Contributor

Thanks! It turned out to be a bit more work than I was anticipating, but it's turned into a fun little project.

I think it can be refactored to 100% inside of the sandbox (by adding a few extra APIs to the sandbox API, like full access to the config file system and a HTTP API -- currently there's http cache, but it's kind of useless). Another approach is to put it fully in the core and not in the sandbox at all. I think we should settle on one or the other, but not a mix. What do you think? I'm perhaps leaning to putting it 100% into the sandbox, so it can upgrade itself.

My vote is also for the sandbox. Updating itself would be very cool. My only concern with it going 100% in the sandbox is that it would require an api that would allow any extension to delete every other extension.

More minor: I think the ZPM installed extensions screen should also have a "Install new extension" command.

Completely agree and on my todo list.

"Executable" locations in the ZPM installed extensions page should pop out a bit more, maybe we can put brackets around them and then we can, later on, create a custom ACE highlighter to highlight them to make clear they're "buttons".

I definitely want to do custom hightlighting at some point. Using brackets seems like a good stop-gap solution though.

Minor: after installing an extension, the file list of the config project doesn't reload.

I noticed this, but it never occurred to me to do anything about it other than manually reload the list. Adding it to my todo list.

Perhaps we should put extensions under a prefix, like: /ext/*

Definitely a good idea. We could limit the configfs APIs to only be able to write/delete files here as well then if we wanted.

I'm uncertain about whether we should force this installed.json file to be read-only, and if it should be under /default or /user/, I think it should be under /user/installed.json. I think this makes it clear it's specific to the user, while /default/* is shared between everybody.

This makes sense to me. My feeling was that it should be read only so someone doesn't edit it and cause themselves problems. I'm not really a big fan of being protected from myself though. And if something were to go wrong editing this file could be useful. If everything goes in the sandbox it could live at /ext/installed.json or /ext/zpm/installed.json. Or we could put it at /user/installed_extensions.json either way.

One thing that is useful for you now, probably is the Sandbox:Show command, which will pop over the webview that hosts the sandbox for ~10 seconds, so you can right-click and get the JavaScript console.

This sounds extremely useful. Thanks!

Contributor

TheKiteEatingTree commented Feb 25, 2014

Thanks! It turned out to be a bit more work than I was anticipating, but it's turned into a fun little project.

I think it can be refactored to 100% inside of the sandbox (by adding a few extra APIs to the sandbox API, like full access to the config file system and a HTTP API -- currently there's http cache, but it's kind of useless). Another approach is to put it fully in the core and not in the sandbox at all. I think we should settle on one or the other, but not a mix. What do you think? I'm perhaps leaning to putting it 100% into the sandbox, so it can upgrade itself.

My vote is also for the sandbox. Updating itself would be very cool. My only concern with it going 100% in the sandbox is that it would require an api that would allow any extension to delete every other extension.

More minor: I think the ZPM installed extensions screen should also have a "Install new extension" command.

Completely agree and on my todo list.

"Executable" locations in the ZPM installed extensions page should pop out a bit more, maybe we can put brackets around them and then we can, later on, create a custom ACE highlighter to highlight them to make clear they're "buttons".

I definitely want to do custom hightlighting at some point. Using brackets seems like a good stop-gap solution though.

Minor: after installing an extension, the file list of the config project doesn't reload.

I noticed this, but it never occurred to me to do anything about it other than manually reload the list. Adding it to my todo list.

Perhaps we should put extensions under a prefix, like: /ext/*

Definitely a good idea. We could limit the configfs APIs to only be able to write/delete files here as well then if we wanted.

I'm uncertain about whether we should force this installed.json file to be read-only, and if it should be under /default or /user/, I think it should be under /user/installed.json. I think this makes it clear it's specific to the user, while /default/* is shared between everybody.

This makes sense to me. My feeling was that it should be read only so someone doesn't edit it and cause themselves problems. I'm not really a big fan of being protected from myself though. And if something were to go wrong editing this file could be useful. If everything goes in the sandbox it could live at /ext/installed.json or /ext/zpm/installed.json. Or we could put it at /user/installed_extensions.json either way.

One thing that is useful for you now, probably is the Sandbox:Show command, which will pop over the webview that hosts the sandbox for ~10 seconds, so you can right-click and get the JavaScript console.

This sounds extremely useful. Thanks!

@zefhemel

This comment has been minimized.

Show comment
Hide comment
@zefhemel

zefhemel Feb 25, 2014

Member

Regarding the ability for an extension to remove all files: I don't think that's something we have to prevent right now. The reason to put extensions in a sandbox (other than a clear security requirement for Chrome Apps) is prevent extensions from somehow killing the editor. Already today they have full write access to every file in a project, so giving them delete access to the config project is not that big a deal. If at some point we don't trust the extensions anymore we probably have to revisit the APIs anyway.

Member

zefhemel commented Feb 25, 2014

Regarding the ability for an extension to remove all files: I don't think that's something we have to prevent right now. The reason to put extensions in a sandbox (other than a clear security requirement for Chrome Apps) is prevent extensions from somehow killing the editor. Already today they have full write access to every file in a project, so giving them delete access to the config project is not that big a deal. If at some point we don't trust the extensions anymore we probably have to revisit the APIs anyway.

@TheKiteEatingTree

This comment has been minimized.

Show comment
Hide comment
@TheKiteEatingTree

TheKiteEatingTree Feb 25, 2014

Contributor

Ah yea didn't think about that. Not too big of a deal then. Also need to have a level of trust for extensions to be useful. I'm thinking the sandbox is probably the way to go then.

Contributor

TheKiteEatingTree commented Feb 25, 2014

Ah yea didn't think about that. Not too big of a deal then. Also need to have a level of trust for extensions to be useful. I'm thinking the sandbox is probably the way to go then.

moved zpm entirely into the configuration project. Created apis to wr…
…ite and delete configfs files. Created api to download files. Added a handler that fires once after configuration loads.
@TheKiteEatingTree

This comment has been minimized.

Show comment
Hide comment
@TheKiteEatingTree

TheKiteEatingTree Feb 28, 2014

Contributor

Moved everything into the sandbox and got it working again. Haven't addressed the other issues yet.

Contributor

TheKiteEatingTree commented Feb 28, 2014

Moved everything into the sandbox and got it working again. Haven't addressed the other issues yet.

@zefhemel

This comment has been minimized.

Show comment
Hide comment
@zefhemel

zefhemel Feb 28, 2014

Member

Awesome! Very excited about this.

Member

zefhemel commented Feb 28, 2014

Awesome! Very excited about this.

TheKiteEatingTree added some commits Mar 1, 2014

Added brackets around commands on installed extensions page. Added in…
…stall extension command to installed extensions page. Changed how updating works to try to make it less likely that an extension breaks during a failed update. If you're in the configuration project when installing, updating or uninstalling an extension the filelist now reloads
@TheKiteEatingTree

This comment has been minimized.

Show comment
Hide comment
@TheKiteEatingTree

TheKiteEatingTree Mar 2, 2014

Contributor

Main thing left is fixing the UI prompts. The install prompt is really annoying when launching from the installed extensions page. I think the issue is related to the prompt listening for keyup and the extension listening for keydown. I'll look into this when I get a chance.

Check the last commit message for things that I fixed/updated. Let me know if I missed something or you just want something changed!

I did a really quick test(I just changed the version and what a prompt says) surrounding zpm updating itself and it seemed to work. Is that something we want to do now or worry about later? I'm not sure how you'd want to set it up if it could update itself separate from zed itself.

Contributor

TheKiteEatingTree commented Mar 2, 2014

Main thing left is fixing the UI prompts. The install prompt is really annoying when launching from the installed extensions page. I think the issue is related to the prompt listening for keyup and the extension listening for keydown. I'll look into this when I get a chance.

Check the last commit message for things that I fixed/updated. Let me know if I missed something or you just want something changed!

I did a really quick test(I just changed the version and what a prompt says) surrounding zpm updating itself and it seemed to work. Is that something we want to do now or worry about later? I'm not sure how you'd want to set it up if it could update itself separate from zed itself.

@zefhemel

This comment has been minimized.

Show comment
Hide comment
@zefhemel

zefhemel Mar 3, 2014

Member

Very cool stuff. So I've been thinking a bit about package management and editors and how I'd like it to work, let me know what you think:

As I see it, one important difference between how extensions/preferences/config works vs Emacs (and perhaps also Vim, not entirely sure) is that it's declarative rather than imperative. Emacs basically gives you a startup file with lisp commands to run to step-by-step build the environment you like, simply by executing lisp commands one at a time. Zed, with its JSON format for configuration is declarative: you specify the configuration you want and Zed just makes it happen (usually within a few seconds). In fact, the convenience commands for setting the font size etc simply update the preference in the configuration object and save it, and let Zed itself figure out what happened and apply the change.

I was thinking: can we make ZPM work the same way? Here's what I'm proposing:we add a "packages" key to the configuration JSON file format listing package URIs:

{
  "packages": ["gh:zedapp/improved-javascript:master", "https://raw.github.com/TheKiteEatingTree/zed-extensions/master/HTMLHint/", "bb:zefhemel/my-other-extension"]
}

Now I used three types of URIs for packages, the first is a convenience notation for github (and translate to roughly the second example), the second one is a raw HTTP link, and the third is for packages hosted on bitbucket. We can add others, too.

Now, whenever the configuration is (re)loaded (a handler should be added for this event), ZPM verifies that all packages listed in the packages array are present under /ext/ (and I'm proposing using something like /ext/gh/zedapp/improved-javascript/master rather than the dot notation). If they're not present, they'll be downloaded and installed. Once they are present, their JSON file will be imported.

Now I still think there should be a "ZPM Install" command that adds to this array automatically, and it should probably also support the gh: and bb: notations there (in the future we should add repo support too, of course).

Now, this config-based approach unlocks a cool feature: /zedconfig.json support. That is, you can now check in a zedconfig.json with your project that includes a number of ZPM packages that you should be using to edit on it. If these packages are not already installed, they would be once first load the project, but they would only be active in that project (while still being present/cached in the Configuration project, just not listed in the main config's packages array, so not loaded in other projects).

So, if you want your contributors to always have specific settings (tab size), or specific Zed extensions, you can specify this in zedconfig.json and they'd get this automatically. A use case that I'm thinking of is a simple Zed-based CMS package that I've been thinking about. If I wrote this CMS as a Zed package, and in the repo of my website added it to packages, everybody can now clone my repo, open in in Zed and start making changes and generating HTML for them.

I think that's pretty cool.

So that's one thing. The other thing is that, inspired with how Github's new AtomEditor does things, is to basically rip out all current language modes and other extensions and put them in separate repos. This makes the Zed core much smaller.

However, we'd still list many of these packages under packages in the default config, so that, upon first load, all packages would be fetched from github (or wherever) and installed (and be kept up to date, separate from the Zed release cycle). This way we have a nice separation of core editor and packages, making it easier for people to contribute.

So... this is all a lot of work (although, probably it's not that bad). The question is two-fold:

  1. What do you think?
  2. Shall I take this on, or do you prefer to do it?

Let me know! I'll also link to this in the Zed user group to see if anybody has opinions.

Member

zefhemel commented Mar 3, 2014

Very cool stuff. So I've been thinking a bit about package management and editors and how I'd like it to work, let me know what you think:

As I see it, one important difference between how extensions/preferences/config works vs Emacs (and perhaps also Vim, not entirely sure) is that it's declarative rather than imperative. Emacs basically gives you a startup file with lisp commands to run to step-by-step build the environment you like, simply by executing lisp commands one at a time. Zed, with its JSON format for configuration is declarative: you specify the configuration you want and Zed just makes it happen (usually within a few seconds). In fact, the convenience commands for setting the font size etc simply update the preference in the configuration object and save it, and let Zed itself figure out what happened and apply the change.

I was thinking: can we make ZPM work the same way? Here's what I'm proposing:we add a "packages" key to the configuration JSON file format listing package URIs:

{
  "packages": ["gh:zedapp/improved-javascript:master", "https://raw.github.com/TheKiteEatingTree/zed-extensions/master/HTMLHint/", "bb:zefhemel/my-other-extension"]
}

Now I used three types of URIs for packages, the first is a convenience notation for github (and translate to roughly the second example), the second one is a raw HTTP link, and the third is for packages hosted on bitbucket. We can add others, too.

Now, whenever the configuration is (re)loaded (a handler should be added for this event), ZPM verifies that all packages listed in the packages array are present under /ext/ (and I'm proposing using something like /ext/gh/zedapp/improved-javascript/master rather than the dot notation). If they're not present, they'll be downloaded and installed. Once they are present, their JSON file will be imported.

Now I still think there should be a "ZPM Install" command that adds to this array automatically, and it should probably also support the gh: and bb: notations there (in the future we should add repo support too, of course).

Now, this config-based approach unlocks a cool feature: /zedconfig.json support. That is, you can now check in a zedconfig.json with your project that includes a number of ZPM packages that you should be using to edit on it. If these packages are not already installed, they would be once first load the project, but they would only be active in that project (while still being present/cached in the Configuration project, just not listed in the main config's packages array, so not loaded in other projects).

So, if you want your contributors to always have specific settings (tab size), or specific Zed extensions, you can specify this in zedconfig.json and they'd get this automatically. A use case that I'm thinking of is a simple Zed-based CMS package that I've been thinking about. If I wrote this CMS as a Zed package, and in the repo of my website added it to packages, everybody can now clone my repo, open in in Zed and start making changes and generating HTML for them.

I think that's pretty cool.

So that's one thing. The other thing is that, inspired with how Github's new AtomEditor does things, is to basically rip out all current language modes and other extensions and put them in separate repos. This makes the Zed core much smaller.

However, we'd still list many of these packages under packages in the default config, so that, upon first load, all packages would be fetched from github (or wherever) and installed (and be kept up to date, separate from the Zed release cycle). This way we have a nice separation of core editor and packages, making it easier for people to contribute.

So... this is all a lot of work (although, probably it's not that bad). The question is two-fold:

  1. What do you think?
  2. Shall I take this on, or do you prefer to do it?

Let me know! I'll also link to this in the Zed user group to see if anybody has opinions.

@TheKiteEatingTree

This comment has been minimized.

Show comment
Hide comment
@TheKiteEatingTree

TheKiteEatingTree Mar 4, 2014

Contributor

I think the packages idea is brilliant. I was originally thinking about having an option to only apply packages to zedconfig.json instead of user.json, but it didn't seem useful enough to be worth the effort the way it works now. But if the same syntax that describes the package as applied also triggers it to install then it becomes incredibly useful. Setting up extensions for a project and sharing them with an entire team just by pushing zedconfig.json would be awesome.

I also agree with the folder structure and github/bitbucket shortcuts.

And almost everything that can be should be an extension. This just makes sense to me.

As far as who works on it, I don't really care to be honest. I'm definitely interested in continuing to work on this, but also want it done and in zed so I can use it! Also I will not have any time to work on it during the week, so if you do please do.

Contributor

TheKiteEatingTree commented Mar 4, 2014

I think the packages idea is brilliant. I was originally thinking about having an option to only apply packages to zedconfig.json instead of user.json, but it didn't seem useful enough to be worth the effort the way it works now. But if the same syntax that describes the package as applied also triggers it to install then it becomes incredibly useful. Setting up extensions for a project and sharing them with an entire team just by pushing zedconfig.json would be awesome.

I also agree with the folder structure and github/bitbucket shortcuts.

And almost everything that can be should be an extension. This just makes sense to me.

As far as who works on it, I don't really care to be honest. I'm definitely interested in continuing to work on this, but also want it done and in zed so I can use it! Also I will not have any time to work on it during the week, so if you do please do.

zefhemel added some commits Mar 4, 2014

Merge branch 'master' into zpm
Conflicts:
	app/config/api/zed/config_fs.js
	app/config/api/zed/http.js
	app/config/api/zed/project.js
	app/js/sandbox.js

@zefhemel zefhemel referenced this pull request Mar 5, 2014

Merged

Updates to ZPM #1

@TheKiteEatingTree

This comment has been minimized.

Show comment
Hide comment
@TheKiteEatingTree

TheKiteEatingTree Mar 6, 2014

Contributor

Made some small changes in the last 2 commits.

One minor thing I've thought of while starting to make my packages work again: Script URLs inside config.json. Right now I believe you have to write out the whole path to a script like this:

"Tools:Spelling:Check": {
        "scriptUrl": "/packages/gh/zedapp/spellchecker/check.js"
  }

This is fine assuming everyone installs the package the same way, but if you install the package with https://raw.github.com/zedapp/spellchecker/master/ it won't work. I don't think this is a big deal since I can't imagine using the raw url over the github syntax, but thought I'd mention it.

Contributor

TheKiteEatingTree commented Mar 6, 2014

Made some small changes in the last 2 commits.

One minor thing I've thought of while starting to make my packages work again: Script URLs inside config.json. Right now I believe you have to write out the whole path to a script like this:

"Tools:Spelling:Check": {
        "scriptUrl": "/packages/gh/zedapp/spellchecker/check.js"
  }

This is fine assuming everyone installs the package the same way, but if you install the package with https://raw.github.com/zedapp/spellchecker/master/ it won't work. I don't think this is a big deal since I can't imagine using the raw url over the github syntax, but thought I'd mention it.

@zefhemel

This comment has been minimized.

Show comment
Hide comment
@zefhemel

zefhemel Mar 6, 2014

Member

Yes, I've been thinking about this too. I think I'll add relative paths that resolve relative to the .json file they're located in. — Zef

Sent from my iPhone

On Thu, Mar 6, 2014 at 8:06 AM, Andrew Stephan notifications@github.com
wrote:

Made some small changes in the last 2 commits.
One minor thing I've thought of while starting to make my packages work again: Script URLs inside config.json. Right now I believe you have to write out the whole path to a script like this:
"Tools:Spelling:Check": {
"scriptUrl": "/packages/gh/zedapp/spellchecker/check.js"
}

This is fine assuming everyone installs the package the same way, but if you install the package with https://raw.github.com/zedapp/spellchecker/master/ it won't work. I don't think this is a big deal since I can't imagine using the raw url over the github syntax, but thought I'd mention it.

Reply to this email directly or view it on GitHub:
#90 (comment)

Member

zefhemel commented Mar 6, 2014

Yes, I've been thinking about this too. I think I'll add relative paths that resolve relative to the .json file they're located in. — Zef

Sent from my iPhone

On Thu, Mar 6, 2014 at 8:06 AM, Andrew Stephan notifications@github.com
wrote:

Made some small changes in the last 2 commits.
One minor thing I've thought of while starting to make my packages work again: Script URLs inside config.json. Right now I believe you have to write out the whole path to a script like this:
"Tools:Spelling:Check": {
"scriptUrl": "/packages/gh/zedapp/spellchecker/check.js"
}

This is fine assuming everyone installs the package the same way, but if you install the package with https://raw.github.com/zedapp/spellchecker/master/ it won't work. I don't think this is a big deal since I can't imagine using the raw url over the github syntax, but thought I'd mention it.

Reply to this email directly or view it on GitHub:
#90 (comment)

@zefhemel

This comment has been minimized.

Show comment
Hide comment
@zefhemel

zefhemel Mar 6, 2014

Member

Ok I'm merging this stuff in and then we can tweak from there.

Member

zefhemel commented Mar 6, 2014

Ok I'm merging this stuff in and then we can tweak from there.

zefhemel added a commit that referenced this pull request Mar 6, 2014

@zefhemel zefhemel merged commit 0dbe190 into zedapp:master Mar 6, 2014

@TheKiteEatingTree TheKiteEatingTree deleted the TheKiteEatingTree:zpm branch Mar 24, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment