[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [Dltk-dev] 'internal' interpreter preference block
|
andrey -
you are correct - i do need to have an internal interpreter that can run code specific for the ide to function.
i did give thought to bundling an internal execution environment, but that does not solve all of my problems. there's no way i could provide an entire perl environment (along with any extra library dependencies to the end user). i could bundle any perl code i write specifically for the ide to function in a separate plugin, but if that code depends on some other perl library, i need to rely upon the user having some interpreter installed that has those modules in it's library path. a language with a java counterpat (jruby/jython) could probably avoid part of this, but i would think the if there were additional library dependies outside of the core environment it would still pose an issue.
most of the time, a user would only have one interpreter configured and it should just default to the one that is being used. i offered a way to choose which interpreter could be used in cases there are more then one. i didn't want to rely on the project's interpreter b/c if multiple were installed, the user may not want to install all the perl dependencies in each, and that would end up limiting functionality for those specific projects. scanning might work, but if multiple interpreters matched the criteria, which would be used? offering the user the a choice seemed to be the most flexible (and easiest) - although it would probably make sense to just use the global default interpreter unless the user wants to specify something else.
in the end, if dependencies aren't met, the script can fail gracefully with some kind of alert that indicates what is missing and then the user has to resolve the problem. eventually i foresaw adding a way for the ide to install those 'external' dependencies for the user, but that was still a ways off.
i have no problem moving this back into my plugin. the only reason i put it in the core was i figured there would be others out there wanting to do the same type of thing. perhaps the upcoming interpreter install changes you are going to suggest could take this into account. maybe there could be some kind of option that would designate if the interpreter was also to be used for internal script execution, or each installed interpreter could have a priority associated with it that would allow for the scanning mechanism to work (although there would still be the issue of what if two interpreters had the same priority, which one should win).
On Wed, Apr 2, 2008 at 3:19 AM, Andrey Platov <
andrey@xxxxxxxxx> wrote:
Hi Jae,
To keep DLTK Core conceptually clear, please could you comment on need to have special 'internal' interpreter. My quick thoughts is that Default interpreter shall be used in cases when you need to ask interpreter to do something outside a project context (or within unknown project context). If project is known - we shall use interpreter bounded to project. This is just general direction.
But your case looks to be slightly different, I guess main reason for you having 'internal' interpreter is to have Perl runtime enviroment to run part IDE code written in Perl. In this case you may be locked by interpreter version and/or required libraries, etc. In this case you definitely shall not rely on Default or any user-configured interpreter. Ideally from my point of view you shall bundle 'internal' Perl execution environment with your IDE and do not expose it to the user at all. Of course your current approach (ask user to configure 'internal' interpreter) will work (also I'm not sure this is convenient for the user), but we'd like to avoid this for other languages.
Alternatively to bundle Perl environment you may consider to scan "installed interpreters" and choose one that fits your needs (version, libraries, etc).
As for easy interpreter bundling, in next weeks I'm planning to propose changes to interpreters management and discuss them with committers. Goal is to make DLTK interpreters management more flexible (lie provide good support for interpreters other than executable binaries like JVM ones), easier to use in terms of API and configuration (which shall allow to bundle interpreters in form of OSGi bundles without pain, or retrieve configurations from different sources), etc
Please share your thoughts and if it's possible to introduce 'internal' interpreter at Perl IDE level, please move this code there. If you definitely need some support from core for your implementation - it's fine to leave this code with core, and let's rethink interpreters stuff in future.
Kind Regards,
Andrey
----- Original Message -----
From: "Jae Gangemi" <
jgangemi@xxxxxxxxx>
To: "DLTK Developer Discussions" <
dltk-dev@xxxxxxxxxxx>
Sent: Wednesday, April 2, 2008 9:06:20 AM GMT +06:00 Almaty, Novosibirsk
Subject: [Dltk-dev] 'internal' interpreter preference block
hello all -
i just committed code that can be used to add a preference page that will allow you to select an 'internal' interpreter (the available list comes from the list of installed interpreters) that can be used to execute an arbitrary script from an editor action or in my case, a source parser (and eventually some editor actions).
please let me know if there are any problems or questions.
--
-jae
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
--
-jae
