Skip to content
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

Merged
merged 2 commits into from
Jan 3, 2020
Merged

Conversation

mpourmpoulis
Copy link
Contributor

PythonVoiceCodingPlugin is a tool which I hope will make voice coding faster and easier.
big5
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.

Copy link
Collaborator

@packagecontrol-bot packagecontrol-bot left a 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

@FichteFoll
Copy link
Collaborator

Removing directories from sys.path after the packages and modules in that location have already been imported doesn't do anything, since imports are resolved based on the cached sys.modules dict first. Regardless, your third_party folder is empty, so you might as well remove that entirely.

Also note that PC installs packages in an archived state and I'm not sure if adding a patht to sys.path like you did even works in that case. Where possible, use relative imports. I can't really tell if your package will work inside one, because it's quite convoluted, so you should definitely test this yourself (by installing the package in a clean profile later or by using Package Controls "create package file" command).

@FichteFoll FichteFoll merged commit ab03b16 into wbond:master Jan 3, 2020
@mpourmpoulis
Copy link
Contributor Author

mpourmpoulis commented Jan 4, 2020

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:

  1. using dependencies
  2. separately download the plug-in and then install the libraries with the user's local installation of python
  3. ship pypi packages along with the plug-in inside the third-party folder

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

python3 -m pip install --target third_party -r requirements.txt

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!

@FichteFoll
Copy link
Collaborator

FichteFoll commented Jan 6, 2020

would you happen to know how long it takes for future releasees to become visible on package control?

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.

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

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 sublime.cache_path()), use a proxy Python script that you execute from within ST's plugin environment with the system Python to interface with these packages, and then communicate between the two. This is more or less common practice for larger frameworks that depend on external executables like SublimeLinter and LSP.

finally, searching through the sublime forum for user profiles, everything I find points me to portable versions, is this what you mean?

I don't understand this part.

@mpourmpoulis
Copy link
Contributor Author

mpourmpoulis commented Jan 7, 2020

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.

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.

installed by the system Python from within ST's embedded Python, which is a terrible idea.

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.

To make external installation of pypi packages possible (option 2), you can (hav ethe user) install them into an ST cache folder (subdir of sublime.cache_path()), use a proxy Python script that you execute from within ST's plugin environment with the system Python to interface with these packages, and then communicate between the two. This is more or less common practice for larger frameworks that depend on external executables like SublimeLinter and LSP.

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

You should be aware that when using an upacked package, PC removes the entire folder on every update

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)?

finally, searching through the sublime forum for user profiles, everything I find points me to portable versions, is this what you mean?

I don't understand this part.

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!

@FichteFoll
Copy link
Collaborator

I also should find another directory for my sublime settings file to avoid overwriting between updates?

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).

finally from what I understand, package updates can happen automatically(

Yes, by default Package Control checks for updates on start.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants