search

20Tauri / DoxyDoxygen

The last word in code documentation generation
140 stars 5 forks source link

Any plans to provide a ST4 build which runs on python 3.8? #167

Closed deathaxe closed 2 years ago

deathaxe commented 2 years ago

Doxygen seems quite popular.

What do you think about running it via python 3.8 on ST4?

A package/plugin can opt-in to python 3.8 plugin host of ST4 by creating a .python-version file in package root with content 3.8.

It requires all modules to be compiled using python 3.8.

20Tauri commented 2 years ago

This has been tested on a 0.79 version but it does not really improve the user experience. In your opinion, what are the advantages of a Python 3.8 version ?

deathaxe commented 2 years ago

Sure, it won't make a big difference for most existing plugins in the first place as most tasks performed by plugins are often too cheap to realize any difference.

With all all plugins opted-in to python 3.8 ST starts faster. Plugins are ready more quickly. They are automatically pre-compiled and don't run in debug-mode anymore.

Running two plugin-hosts is more expensive. Both need RAM and libraries/dependencies will need to be installed separately. The long term goal is therefore should be to return to a single plugin_host.

Folks have begged for more recent python for a long time. Here it is. So it should be the only one to use on ST4 these days. The "old" plugin_host just exists for backward compatibility, only. Let's call it deprecated, even though it's unlikely to be dropped anytime soon.

It's rather easy and seamless to opt-in most existing packages to python 3.8 by just adding said .python-version file locally. It fails however for packages with pre-compiled plugins.

I'v opted-in most plugins to py3.8 upstream, I have write access to, already.

Maybe Package Control will support the move towards py3.8 by adding mechanisms to force old unmaintained packages to run on python 3.8 once compatibility is verified. Maybe by something like "python_versions" key repositories.json, which is being added for dependencies/libraries.

TBH, I don't care about plugins like SublimeCodeIntel to break or not be ported as their time is over, but I'd appriciate popular and maintained packages to make the move.

Package Control 4.0 is going to support ST3143+ so can't make any use of python 3.8 syntactical sugar, but internal dev build already runs on python 3.8 on ST4 for said reasons.

20Tauri commented 2 years ago

A 0.81.2 version has been released with native support for ST4 python 3.8. I hope this help the Sublime Text team. I'm glad this plugin is considered useful, even if it's not really promoted by Package Control (many users discover the plugin through the "DocBlockR 2021" entry which is of little interest)

rchl commented 2 years ago

I don't think it's Package Control's job to promote anything. Although it could be a good idea for monetization. :)

20Tauri commented 2 years ago

"Promote" is probably not the right word, but it is hard to find packages for a specific need with Package Control.

DoxyDoxygen was born because DocBlockR did not work well with C++. DoxyDoc (a specific package for C++) was even worse. It even destroyed the code forcing to do undos.

This research made me lose time. For me, it is the mission of Package Control to guide the user to the plugins that best fit their needs.

The top 100 gives a very strong premium to historical packages. Faulty packages make the offer not very readable and do not invite to explore. I think that a system of suggestions and notes would improve the situation a bit. But I am aware that there is no perfect system.