-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Add PythonVoiceCodingPlugin package #7751
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Automated testing result: SUCCESS
Repo link: PythonVoiceCodingPlugin
Packages added:
- PythonVoiceCodingPlugin
Processing package "PythonVoiceCodingPlugin"
- All checks passed
Removing directories from Also note that PC installs packages in an archived state and I'm not sure if adding a patht to |
firstly happy new year! my best wishes! many thanks for merging as well as for your valuable feedback! I have been looking into your comments today and it seems I have made mistakes which cause trouble with installation via package control. As you correctly pointed out, package control currently installs the repository as a compressed archive under the Installed packages folder as PythonVoiceCodingPlugin.sublime-package file. This is definitely not what I had in mind (I wanted the plug-in to be installed uncompressed under the packages folder instead) and at the same time of course breaks all imports! as a consequence, installation via package control is currently impossible with the version 0.0.4! to address this issue, I have added a .no-sublime-package file. I have tested it on a clean sublime installation by manually adding my repository and installing from the master branch instead of my latest release(I also spent quite a bit of time today trying to make it work with my fix_package_control branch but failed , I must be missing something here) and also made a a 0.0.5-alpha.0 release containing these modifications.as a side note, my apologies this is a very newbie question but would you happen to know how long it takes for future releasees to become visible on package control? Furthermore, many thanks for pointing out that removing those subdirectories from the path has no effect,it will be removed with my next release! However regarding the issue with that third_party folder, I think it is a little bit more complicated. when faced with a decision of how I would provide users with the necessary libraries my project needs I considered three possibilities:
In general, while dependencies probably are the recommended way and my inexperience with plug-in development might be to blame for my conclusions, I was not really that much satisfied by the whole idea. For a start, currently none of my three top level libraries are available as dependencies, at least in the default channel. Down the line I'm looking into ideas that will require several more libraries and all of these themselves could require other libraries to be installed, so the number of pypi packages I need to convert into dependencies and of course maintain can increase. additionally experimenting with a newer version of the pypi package seems much simpler. Furthermore, I am considering restructuring at some point the project into a client/server architecture, with the core backend work happening outside of the embedded interpreter, and I'm not really that sure the dependencies will be helpful when this happens. As a consequence, I prefer either the second or the third option,and I manipulated the path to make sure the third party folder is in it. though if I understand correctly, option three might need a little bit more care with the whole licensing stuff as in that case I'm also distributing those packages, but not much of a problem for the time being. In the end I have gone for the second option. After cloning, users run the below command
which installs the necessary libraries inside the third_party folder, without affecting the site-packages of their local installation. to be honest, that is a bit cumbersome as well, as it currently needs to be done manually so I'm not fully satisfied with that either. I have been thinking about trying to automate the whole procedure but I was more focused on developing features and bug fixing so I haven't gone around to it.As a quick fix, so that everything works out of the box when people install the plug-in via package control would be to create a new release 0.0.5 that contains these libraries already inside third-party folder(so option three ). finally, searching through the sublime forum for user profiles, everything I find points me to portable versions, is this what you mean? this is something I haven't looked into and I fear there might be technicalities, as the plug-in is to be used alongside with the provided grammar bundles, with which they communicate through the sublime command line interface (subl) and not sure if this is going to cause any trouble. Once again many thanks for your feedback and I would love to hear any thoughts you have about the above! |
It takes approximately one hour for the crawler to pick up changes. Note that pre-releases aren't installed by default and require a manual settings tweak by the user.
You should be aware that when using an upacked package, PC removes the entire folder on every update, meaning your users would have to perform these steps after every update. Furthermore, it you intend to use the packages fetched and installed by the system Python from within ST's embedded Python, which is a terrible idea. Either have the user download packages from pypi into their system Python managed site packages or vendor the Python packages with your ST package, but don't mix the two, since the two Python versions are most likely going to differ (nobody uses Python 3.3 anymore). To make external installation of pypi packages possible (option 2), you can (hav ethe user) install them into an ST cache folder (subdir of
I don't understand this part. |
yeah it eventually did appear after a few hours,I was just wondering if that was natural or if I had made an error adding my project to the package control prereleases setting.
In general I agree that mixing python versions can be an entrance to a deep dark forest with possibly no exit. Initially, I myself, when I started experimenting with downloading pypi packages, downloaded python 3.3.5 (sublime uses 3.3.6 but I couldn't find a build for that) and used that version to download the packages, so as not to risk any compatibility issues. However, for the current needs of my project, I haven't run into any issues with the version used for installation, everything works perfectly with both 3.5.2 and 3.7.4. this is probably a perk of the design decisions I made early on. Because as you said Python 3.3 is old and available pre-built binaries/wheels are scarce for that version , I thought that providing my own binaries for a library I want to use was error-prone , I have made sure that all of the libraries used are pure python! None of my dependencies use C code ( as an example I use the highest version of segment_tree which does not import numpy), removing an important factor for incompatibilities. Of course everything is tested just to be sure. but for the time being I will be shiping them with the package.
This is close to what I have in mind with restructuring into a client/server architecture.The code using my future libraries(possibly containing C code) will be running on the backened/proxy script and a relatively small client script communicating with it. Thanks for pointing out those two projects, I would like take a look at how they go about with this sublime cache you mentioned. furthermore, I assume that since
I also should find another directory for my sublime settings file to avoid overwriting between updates? finally from what I understand, package updates can happen automatically( unless the user turns the setting off)?
Nevermind, my bad, Looking at it again, I Completely misunderstood some things I read on the forum and got needlessly confused. My apologies if I confused you too! |
I don't know if your explicitly saving that, but user-configured settings go to the User package normally, which ST never touches and overrides any other package settings (or any other resource file that is merged by ST internally).
Yes, by default Package Control checks for updates on start. |
PythonVoiceCodingPlugin is a tool which I hope will make voice coding faster and easier.
![big5](https://user-images.githubusercontent.com/35875229/68536811-ad27d000-0361-11ea-9659-aa088b0dd6f3.gif)
In case you are not familiar with voice coding, the core idea is to use speech recognition to dictate the code and voice commands to perform various operations (often such as to press the enter key or go left a certain number of words etc).
What this project tries to achieve is ,by running on the editors side, to provide valuable higher level functionality that would otherwise be impossible or at least very hard to implement, such as syntactically navigating through code, workarounds to struggling with dictating really long and hard to pronounce parameter or variable names, etc. All this can make user experience much more convenient , quicker and boost productivity. You can find more information in my documentation.
The closest package (and in fact the only related to voice coding) I could find in package control is VoiceCode but a quick look at their github reveals that there are substantial differences between our approaches.