weixin_39639518
2020-11-29 08:17 阅读 10

Zed Package Manager

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: - https://raw.github.com/TheKiteEatingTree/zed-extensions/master/HTMLHint/ - https://raw.github.com/TheKiteEatingTree/zed-extensions/master/Objective-C/

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.

该提问来源于开源项目:zedapp/zed

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

14条回答 默认 最新

  • weixin_39639518 weixin_39639518 2020-11-29 08:17

    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.

    点赞 评论 复制链接分享
  • weixin_39658619 weixin_39658619 2020-11-29 08:17

    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!

    点赞 评论 复制链接分享
  • weixin_39658619 weixin_39658619 2020-11-29 08:17

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

    点赞 评论 复制链接分享
  • weixin_39639518 weixin_39639518 2020-11-29 08:17

    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!

    点赞 评论 复制链接分享
  • weixin_39658619 weixin_39658619 2020-11-29 08:17

    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.

    点赞 评论 复制链接分享
  • weixin_39639518 weixin_39639518 2020-11-29 08:17

    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.

    点赞 评论 复制链接分享
  • weixin_39639518 weixin_39639518 2020-11-29 08:17

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

    点赞 评论 复制链接分享
  • weixin_39658619 weixin_39658619 2020-11-29 08:17

    Awesome! Very excited about this.

    点赞 评论 复制链接分享
  • weixin_39639518 weixin_39639518 2020-11-29 08:17

    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.

    点赞 评论 复制链接分享
  • weixin_39658619 weixin_39658619 2020-11-29 08:17

    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.

    点赞 评论 复制链接分享
  • weixin_39639518 weixin_39639518 2020-11-29 08:17

    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.

    点赞 评论 复制链接分享
  • weixin_39639518 weixin_39639518 2020-11-29 08:17

    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.

    点赞 评论 复制链接分享
  • weixin_39658619 weixin_39658619 2020-11-29 08:17

    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.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: https://github.com/zedapp/zed/pull/90#issuecomment-36830238

    点赞 评论 复制链接分享
  • weixin_39658619 weixin_39658619 2020-11-29 08:17

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

    点赞 评论 复制链接分享

相关推荐