[jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure more reliable locating of vagrant command (#831)

Max Rydahl Andersen manderse at redhat.com
Wed Dec 9 04:48:45 EST 2015 

On 8 Dec 2015, at 21:09, Rob Stryker wrote:

> Well, they run 'bash' basically,  which then has a full path, and then 
> feed further commands into the bash command. But I don't think running 
> bash is a solution thats appropriate for us over in cdk / vagrant.

> I still think our tools should be able to handle if the command isn't 
> on the path.

if it is not on the path users should be asked to point to it.

> There's no reason to make that assumption when to work around it is so 
> simple.  We simply search the path, which finds 95% of the usecases in 
> a very very quick time. And in the event it's not on the path, we do 
> the which/where, and this command responds almost instantly.

which searches the path and where is a control structure so I do not 
follow what difference that makes.

> We've already noticed that Mac seems to generate a different path 
> based on if you use the .app shortcut or from a terminal.

Yes, same for linux and windows afaik. They behave very similar here - 
just that on linux we (devs not users) tend to use command line to start 
things with.

> And windows users often install things like putty without explicitly 
> putting them on the path since they're used to using the binaries 
> directly. There seem to be many ways in which the path might be 
> incomplete, and it's definitely worth our while to use every mechanism 
> available to find them, to help our users and make our tools work 
> OOTB.

I don't grok why you are talking about putty here.

For Vagrant users are required to have it on the path to use it properly 
on windows afaik. So I don't understand why we can't rely on that too.

> Anyway, again,  we only run the search logic once per workspace 
> session. In 95% of the cases it responds extremely fast. In the event 
> the binary isn't found on the path, the simple which/where runs, and 
> also returns extremely quickly... and this is done only once per 
> workspace. I can't even notice a delay honestly.

Again, search path == run which so I'm not following why this is 
relevant ?

And I definitely do not like that search logic like this is done once 
per workspace session. Should be done on each run. Eclipse is a long 
running thing and unless operations are extremely expensive (like a 
remote/possible blocking call) we should do them dynamically instead of 
statically.

/max

>
> On 12/08/2015 03:00 PM, Max Rydahl Andersen wrote:
>> Rob,
>>
>> Is the Tty issue not separate from the way they use to locate the 
>> right way to run.
>>
>> I.e. They assume user has vagrant on path. Removing all need for 
>> doing custom which/where etc.
>>
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>> On 08 Dec 2015, at 20:34, Gorkem Ercan <gercan at redhat.com 
>> <mailto:gercan at redhat.com>> wrote:
>>
>>>
>>> I guess you can deal with /dev/tty. Perhaps something like "sh -l 
>>> less >/dev/tty" would work (I have not tried it though)
>>>
>>> On Tue, Dec 8, 2015 at 1:40 PM, Rob Stryker <rob.stryker at jboss.com 
>>> <mailto:rob.stryker at jboss.com>> wrote:
>>>
>>> OK, so, tl;dr is it seems you're using Debug.exec(etc) to launch
>>> the command, in this case bash,  which then gives you an
>>> IProcess. You feed further input into the IProcess to get the
>>> desired result, and I'm assuming you wire in the console support
>>> on your own via stream listeners.
>>>
>>>
>>> So you're not using any of org.eclipse.tm.terminal stuff.
>>>
>>> I've played with your utility class
>>> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/util/ExternalProcessUtility.java
>>> and it also seems to not function if the process being run is
>>> expecting the caller to be a TTY terminal (specifically, vagrant
>>> up for cdk2b3 not from the openshift-vagrant repo but the
>>> standard distribution).
>>>
>>> It seems to me that Runtime.exec(etc), Debug.exec(etc),  the
>>> external tools launch configuration, and all other solutions are
>>> incapable of being treated as a tty. Only the
>>> org.eclipse.tm.terminal stuff is capable of implementing the
>>> additional requirements to be treated as a tty...  however, I
>>> feel that using o.e.tm.terminal on a more regular basis is
>>> misguided.  For the first part, it becomes difficult to read its
>>> output.  The user can suddenly get involved in the process by
>>> typing things in at inopportune moments. It is impossible to use
>>> without the UI, so can't be done in the background, as well as a
>>> number of other issues that come as consequences of those.
>>>
>>> In short, it seems applications requiring a TTY environment are
>>> really not that many, and the fact that vagrant-registration
>>> requires it at all is very strange. It most likely needs the TTY
>>> functionality to accept a password without showing it, but I
>>> can't seem to figure out if thats just a guess or not.
>>>
>>> Either way, I'm going to stick with our current way of doing
>>> things, either via Runtime.exec when we want it in the
>>> background, ro external-tools launch config when we want the
>>> command's output to be shown in a console.
>>>
>>> - Rob
>>>
>>>
>>>
>>> On 12/08/2015 08:02 AM, Gorkem Ercan wrote:
>>>>
>>>> For Node.js based tools we needed a fully configured PATH
>>>> because it is often the case those tools will make calls to
>>>> other apps.
>>>> Basically our strategy is to start a full bash/cmd shell (notice
>>>> -l for bash) which will be configured fully. [1]
>>>> then execute the commands [2]
>>>> finally issue an exit to leave the shell [3]
>>>>
>>>> The only downside is you can not easily capture the process exit
>>>> code.
>>>>
>>>> The code examples are from the initial implementation that I
>>>> have done for CordovaCLI and uses eclipse libraries for starting
>>>> the process however it can be implemented equally same using the
>>>> Runtime.exec too. [4]
>>>>
>>>>
>>>> [1]
>>>> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L175
>>>> [2]
>>>> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L135
>>>> [3]
>>>> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L139
>>>> [4]
>>>> https://github.com/gorkem/js-parser-benchmarks/blob/master/src/main/java/org/jboss/tools/benchmark/parsers/esprima/EsprimaParser.java#L70
>>>> --
>>>> Gorkem
>>>>
>>>> On Tue, Dec 8, 2015 at 2:09 AM, Max Rydahl Andersen
>>>> <manderse at redhat.com <mailto:manderse at redhat.com>> wrote:
>>>>
>>>>     Question relevant on the list.
>>>>
>>>>     /max
>>>>     http://about.me/maxandersen
>>>>
>>>>
>>>>     On 08 Dec 2015, at 05:09, Rob Stryker <rob.stryker at jboss.com
>>>>     <mailto:rob.stryker at jboss.com>> wrote:
>>>>
>>>>>     Hey Guys:
>>>>>
>>>>>     Can you clarify how you guys call filesystem commands like
>>>>>     npm and cordova?
>>>>>
>>>>>     In the CDK tools as currently coded, we do two different
>>>>>     things.  One, is that we create an "External Tools Launch
>>>>>     Configuration" which runs the command. This requires
>>>>>     knowing the actual location of the executable.  The other
>>>>>     is to simply call Runtime.exec(etc) and get a Process from it.
>>>>>
>>>>>     The external tools launch config is useful because it opens
>>>>>     a console for us and means we don't have to do any of the
>>>>>     wiring, so we use that when we know we want the commands to
>>>>>     be visible to the user. We use the runtime.exec() in the
>>>>>     background for commands that we want to run without showing
>>>>>     the user (for example if we did a vagrant adbinfo)
>>>>>
>>>>>     How do you all do it?
>>>>>
>>>>>     - Rob Stryker
>>>>>
>>>>>
>>>>>     On 12/03/2015 11:36 AM, Max Rydahl Andersen wrote:
>>>>>>
>>>>>>     In
>>>>>>     
>>>>>> plugins/org.jboss.tools.openshift.cdk.server/src/org/jboss/tools/openshift/cdk/server/core/internal/CDKConstantUtility.java
>>>>>>     
>>>>>> <https://github.com/jbosstools/jbosstools-openshift/pull/831#discussion_r46575476>:
>>>>>>
>>>>>>     >  	public static String getVagrantLocation() {
>>>>>>     > -		return VAGRANT_LOCATION_LINUX;
>>>>>>     > +		return findVagrantLocation();
>>>>>>
>>>>>>     im wondering if we are better of launching this similar to
>>>>>>     what @gercan <https://github.com/gercan> and @ibuziuk
>>>>>>     <https://github.com/ibuziuk> been doing for npm and
>>>>>>     cordova cli tools.
>>>>>>
>>>>>>     i.e. call out via bash or cmd.exe making it up to the user
>>>>>>     to have it properly configured in PATH
>>>>>>
>>>>>>     —
>>>>>>     Reply to this email directly or view it on GitHub
>>>>>>     
>>>>>> <https://github.com/jbosstools/jbosstools-openshift/pull/831/files#r46575476>.
>>>>>>
>>>>>
>>>>
>>>
>>>


/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151209/f1ce4049/attachment-0001.html

More information about the jbosstools-dev mailing list