Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Simplify mounting of project sources to plugins
Let's make an example. The user defines a workspace with 3 containers (3 tools in a devfile):

- Theia: it has mountSources=yes and the projects volume bound to folder /projects by default (i.e. defined in che-plugin.yaml, users don't need to specify anything in devfile) 
- Go LS and tooling: the same as Theia, the user doesn't need to specify anything about volumes or mount sources because the default should work for him
- His own runtime tool: it is where he will be able to open a shell and build / run his application. He is used to keep his sources /go/ so he will want to set `sourcePath=/go/` in the devfile 

In that scenario Go LS and Theia will use the same path (/projects bound to the volume /projects folder), the user will be able to use his own container and specify the source code path as required by his environment (/go bound to the volume /projects folder) without creating symlinks or changing environment variables. Wouldn't it be a valid and important scenario to support?

On Tue, Jan 22, 2019 at 5:34 PM Gorkem Ercan <gorkem.ercan@xxxxxxxxx> wrote:

I am a bit late to the thread but why is the source code path a plugin level concern?
I can see this being a workspace (IDE) level setting but at the plugin level changing the
path for each plugin does not sound like something that will work. Most of the plugins
and tools that Che uses comes from desktop. These tools are used to working with
single filesystem hierarchies and with concepts like workspaces, I do not think they
will be ready to handle own file system hierarchy and a way to map this to IDE’s hierarchy.
Unless we are assuming that plugins will work on their own and never communicate with each other
or the IDE this setting is an invitation to break things.

Thanks,
Gorkem

On 22 Jan 2019, at 11:19, Oleksandr Garagatyi wrote:

Yes, Lukas, you are completely right. We can’t clone Che-plugin-broker into /projects since traditional go tooling would not work

вт, 22 янв. 2019 г. в 18:01, Lukas Krejci <lkrejci@xxxxxxxxxx>:


On 22. 01. 19 16:43, tmader@xxxxxxxxxx wrote:
> On Tue, 2019-01-22 at 17:32 +0200, Oleksandr Garagatyi wrote:
>> @Thomas Maeder
>> In Go world projects are located by the GOPATH. Usually, GOPATH env
>> var is exported in bash profile or so. E.g. export
>> GOPATH=/home/user/goAfter that Go compiler and utils follow next
>> structural location of files:
>> $GOPATH/src <- projects AND dependencies (though dependencies not
>> always go here)
>> $GOPATH/bin <- compiled and packaged Go apps (usually added to PATH
>> to launch tools from it, often used for go based linters and other Go
>> related tools)
>> $GOPATH/src contains folders that represent Go packages and usually
>> include source hosting like github.com or golang.org.
>> For example, when I'm working on Che broker repo my path is
>> $GOPATH/src/github.com/eclipse/che-plugin-broker or
>> /home/gaal/workspace/go/src/github.com/eclipse/che-plugin-broker on
>> my system in particular.
>> All the Go tools like linters, compiler, and others expect GOPATH to
>> be populated in the system and structure to be respected.
>>
>> Hope it helps. If not, please, let me know.
> Thanks for the explanation. Howerver, I don't think it's a problem for
> the tooling, because the tooling will be installed in the plugin
> sidecar, where we control the value of $GOPATH (as well as in the Theia
> container). Why should GOPATH not be /projects?
>

You need to checkout your code into a particular subdirectory of GOPATH
that corresponds to the "structure convention" of Go, if I am not
mistaken (and please correct me if I'm wrong, Alex, I'm a Go noob).

E.g. because che-plugin-broker is hosted on github, it *needs* to be
checked out precisely to

$GOPATH/src/github.com/eclipse/che-plugin-broker

is that compatible we how we checkout stuff into /projects?

> /Thomas
>
>
>
>
>
> _______________________________________________
> che-dev mailing list
> che-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/che-dev
>
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
--
Oleksandr Garagatyi

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev

Back to the top